Ситуация, когда 1С:Предприятие 8.3 начинает «замирать» каждые несколько минут даже при отсутствии активных действий пользователя, является критической для работы любого предприятия. Особенно остро эта проблема проявляется в связке с MS SQL Server, когда в файловом варианте база работает стабильно, а при переходе на клиент-серверный вариант возникают необъяснимые фризы. Рассмотрим подробно причины такого поведения и разберем по шагам методы оптимизации системы для устранения зависаний.
Первым делом проанализируем, как именно общаются между собой сервер приложений 1С и сервер баз данных. Если обе службы (rphost.exe и sqlservr.exe) установлены на одной физической или виртуальной машине, использование сетевого протокола TCP/IP может быть избыточным и приводить к микрозадержкам.
Разберем настройку Shared Memory (общая память). Этот протокол позволяет процессам обмениваться данными напрямую через оперативную память, минуя сетевой стек ОС. Для этого выполним следующие действия:
SQL Server Configuration Manager.SQL Server Network Configuration -> Protocols for MSSQLSERVER.lpc:ИмяСервера.Также важно обратить внимание на настройки IPv6. Платформа 1С в некоторых сборках (особенно старых, таких как 8.3.10.2772) может некорректно обрабатывать разрешение имен, пытаясь сначала обратиться по IPv6, а затем по таймауту переходить на IPv4. Мы рекомендуем полностью отключить IPv6 в свойствах сетевого адаптера сервера или через реестр Windows, чтобы исключить этот фактор.
Часто причиной «замираний» всей базы на несколько секунд является неправильная настройка параллелизма в SQL Server. Рассмотрим параметр MAXDOP (Maximum Degree of Parallelism). По умолчанию он равен 0, что позволяет SQL распараллеливать один запрос на все доступные ядра процессора. Для 1С это часто становится фатальным, так как возникают блокировки типа CXPACKET.
Выясним причину и установим оптимальные значения:
Max Degree of Parallelism в значение 1. Это заставит каждый отдельный запрос выполняться на одном ядре, что для архитектуры 1С является наиболее стабильным вариантом.Cost Threshold for Parallelism. Изменим стандартное значение 5 на 50. Это предотвратит попытки SQL сервера распараллеливать мелкие, «дешевые» запросы, которые и вызывают микрофризы интерфейса.Еще один критически важный момент — Autogrow (авторасширение базы). Если расширение настроено в процентах (например, 10%), то при достижении лимита база может «встать» на значительное время, пока ОС выделяет место на диске. Проанализируем настройки файлов .mdf и .ldf и установим фиксированный размер приращения, например, 256 МБ или 512 МБ, в зависимости от интенсивности работы.
Даже если автор утверждает, что все задания отключены, система может продолжать выполнять скрытые процессы. Разберем ситуацию с фоновыми задачами. Иногда задание может «зациклиться» или постоянно перезапускаться после ошибки, создавая пиковую нагрузку на rphost.
Посмотрим на список активных фоновых заданий через консоль администрирования 1С. Особое внимание уделим заданию «Синхронизация файлов с облачным сервисом» или индексации Полнотекстового поиска (ПП). Если индекс ПП поврежден, попытка его обновления будет вызывать зависание конфигуратора и предприятия. Рекомендуется:
Также применим «хитрость» с переключением флажков: если задание кажется отключенным, попробуйте включить его, сохранить, а затем снова выключить. Это принудительно обновит состояние в таблицах SQL.
Поскольку работа ведется через терминальный сервер, проанализируем специфические причины, связанные с этой средой. Одной из самых неочевидных причин зависаний интерфейса 1С является опрос принтеров. Программа периодически проверяет доступность принтера по умолчанию.
Проверим это предположение:
Microsoft Print to PDF.Не забудем и про электропитание. На серверах часто стоит режим «Сбалансированный». Выясним, как это влияет: процессор снижает частоту в простое, и когда 1С посылает запрос, требуется время на «пробуждение» ядер, что ощущается как задержка в 0.5–1 секунду. Установим план «Высокая производительность» (High Performance) в настройках Windows Server.
Если вышеперечисленные методы не помогли, нам придется углубиться в диагностику. Настроим Технологический журнал (ТЖ). Создадим файл logcfg.xml в папке conf сервера 1С. Нас интересуют события, длительность которых превышает 1-2 секунды.
Пример настройки для отлова долгих запросов к БД:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\1C" history="24">
<event>
<eq property="Name" value="SDBL"/>
<gt property="Duration" value="1000000"/>
</event>
<event>
<eq property="Name" value="WAITCONN"/>
</event>
<property name="all"/>
</log>
</config>
Событие SDBL покажет нам запросы к базе данных, которые выполняются аномально долго. Событие WAITCONN подскажет, нет ли проблем с ожиданием свободных соединений в пуле. Анализируя эти логи, мы сможем точно сказать: виновата ли конфигурация (плохой запрос), настройки SQL или внешние блокировки антивируса.
К слову об антивирусах: обязательно добавим в исключения процессы rphost.exe, rmngr.exe, sqlservr.exe и все временные папки 1С (%AppData%\Local\1C и %AppData%\Roaming\1C), так как проверка временных файлов при каждом обращении 1С может вызывать те самые «ежеминутные тормоза».