Ситуация, когда информационная система на базе 1С начинает «подтормаживать» через равные промежутки времени (например, каждые 2 часа на 5–10 минут), является классической проблемой для высоконагруженных систем с большим количеством пользователей. В такие моменты привычные операции — формирование печатных форм или обновление динамических списков — замедляются в несколько раз, хотя видимых причин в виде 100% загрузки процессора может и не быть. Разберем по шагам, как диагностировать и решить эту проблему.
Одной из наиболее частых причин «затыков» в работе связки 1С и SQL является неправильная настройка параллелизма. Если СУБД пытается распараллелить выполнение даже простого запроса на все доступные ядра процессора, это порождает огромные накладные расходы на управление потоками. Разберем ключевые параметры:
0 (использовать все доступные процессоры). Для систем 1С настоятельно рекомендуется устанавливать значение 1 (отключить параллелизм для отдельного запроса) или, в крайнем случае, ограничивать его небольшим числом ядер (2 или 4, в зависимости от количества процессоров).MAXDOP больше 1, установите порог стоимости параллелизма. Значение по умолчанию 5 — слишком маленькое для современных серверов. Рекомендуется установить значение 50 или выше, чтобы SQL Server не пытался параллелить «легкие» запросы.Проверить и изменить эти настройки можно через SQL Management Studio или с помощью скрипта:
EXEC sys.sp_configure N'show advanced options', N'1';
RECONFIGURE;
EXEC sys.sp_configure N'max degree of parallelism', N'1';
RECONFIGURE;
Если тормоза возникают циклично, проанализируем настройки кластера 1С. В консоли администрирования серверов 1С для рабочих процессов существуют параметры «Интервал перезапуска» и «Допустимый объем памяти».
Рассмотрим ситуацию: если процесс rphost достигает предела по памяти или истекает время его жизни, сервер 1С создает новый процесс и начинает постепенно переводить туда пользователей. В этот момент система может существенно замедляться, так как кэш нового процесса пуст, а старый процесс еще удерживает часть ресурсов. Проверьте параметры:
86400 (сутки) и настроить перезапуск на ночное время.Чтобы понять, что именно происходит внутри 1С в моменты замедления, нам не обойтись без Технологического журнала. Это основной инструмент разработчика для диагностики платформенных проблем. Настроим сбор событий, которые длятся более определенного времени (например, 5–10 секунд).
Создадим файл logcfg.xml в папке conf на сервере 1С со следующим содержимым:
<config xmlns="http://v8.1c.ru/7.4/config">
<log location="C:\LOGS\DBMSSQL" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="5000000"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<gt property="Duration" value="5000000"/>
</event>
<property name="All"/>
</log>
</config>
В данном примере мы фиксируем все обращения к СУБД (DBMSSQL) и запросы на языке SDBL, которые длились более 5 секунд (время в ТЖ указывается в микросекундах). Проанализировав эти логи в период торможения, мы увидим конкретные куски кода или SQL-запросы, которые «вешают» систему.
Выясним, не влияют ли другие базы данных на основную рабочую среду. Если на одном сервере крутятся «тяжелая» самописка и, например, типовая конфигурация (как «Аптека» в примере автора), они могут конфликтовать за ресурсы rphost.
Проанализируем возможность разнесения баз по разным рабочим процессам. В настройках информационной базы в консоли кластера можно указать конкретные рабочие серверы или использовать «Профили безопасности» и «Требования функциональности» для того, чтобы закрепить за конкретной базой определенные ресурсы. Это исключит ситуацию, когда регламентное задание одной базы полностью парализует работу пользователей в другой.
Периодичность в 2 часа часто указывает на выполнение фоновых заданий. Проверим следующие моменты:
Auto Update Statistics Asynchronously (асинхронное обновление статистики). Это позволит SQL выполнять запросы со старой статистикой, не дожидаясь окончания процесса обновления.Если системный администратор утверждает, что ресурсов достаточно, посмотрим на проблему со стороны SQL Server через Wait Types (типы ожиданий). Если в моменты тормозов вы видите высокие значения:
PAGEIOLATCH_EX/SH — значит, система «упирается» в дисковую подсистему (медленное чтение/запись).LCK_M_... — это явные блокировки, когда один пользователь или процесс заблокировал таблицу, а остальные ждут.CXPACKET — подтверждение проблем с MAXDOP (избыточный параллелизм).Для детального анализа рекомендуется использовать отчеты Standard Reports -> Performance Dashboard в SQL Management Studio или сторонние инструменты, такие как статистика по запросам MSSQL из состава подсистемы инструментов разработчика.
Резюме: Решение проблем с периодическими тормозами всегда начинается с настройки MAXDOP = 1, анализа интервалов перезапуска rphost и обязательного включения Технологического журнала. Только сопоставление времени тормозов с конкретными событиями в логах позволит точно определить «виновника» — будь то тяжелый отчет пользователя или неудачно настроенное регламентное задание.