Как определить причину периодических зависаний 1С:Комплексная автоматизация 2.4?

← На главную

Периодические зависания информационной базы (фризы), повторяющиеся с определенным интервалом (например, каждые 2–5 минут), — это одна из самых сложных диагностических задач для администратора 1С. В условиях работы 1С:Комплексная автоматизация 2.4 на серверном варианте с публикацией на веб-сервере, источником проблемы может быть любой уровень инфраструктуры: от кода конфигурации до настроек дисковой подсистемы SQL-сервера. Разберем пошагово, как проанализировать ситуацию и найти «виновника» деградации производительности.

1. Анализ регламентных и фоновых заданий

Первым делом проанализируем активность системы внутри самой платформы 1С. Поскольку зависания имеют циклический характер, велика вероятность, что они связаны с РегламентныеЗадания. В конфигурации КА 2.4 многие процессы вынесены в фоновое выполнение.

Выполним следующие действия:

Откроем консоль регламентных заданий и отсортируем их по колонке «Дата окончания».
Сопоставим моменты зависания системы с временем завершения или начала выполнения заданий.
Обратим особое внимание на задание «Индексация полнотекстового поиска». Оно часто настроено на запуск каждые несколько минут. В крупных базах процесс перестроения индекса (ППС) вызывает колоссальную нагрузку на дисковую подсистему.
Проверим специфичные для КА 2.4 задания: «Расчет взаиморасчетов», «Отражение документов в регламентированном учете» и «Формирование движений по партиям». Эти механизмы работают через РегистрСведений.ОчередьЗаданийКРасчету. Если очередь переполнена, фоновые процессы могут блокировать таблицы, вызывая ожидание у пользователей.

2. Использование Технологического журнала (ТЖ)

Журнал регистрации (ЖР) не фиксирует длительность операций и не показывает, на чем именно «зависла» система. Для глубокого анализа нам потребуется Технологический журнал. Это наиболее мощный инструмент диагностики платформы «1С:Предприятие».

Рассмотрим пример настройки файла logcfg.xml для выявления длительных операций и событий, превышающих 5 секунд:


<config xmlns="http://v8.1c.ru/7.4/config/log">
  <log location="C:\LOGS\ALL" history="24">
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <gt property="Duration" value="5000000"/>
    </event>
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="SDBL"/>
      <gt property="Duration" value="5000000"/>
    </event>
  </log>
</config>

Проанализируем полученные логи. Событие DBMSSQL покажет конкретные SQL-запросы, которые выполнялись долго. Событие EXCP поможет увидеть ошибки, которые могли происходить в фоновом режиме, не отображаясь у пользователя, но потребляя ресурсы.

3. Диагностика на стороне СУБД (SQL Server)

Если сервер 1С работает штатно, выясним, что происходит на стороне SQL-сервера. Зависание может быть вызвано ожиданием ресурсов (Wait Stats).

Разберем основные типы ожиданий, которые могут возникать в моменты фризов:

PAGEIOLATCH: Если вы видите этот тип ожидания, значит, SQL-сервер ждет данных с диска. Это подтверждает гипотезу о проблемах с дисковой подсистемой или чрезмерной нагрузке от других процессов (например, антивируса или архивации).
LCK_M_...: Это явные блокировки. Один процесс (например, тяжелый отчет) захватил таблицу, а остальные стоят в очереди. Выясним, какой именно spid является блокирующим.
CXPACKET: Свидетельствует о неоптимальной настройке Max Degree of Parallelism. Сервер тратит ресурсы на управление потоками вместо выполнения запроса.

4. Особенности веб-публикации и веб-сервера

Поскольку база опубликована, проанализируем работу веб-сервера (IIS или Apache). Иногда зависания связаны не с 1С, а с сетевым уровнем или настройками пула приложений.

Проверим следующие настройки:

Keep-Alive: Убедимся, что таймауты Keep-Alive на веб-сервере согласованы с настройками кластера 1С.
Recycling (Переработка пулов): В IIS по умолчанию может стоять периодическая перезагрузка рабочих процессов. В момент перезапуска пула все пользователи ощутят «зависание» на 10–30 секунд, пока процесс инициализируется заново.
Антивирусная защита: Проверим, не сканирует ли антивирус временные файлы процессов rphost.exe и w3wp.exe. Исключим папки с сеансовыми данными и файлы БД (.mdf, .ldf) из проверки.

5. Мониторинг счетчиков производительности ОС

Для понимания общей картины настроим сбор счетчиков производительности Windows (Performance Monitor) с интервалом в 1–2 секунды. Нам важны следующие показатели:

Средняя длина очереди диска (Avg. Disk Queue Length): Если значение стабильно выше 2 на один физический диск, это говорит о перегрузке. Именно это часто является причиной кратковременных замираний интерфейса.

% загрузки процессора: Проанализируем, какой именно процесс потребляет CPU в моменты пиков — sqlservr.exe или rphost.exe. Если rphost.exe, то проблема в неоптимальном коде 1С, если sqlservr.exe — в тяжелых запросах или отсутствии индексов.

6. Проверка лицензирования и сети

Иногда «фризы» на несколько секунд вызваны тем, что платформа теряет связь с менеджером лицензий. Если используются сетевые ключи HASP, проанализируем файл nnhasp.ini. Рекомендуется явно прописывать IP-адрес сервера лицензий (NH_SERVER_ADDR), чтобы исключить фазу широковещательного поиска (Broadcast), во время которой поток 1С может блокироваться.

Резюме

Для решения проблемы «зависаний раз в 2–5 минут» мы рекомендуем комплексный подход:

1. Временно отключите полнотекстовый поиск для проверки гипотезы о нагрузке на диск.
2. Включите замер производительности в момент зависания, если это возможно сделать на конкретном рабочем месте.
3. Настройте минимальный Технологический журнал на сбор событий DBMSSQL и SDBL длительностью более 5 секунд.
4. Проверьте очередь заданий к расчету в КА 2.4 — это «узкое место» данной конфигурации.