Ситуация, когда мощный сервер с современными SSD-дисками и достаточным объемом оперативной памяти начинает периодически «подвешивать» сеансы пользователей 1С на 3–10 секунд, является классической проблемой при эксплуатации высоконагруженных систем. Часто такие зависания не фиксируются стандартными инструментами замера производительности (APDEX), так как задержка происходит на уровне системных вызовов или ожидания внешних ресурсов. В данной статье мы разберем комплексный подход к диагностике и решению этой проблемы на примере реального кейса с 1С:Документооборот.
Прежде чем приступать к программным изменениям, необходимо убедиться, что аппаратная часть и операционная система работают корректно. Для этого проанализируем состояние сервера с помощью системного монитора Performance Monitor (Perfmon). Рассмотрим ключевые показатели, на которые следует обратить внимание:
PhysicalDisk\Avg. Disk Queue Length (длина очереди). В норме она не должна превышать 2 на один физический диск. Также критически важны Avg. Disk Write Time и Avg. Disk Read Time. Если значения превышают 15–20 мс, значит, диски не справляются с нагрузкой, несмотря на их номинальную скорость.System\Processor Queue Length. Очередь более 2 на одно логическое ядро свидетельствует о нехватке вычислительных мощностей. Обратим внимание на показатель прерываний в секунду — резкие всплески могут указывать на проблемы с драйверами или сетевой картой.SQLServer:Buffer Manager\Page life expectancy (PLE). Он показывает, сколько секунд страница данных удерживается в кэше. Значение ниже 300 секунд говорит о «кислородном голодании» SQL-сервера и необходимости выделения дополнительной памяти.Важный нюанс: Если при попытке трассировки SQL-запросов с записью в таблицу сервер «встает колом», это явный признак того, что дисковая подсистема или механизмы блокировок SQL не справляются с синхронной записью логов. В таких случаях рекомендуется использовать Extended Events (расширенные события) с асинхронной записью в файл.
Выясним причину влияния рабочих процессов rphost на стабильность системы. Если используется 32-битная версия сервера 1С:Предприятие, мы сталкиваемся с жестким ограничением адресного пространства (около 3-4 Гб на процесс). Рассмотрим, почему это приводит к зависаниям:
При достижении лимита памяти или сильной фрагментации виртуального адресного пространства, процесс rphost начинает тратить значительное время на очистку памяти или перезапуск. В этот момент все пользователи, чьи сеансы находятся в данном процессе, ощущают «фриз». Проанализируем настройки кластера и внесем следующие корректировки:
Часто причина периодических тормозов кроется в регламентных заданиях, которые выполняются в фоновом режиме. Рассмотрим ситуацию, когда 1С обращается к внешней базе данных (например, к сайту на MySQL) через COM-объединение. Посмотрим на пример кода, который может вызывать длительное ожидание:
Соединение = Новый COMОбъект("ADODB.Connection");
Соединение.ConnectionString = "Driver={MySQL ODBC 8.0 Driver};Server=my_server;Database=my_db;Uid=my_user;Pwd=my_pass;";
Соединение.ConnectionTimeout = 60;
Соединение.CommandTimeout = 60;
Попытка
// Именно здесь происходит зависание
Соединение.Open();
Исключение
ЗаписьЖурналаРегистрации("Ошибка подключения", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;
Проанализируем этот участок кода. Если метод Open() выполняется 10–12 секунд, это блокирует поток выполнения рабочего процесса. Если таких заданий несколько, сервер начинает «подвисать» для всех пользователей. Выясним причину такой задержки.
Опытным путем установлено, что новые версии драйверов (например, MySQL ODBC 8.0) могут работать крайне медленно в средах Windows 2008 R2 из-за попыток использования SSL, протоколов шифрования caching_sha2_password или особенностей разрешения имен IPv6.
Рассмотрим решение: замена драйвера MySQL ODBC с версии 8.0 на версию 5.1 (или 5.3) позволяет сократить время установки соединения с 12 секунд до 0.03 секунды. Это полностью устраняет «необъяснимые» фризы в интерфейсе пользователей, так как фоновое задание перестает захватывать ресурсы на длительное время.
Для исключения микрозависаний выполним дополнительные настройки сервера:
MaxDop = 1 (в некоторых случаях — 2 или 4, в зависимости от количества ядер и нагрузки), чтобы избежать ожиданий на типе CXPACKET.Netbios-именем, иначе протокол может не задействоваться.Подводя итог, скажем: если вы столкнулись с периодическими зависаниями, которые не видит 1С-ный замер производительности, ищите проблему во внешних компонентах, COM-объектах или сетевых ожиданиях при работе фоновых заданий. Системный мониторинг счетчиков PhysicalDisk и SQLServer:Buffer Manager в сочетании с анализом драйверов внешних систем — кратчайший путь к стабильной работе 1С.