Описание окружения: основной кластер 1С состоит из 2х виртуальных машин VM06 и VM10; сервер для тестов и копий баз - VM28. Много баз вида "бухгалтерия", куда иногда заходит 1 пользователь-бухгалтер, ведущий эту базу.
Некоторое время назад прочитал статью Производительность сервера 1С и фоновые задания. Ну почитал, поогорчался по поводу очередного "это не баг, это фича" и забыл. Вернее, подумал "ну, как-нибудь надо будет проверить на своих серверах".
Шло время. Тормоза на серверах нарастали. Загрузка процессора стала уже даже не 80-90%, а 90-100%. Причем в диспетчере задач на конкретной виртуальной машине часто видел 100% загрузку несколько минут подряд.
Я глядел на графики и пытался увидеть зависимость между работой пользователей (или фоновых заданий) и нагрузкой на процессоры. И вот что заметил:
1) Нагрузка на процессоры не имеет прямой зависимости от числа сеансов пользователей. Потому что пользователи в 18:00 домой ушли, а нагрузка не ушла.
2) Нагрузка на процессоры резко падает в 24:00, и резко возвращается уже в 8:00 - а в это время (8:00) пользователи только начинаю заходить в 1С.
Отсюда сделал вывод, что весомую нагрузку дают фоновые задания. На основании того, что нагрузка растет в 8:00, и падает в 24:00, - был вычислен "виновник" - регламентное задание "обновление индекса". Его типовое расписание как раз "с 8:00 каждый день".
вообще конечно весьма странное расписание. Понятно было б если расписание было круглосуточным (как у большинства регламентных), или например с 8:00 до 17:00. А то получается что пользователи вечером ушли, а индексирование работает "ни для кого". И дает нагрузку в 8:00 вместо того, чтоб подготовить свежие данные в 7:30.
Но как оказалось позже, это был не он. Отключение полнотекстового поиска на копиях баз не дало заметного снижения нагрузки на процессор.
На тестовом сервере дела обстояли еще хуже. От руководства поступило указание создать еще несколько копий баз с формулировкой "не блокировать регламентные через свойства базы в консоли, только отметить ""Это копия базы"", чтоб заблокировать обмены". Работать стало вообще невозможно. И в попытке хоть как-то повлиять на ситуацию, в копиях баз я решил по одному выключать регламентные задания которые нельзя было назвать жизненно необходимыми, а также отключить функциональность (полнотекстовый поиск, новости, проверка контрагентов, СПАРК-риски и т.п.).
Уже не помню почему, мой выбор первым делом пал на регламентное "проверка лицензии сеанса" в БСХП. И...
Отключение иных регламентных и функциональности не дали столь заметного эффекта.
Итак, главный вывод данной статьи: эффект, описанный в статье "Производительность сервера 1С и фоновые задания" имеет место, но только когда интервал запуска (условно) менее минуты и в базе нет пользователей. В той статье наличие проблемы было подтверждено для пустого регламентного задания запускаемого каждые 10 секунд в 15 базах. В моем случае расписание запуска задания от разработчика БСХП - 15 секунд, число баз 9.
В статье Юрия был намек, а в комментариях - прямо предложено решение в виде поддержания ненулевого числа сеансов в базах. Я проверил влияние com-соединений в таких базах (читай "сеансов") на процессор:
Как видим, добавление сеансов (com-соединений) действительно позволяет решить проблему не отключая регламентное задание.
После тестового сервера пришла очередь рабочих баз и рабочих серверов:
При этом оказалось, что еще в марте можно было заметить резкий рост нагрузки на процессор в момент включения данного регламентного задания:
На снимке можно заметить резкое повышение нагрузки на процессор 27 марта - как раз в тот момент, когда я включил это регламентное. Но на тот момент боги ит-олимпа еще не включили меня в число избранных, имеющих доступ к zabbbix, а потому у меня не было графика, на котором была бы видна история изменения нагрузки на процессоры.
Вообще это стандартное регламентное, встроенное в конфигурацию "Бухгалтерия сельскохозяйственного предприятия" - БСХП. По-умолчанию оно включено. Я отключил его в январе-феврале из-за обнаруженных падений рабочих процессов сервера 1С (rphost.exe), причем падения в журнале Windows фиксировались очень часто, примерно раз в 5 минут:
На снимке видны значения параметров "version=" и "timestamp=". По этим параметрам гугл привел на https://forum.infostart.ru/forum86/topic183763/, откуда стало ясно что причина в ключах БСХП. Проблема была озвучена админам, был назначен исполнитель, который отчитался что сервер лицензий конфигурации обновлен (как оказалось позже, это было не так). Но падения не прекратились. Тогда был включен технологический журнал, который указал на вызов метода, а тот в свою очередь уже привел к регламентному:
После чего уже другой исполнитель занялся ключами и обновил СЛК. Падения прекратились, и было решено включить регламентное.
Ссылки:
1) Как получить такие же графики по числу сеансов в zabbix?
См. Zabbix: Мониторинг состояния сервера 1С
А если хочется сразу готовое решение, то вот: <здесь будет статья с моей конфой>
2) Обработка для создания com-соединений по списку баз из окна запуска (по файлу ibases.v8i) Выполнение кода и создание пользователя сразу в нескольких базах
Понравилась статья? Поставь плюс. Рекомендую другие статьи:
Исправление ошибки "Для одного ссылочного кода существует более одной таблицы в базе данных"
