Медленный обмен в РИБ #804374

Всем привет. Становится невозможно работать в РИБ. Пытаюсь как-то повысить производительность. Провел расходную накладную в периферийной базе - к выгрузке зарегистрировался 1 документ и 1 нз регистра . Делаю обмен в периферии с центром и замеряю . Файл обмена всего 21 килобайт . Делаю обмен в центре с периферией и замеряю . Это вообще нормально генерировать и обрабатывать xml-файл в 21 килобайт 20 секунд? Есть ли какие пути увеличения производительности?

Мало инфы.Загрузка аппаратных мощностей в этом момент какая? Куда файл обмена кладете? Может диски очередями забиты или, если по сети, то сеть перегружена.

Обмен через FTP или как?

ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения, чРазмерТранзакции); где чРазмерТранзакции = 0, а ЗаписьСообщения формируется как: стрИмяФайла = "C:UsersAdministratorAppDataLocalTempMSG_11118_1_00000000000000000000000000000000002627.xml" на машине где Кластер серверов, обмены делаю с другого сервака. Сейчас перемеряю на машине где сам Кластер находится.

Все, замеры на одном серваке, где стоит кластер серверов и работаю в клиентах показали такие же результаты. Обмен через файл на диске. Кластер серверов и клиенты на 1-м серваке, кладу файл сюда же на диск С:, сеть не причем поидее. Пока грешим на дисковую систему, в планах есть переход на SSD. Но это же нереально 20 кбайт обрабатывать 20 секунд!

Там цифры можно конкретные посмотреть. Если у тебя очередь диска 20, то ничего удивительного.

Загрузка ЦП

Вот вот, именно на этой форточке есть кнопка посередине внизу "Resource Monitor ...". Вот нажимай ее. А там уже и до статистики по дискам доберешься.

Момент выполнения метода ЗаписатьИзменения Не особо умею мониторить, но на сколько понял высокой загрузки дисков тоже нет.

Уже почти добрался. :) Заходи на вкладку "Диск". Разворачивай окна. Самое нижнее "Запоминающие устройства". Последний столбец "Длина очереди" ЗЫ: На английский сам переведи ладно.

Спасибо ) Но больше 0.06 не прыгало в момент выполнения метода. Еще серваки виртуальные, админы разворачивают. Думаю это тоже частично влияет, но не на столько же...

Может у тебя хостовые машины еле шевелятся. Надо там смотреть.

Надо тебе с админами кооперироваться. Ты у себя время формирования файла смотри, а админы пусть у себя профайлерами статистику собирают.

А все остальные операции летают?Только обмен проблемный?

из очевидного: вечером выгоните пользователей и проведите повторный обмен - станет понятно проблема это параллельности или производительности

а чего за конфа ? Где все модули через Ом начинаютя?

Не открывается у меня Радикал. Но если загрузка CPU высокая (одно ядро на 100%), то это настройки виртуалки (мало выделили ресурсов и т.д.). Если низкая, то блокировки в базе. Ну и стандартный вопрос: после чего начались проблемы?

А какой смысл тестировать на 1 документе,не понимаю... Там только на накладные расходы может все уходить типа заархивировать/разархивировать сообщение. Попробуй в настройках обмена отключить сжатие сообщений

у тебя  79% времени выполняется запись изменений плана обмена. я думаю в базе куча не используемых узлов и соответственно куча записей для регистрации

Критичен только обмен, остальное работает терпимо. Тестирую в 2-х тестовых базах только под 1 юзером. Не важно :) Мало распространенная с доработками. Когда количество узлов перевалило за 15. Около 20 узлов в РИБ, все рабочие и регулярно делают обмены. Чет мне кажется дело в 1С и большом количестве узлов.

количество узлов никак не влияет на обмен. Возьмите с типовой последние обработки для обмена и общие модули.

Ну да, в периферии то всего 2 узла. Типовой, как таковой, и нету у данной конфы, поэтому не возьму. Пытаюсь разобраться почему медленно выполняется 1 строка кода. За ночь сделалось ТИИ в обоих базах, после этого скорость не увеличилась.

возьмите любую типовую конфу и оттуда общие модули и обработки для обмена. Они универсальные и одинаковые.

Сегодня обмены колом стали из-за блокировок. Пришлось всех кикать и делать монопольно самому. Вот такая красота при замере . Если дальше запросы и т.п. я могу оптимизировать, то эти 2 строки кода нет :(

Статистика хостовых машин в это время что показывает? Статистика самих виртуалок в это время что показывает? ЗЫ: Может антивирус активно мешает?

Поставь в настройках, количество элементов в транзакции при загрузке = 1.

аналогично, при выгрузке.

сейчас у тебя, видать 0 стоит и он всё в одну большую транзакцию пихает

С админами надо проверить будет, пока нет возможности. Пробовал в тестовой базе ставить 1 и не понял на что влияет. Для выгрузки был 1 документ и 1 нз регистра, все равно одним пакетом все выгрузил. Но все равно спс, надо попробовать будет нормально протестить. Уже идея возникла на автономной машине развернуть центр и 1 периферию и сделать замеры, чтобы понять в железе дело или нет.

пакет и будет один, просто его формирование будет быстрее

>количество узлов никак не влияет на обмен Еще как влияет. Для каждого нужно зарегистрировать изменение, для каждого проставить номер, для каждого очистить регистрацию. И это все *для каждого элемента*. Сейчас кто-то должен дать классическую ссылку на ИТС про обмен и блокировки. Мне лень искать.

Вот: (Слава встроенному поиску в Firefox.)

Спасибо за ссылку, но уже читал статью. Пока боремся, но проблема достигла критической точки :(

не реклама, но, вроде, хвалят

У нас ничего не хвалят ) Все системы кривые, если их не оттестировало пару млн человек, что в сфере решений 1С нереально...

+ 1.

Спс, уже тестируем.

Небольшой тестик сделал. Одна и та же база в файловом и серверном варианте:

Файловая база это на локальной машине или все на том же виртуальном сервере?

На том же виртуальном сервере, где и кластер серверов.

А локально что с быстродействием?   Есть все таки подозрение,  что ваша виртуалка слишком долго думает чтобы выделить ресурсы вашему "быстрому" процессу. )