Встречаются ситуации, когда рабочий процесс сервера 1С (rphost.exe) внезапно начинает потреблять значительную часть ресурсов процессора, вплоть до 100%. При этом стандартные средства мониторинга, такие как анализ запросов к СУБД (например, MS SQL), не показывают аномалий. Запросы выполняются с обычной скоростью, но система в целом тормозит, а ключевые показатели производительности, вроде Apdex, резко падают. Проблема может появляться и исчезать без видимых причин, что сильно усложняет диагностику.
Давайте разберемся, как системно подойти к поиску источника такой нагрузки, когда проблема кроется не в базе данных, а на стороне сервера приложений 1С.
Первое, с чего стоит начать, — это сбор ключевых показателей производительности самого сервера. Если вы столкнулись с необъяснимой загрузкой CPU, обратите внимание на следующие счетчики производительности Windows (Performance Monitor):
Особое внимание уделим очереди к процессору. Если у вас мощный сервер с большим количеством ядер (например, 32), а очередь все равно огромная, это может указывать на скрытое ограничение.
Критически важный момент — тип серверной лицензии 1С.
Лицензия версии ПРОФ имеет ограничение на количество используемых ядер. Для старых платформ, как в рассматриваемом случае (8.3.12), это ограничение составляет 12 ядер. Это означает, что даже если на вашем сервере 32 или 64 ядра, сервер 1С будет использовать только 12 из них. Остальные будут простаивать. В результате, вся нагрузка ложится на эти 12 ядер, они быстро достигают 100% утилизации, и возникает огромная очередь из задач, которые ждут обработки. Лицензия КОРП, в свою очередь, таких ограничений не имеет и может использовать все доступные ресурсы сервера.
Таким образом, если у вас лицензия ПРОФ и высокая очередь к процессору, вы, скорее всего, уперлись именно в это ограничение. Проблема не в "железе", а в лицензионной политике.
Иногда нагрузку создают не внутренние алгоритмы 1С, а внешние программы, которые вызываются из кода. Часто для таких целей используется COMОбъект("WScript.Shell"). В нашем примере были обнаружены вызовы утилит ping и WinSCP.exe.
Пример кода для создания искусственной паузы через ping:
СтрокаЗапроса = "ping -n 1 -w " + Формат(1000 * КоличествоСекунд, "ЧДЦ=0; ЧГ=") + " 127.255.255.255";
WshShell = Новый COMОбъект("WScript.Shell");
WshShell.Run(СтрокаЗапроса, 0, -1);
Такой код, хоть и работает годами, может стать источником проблем. Если внешний процесс (ping, WinSCP или любая другая программа) по какой-то причине "подвиснет" — например, из-за сетевых проблем, недоступности удаленного хоста или ошибки в самой утилите — то сеанс 1С, который его запустил, будет ждать его завершения, удерживая ресурсы рабочего процесса rphost. При большом количестве таких "зависших" вызовов это может приводить к деградации производительности.
Как диагностировать:
rphost.exe. Если вы видите "висящие" ping.exe, WinSCP.exe или другие утилиты, это ваш главный подозреваемый.Это самый мощный метод для поиска конкретного виновника, когда непонятно, какой именно пользователь или фоновое задание вызывает проблему. Суть метода в том, чтобы заставить сервер 1С создавать отдельный рабочий процесс rphost.exe для каждого нового подключения.
Внимание! Этот режим является исключительно диагностическим. Он потребляет много ресурсов (порты, оперативная память) и не предназначен для постоянной работы. Используйте его на короткое время для выявления проблемы.
Разберем по шагам, как это настроить:
Что мы получим в итоге?
Теперь в "Диспетчере задач" вы увидите множество процессов rphost.exe. Когда возникнет проблема с высокой загрузкой CPU, вы легко определите, какой именно процесс ее вызывает. После этого в консоли администрирования серверов 1С вы сможете посмотреть, какой именно сеанс (пользователь, фоновое задание) обслуживается этим процессом, и получите точное указание на источник проблемы.
После того как вы определили проблемный сеанс, необходимо понять, что именно он делает. Если проблема не в запросах к СУБД, значит, она в серверном коде 1С (длительные циклы, рекурсия, неоптимальная работа с коллекциями). Здесь на помощь приходит Технологический журнал.
Настройте ТЖ на сбор следующих событий:
SCALL (Server Call) — вызовы серверных процедур и функций. Анализируя это событие по свойству Duration (длительность), вы найдете самые "тяжелые" серверные операции, которые и потребляют процессорное время.MEM и LEAKS — события, связанные с управлением памятью. Иногда высокая загрузка CPU является следствием медленной утечки памяти. Процесс rphost разрастается, и операционная система тратит все больше ресурсов на его обслуживание.Анализ логов ТЖ позволит выявить конкретную процедуру или функцию в коде конфигурации, которая является причиной аномальной нагрузки.
Системный подход, включающий анализ системных метрик, проверку лицензий, изоляцию сеансов и детальный анализ кода с помощью ТЖ, поможет найти и устранить даже самые неочевидные причины высокой загрузки процессора сервером 1С.