В высоконагруженных системах 1С, работающих с базами данных объемом в несколько терабайт, администраторы часто сталкиваются с ситуацией, когда количество SQL-запросов резко возрастает, а система перестает отвечать. При этом ресурсы сервера (процессор, диски) могут не показывать пиковой нагрузки, а большинство запросов находятся в статусе Sleeping. Разберем подробно, почему это происходит и как решить данную проблему.
Для начала проанализируем, что именно означает статус Sleeping в контексте MS SQL Server. Само по себе это состояние говорит о том, что соединение установлено, но в данный момент SQL-сервер не выполняет никаких команд и ждет следующего пакета от клиента (сервера приложений 1С). Однако критически важным является наличие открытой транзакции в этом состоянии. Если open_tran > 0, это означает, что 1С начала транзакцию, внесла изменения или наложила блокировки, а затем "ушла" выполнять длительный код на встроенном языке или ожидать ответа от внешнего сервиса.
Выясним причину такого поведения. Когда транзакция остается открытой в "спящем" режиме, она продолжает удерживать блокировки на уровне строк или таблиц. Другие сеансы, пытающиеся обратиться к тем же данным, встают в очередь (ожидание LCK_M_...), что в итоге приводит к лавинообразному росту количества активных соединений и полной деградации производительности.
Рассмотрим наиболее вероятного виновника — фоновые процессы. В крупных базах данных (свыше 2.5 Тб) фоновые задания могут выполняться часами. Проанализируем список активных фоновых заданий в моменты коллапса через консоль администрирования 1С или стандартную обработку "Регламентные и фоновые задания".
Если вы обнаружили процессы, которые висят долгое время, попробуйте их принудительно завершить. Особое внимание стоит уделить:
Одной из неочевидных причин зависания SQL-соединений являются искусственные задержки в коде 1С. Разберем пример кода, который может привести к серьезным проблемам в многопользовательской среде:
ДатаПауза = ТекущаяДата() + 20;
Пока ТекущаяДата() < ДатаПауза Цикл
// Пустой цикл для ожидания
КонецЦикла;
Посмотрим на ситуацию: если такой код выполняется внутри транзакции (например, в модуле объекта ПередЗаписью или ПриЗаписи), то на все 20 секунд SQL-соединение будет находиться в статусе Sleeping, удерживая все захваченные блокировки. Это крайне неэффективный способ реализации пауз. Если необходимо организовать ожидание (например, при работе с веб-сервисами), рекомендуется выносить это ожидание за пределы транзакционных блоков или использовать механизмы фоновых заданий.
В базах большого объема механизм версионирования объектов может стать "монстром", поглощающим ресурсы. Выясним, почему это происходит. Каждое изменение объекта приводит к записи в таблицу ВерсииОбъектов. При объеме базы 2.5 Тб эта таблица может занимать сотни гигабайт. Постоянная запись в нее при проведении документов создает огромную нагрузку на дисковую подсистему и увеличивает время фиксации транзакций.
Рассмотрим шаги по оптимизации:
Для баз данных объемом свыше 2 Тб стандартные настройки SQL Server могут быть неоптимальны. Проанализируем состояние базы tempdb. В статусе Sleeping запросы могут находиться и в том случае, если сервер приложений 1С ждет выделения места или страниц во временных таблицах.
Выполним следующие рекомендации:
tempdb на несколько файлов одинакового размера (по количеству ядер процессора, но обычно не более 8-12 файлов).tempdb на самые быстрые доступные накопители (NVMe SSD).Разберем настройки кластера 1С. В версии 8.3.11 управление пулом соединений имеет свои особенности. Если количество соединений достигает лимита (150 в описанном случае), сервер 1С перестает выдавать новые соединения, и система "замирает".
Проанализируем параметры в консоли администрирования:
rphost, чтобы в случае зависания одного из них, остальные продолжали работу.Для решения проблемы с массовым появлением запросов в статусе Sleeping необходимо действовать комплексно. Сначала выявим длительные фоновые задания и проверим код на наличие "пустых циклов" и транзакционных ловушек. Затем оптимизируем хранение версий объектов и настройки tempdb. Важно помнить, что на таких объемах данных (2.5 Тб) любая микро-задержка в коде, помноженная на количество пользователей, превращается в критическую остановку всей системы.