Почему 1С тормозит, когда сервер свободен: ищем «невидимые» причины

← На главную

Рассмотрим сложную и нетривиальную ситуацию: высоконагруженная система 1С:ERP на мощном сервере с сотнями пользователей внезапно начинает "зависать". При этом все стандартные средства мониторинга — диспетчер задач, монитор ресурсов, SQL Management Studio, технологический журнал — показывают, что сервер практически не нагружен, а очевидных ошибок и блокировок нет. Пользователи "висят" намертво, а система выглядит так, будто с ней никто не работает. Выясним, куда копать в таких случаях и как обнаружить "невидимые" причины тормозов.

Проблема часто носит комплексный характер, и ее решение требует системного подхода, затрагивающего все уровни: от физического оборудования до тонкостей кода конфигурации.

Этап 1. Анализ аппаратной части, виртуализации и ОС

Как показала практика, одной из самых неочевидных причин подобных "фризов" может быть подсистема хранения данных и настройки на уровне "железа" или гипервизора. Даже если у вас сверхбыстрые диски, проблема может скрываться в том, как операционная система с ними работает.

Проблема: PCI-E SSD и диспетчер очереди I/O

В описанном на форуме случае финальным решением стал переезд на новый сервер, где не использовался PCI-E SSD. Это указывает на то, что проблема крылась либо в самом диске, либо в его драйверах, либо в его взаимодействии с гипервизором.

Рассмотрим подробнее. Современные быстрые диски, особенно NVMe SSD потребительского класса, могут стать "бутылочным горлышком" в многопользовательской среде. Операционные системы и гипервизоры могут использовать для них примитивные диспетчеры очереди ввода-вывода, например, FIFO ("первый пришел — первый ушел"). Такая очередь неэффективна, когда на диск одновременно поступает множество мелких и разнородных запросов от сотен сеансов 1С. В результате, хотя общая загрузка диска в процентах будет низкой, система будет "замирать", ожидая обработки своего запроса в общей очереди. Диск, по сути, становится "однопользовательским".

Решения:

В некоторых ОС (например, Linux, на ядре которого работают гипервизоры типа ESXi) можно перенастроить планировщик ввода-вывода на более подходящий для серверных нагрузок (например, `noop` или `deadline`).
Использовать SSD класса Enterprise. Они изначально спроектированы для параллельных многопоточных нагрузок и имеют более совершенную внутреннюю логику обработки очередей.
Проверить совместимость оборудования. Убедитесь, что ваша модель SSD и его прошивка официально поддерживаются версией вашего гипервизора (Hyper-V, ESXi). Иногда простое обновление гипервизора или драйверов решает проблему.

Проблема: Настройки энергосбережения

Еще одна частая и неочевидная причина — включенные по умолчанию режимы энергосбережения в BIOS/UEFI сервера и в настройках гипервизора. Такие режимы (C-states, P-states) снижают частоту процессора и отключают ядра в моменты простоя. Когда нагрузка резко возрастает, системе требуется время, чтобы "проснуться" и выйти на максимальную производительность. Эти микрозадержки, помноженные на сотни пользователей, могут приводить к заметным "тормозам".

Решение: В настройках BIOS/UEFI сервера и в панели управления гипервизора установите профиль управления питанием на "Максимальная производительность" (High Performance). Это заставит процессор всегда работать на максимальной частоте.

Проблема: Настройки `tempdb` в MS SQL

Для высоконагруженных систем 1С критически важна правильная настройка системной базы данных `tempdb`. 1С активно использует временные таблицы, и если `tempdb` настроена неоптимально, это становится узким местом.

Решение:

Размещайте файлы `tempdb` на самых быстрых дисках, которые у вас есть (в идеале — NVMe SSD класса Enterprise).
Создайте несколько файлов данных для `tempdb`. Рекомендуемое количество — по одному файлу на каждое ядро процессора, выделенное для SQL Server (но обычно не более 8). Это снижает конкуренцию за системные ресурсы при создании временных таблиц.

Этап 2. Настройка кластера серверов 1С:Предприятие

Даже при идеальном "железе" неправильные настройки кластера серверов 1С могут приводить к деградации производительности.

Проблема: Один рабочий процесс (rphost)

По умолчанию в кластере 1С работает один рабочий процесс на информационную базу. При большом количестве пользователей он становится "бутылочным горлышком". Платформа 1С не всегда эффективно распределяет потоки одного процесса по разным ядрам процессора. В итоге вы можете видеть картину: одно ядро CPU загружено на 100%, остальные простаивают, а весь сервер "тормозит". При этом общая загрузка процессора может быть всего 10-15%.

Решение: Увеличить количество рабочих процессов.

Зайдите в настройки рабочего сервера в консоли администрирования кластера 1С.
Увеличьте параметр "Количество ИБ на процесс" или уменьшите "Количество соединений на процесс", чтобы платформа автоматически создавала новые процессы `rphost.exe`.
Опытным путем рекомендуется устанавливать количество рабочих процессов примерно равным количеству физических ядер процессора.
Важно: При увеличении числа процессов необходимо настроить их автоматический перезапуск по объему потребляемой памяти или по расписанию. Это помогает бороться с утечками памяти, которые свойственны платформе. Например, можно настроить перезапуск процесса, когда он достигнет 5-7 Гб ОЗУ.

Это компромисс: вы получаете лучшую производительность и отзывчивость, но иногда пользователи могут испытывать кратковременный разрыв сессии при "миграции" с одного перезапускаемого процесса на другой. Однако это лучше, чем тотальное "зависание" всех.

Проблема: Динамическое обновление конфигурации

В высоконагруженных и сильно доработанных базах механизм динамического обновления часто приводит к непредсказуемым последствиям. Он может оставлять "мусор" в служебных данных, что вызывает деградацию производительности.

Яркий пример из обсуждения — константа СведенияОбОбновленииИБ. В ней накапливалась таблица значений с информацией о сеансах, которая разрослась до 11000 строк. Простое обращение к этой константе занимало 6 секунд. После ручной очистки время сократилось до миллисекунд.

Решение: Полностью отказаться от динамических обновлений. Проводить все обновления конфигурации монопольно, выгнав всех пользователей из базы. После обновления обязательно выполнять Тестирование и Исправление (ТИИ) с реструктуризацией таблиц информационной базы.

Этап 3. Анализ кода и настроек конфигурации

Если на уровне "железа" и платформы все настроено верно, ищем причину в самой конфигурации.

Проблема: Механизм ограничения доступа на уровне записей (RLS)

В ходе диагностики было обнаружено, что сеансы пользователей "висели" внутри вызова функции общего модуля, которая многократно вызывала платформенный метод УстановитьБезопасныйРежимРазделенияДанных(). Это напрямую связано с механизмом RLS.


// Примерный код, где происходило зависание
Функция ВычислитьВБезопасномРежиме(Знач Выражение, Знач Параметры = Неопределено) Экспорт
    УстановитьБезопасныйРежим(Истина);
    МассивРазделителей = ОбщегоНазначенияПовтИсп.РазделителиКонфигурации;
    Для Каждого ИмяРазделителя Из МассивРазделителей Цикл
        УстановитьБезопасныйРежимРазделенияДанных(ИмяРазделителя, Истина); // ТУТ ВСЕ ВИСЯТ
    КонецЦикла;
    Возврат Вычислить(Выражение);
КонецФункции

Проблема RLS часто бывает "невидимой". SQL-сервер может быть не нагружен, но система тормозит. Это происходит потому, что платформа 1С тратит огромное количество времени не на само выполнение запроса, а на его построение. Она анализирует сложные шаблоны ограничений, добавляет их к основному запросу, и этот процесс может занимать секунды, блокируя выполнение кода.

Решение: Оптимизация RLS.

Проанализируйте шаблоны ограничений доступа. Часто типовые роли содержат избыточные проверки по множеству полей ("Организации", "Подразделения", "Группы доступа партнеров" и т.д.).
Если для большинства пользователей достаточно ограничения по одному-двум полям (например, только по подразделению), создайте собственные, упрощенные роли с максимально простыми шаблонами RLS. Это может ускорить работу с динамическими списками и открытие форм в десятки раз.

Проблема: Большой журнал регистрации (ЖР)

Работа с огромным журналом регистрации — еще одна причина "мертвых" зависаний. Попытка сделать отбор в ЖР по какому-либо объекту (например, найти все события по конкретному документу) в файле размером в десятки гигабайт может привести к полной блокировке сеанса. Причем такой зависший сеанс иногда невозможно даже принудительно завершить из консоли администрирования.

Решение:

Регулярно сокращайте и архивируйте журнал регистрации. Не позволяйте ему разрастаться до неконтролируемых размеров.
Если вы все еще используете старый формат ЖР (файлы `.lgf`), рассмотрите переход на формат SQLite, но будьте готовы к тщательному тестированию производительности. В некоторых случаях старый формат может работать быстрее, но он более подвержен проблемам при больших объемах.

Выводы

"Невидимые" тормоза в 1С, когда стандартные метрики производительности в норме, почти всегда указывают на наличие узкого места на том уровне, который этими метриками не отслеживается. Для решения таких проблем необходим комплексный подход:

Начните с "железа": Отключите энергосбережение, проверьте совместимость и настройки подсистемы хранения данных, особенно если используете быстрые NVMe SSD.
Оптимизируйте кластер 1С: Увеличьте количество рабочих процессов, настройте их автоматический перезапуск, откажитесь от динамических обновлений.
Ищите узкие места в конфигурации: Проанализируйте и упростите правила RLS, следите за размером журнала регистрации и оптимизируйте код, выполняющий длительные транзакции.

Только последовательная проверка всех этих уровней позволит найти и устранить истинную причину загадочных "зависаний" и обеспечить стабильную работу высоконагруженной системы.