Почему периодически зависает база 1С 8.3 на MS SQL Server и как это исправить?

← На главную

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

Основные причины сбоев и зависаний базы

Проанализируем типичную инфраструктуру: сервер приложений 1С работает под управлением 32-разрядной платформы 1С:Предприятие 8.3, СУБД развернута на MS SQL Server 2016, а средой виртуализации выступает Hyper-V. В таких условиях зависания чаще всего вызываются следующими факторами:

Переполнение адресного пространства 32-битного рабочего процесса: Рабочий процесс rphost.exe в 32-разрядной версии имеет жесткое ограничение виртуальной памяти (около 2–3 ГБ). При приближении к этому порогу процесс зависает при попытке выделить новый блок памяти.
Повреждения кеша после динамических обновлений: Частое использование механизма динамического обновления конфигурации БД приводит к рассогласованию метаданных в кеше кластера, что вызывает аварийную остановку внутренних потоков.
Стековые и сетевые ошибки сокетов (ошибка 10038): В технологическом журнале появляется исключение вида WSAENOTSOCK (код 10038 — попытка выполнить операцию на объекте, не являющемся сокетом), связанное с некорректной работой сетевых карт виртуализации Hyper-V или некорректным разрывом соединений.
Неоптимальные настройки автоприращения файлов MS SQL: При задержках на стороне дисковой подсистемы во время автоувеличения размера файлов базы данных или лога транзакций 1С может уходить в длительное ожидание.

Шаг 1. Диагностика через технологический журнал 1С

Для определения точной причины сбоя настроим сбор данных технологического журнала. Создадим файл log.cfg в каталоге конфигурации сервера 1С (обычно C:\Program Files (x86)\1cv8\conf) со следующим содержимым:


<config xmlns="http://v8.1c.ru/8.2/virtual-resource-system">
  <log location="C:\LOGS\1C" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="PROC"/>
    </event>
    <property name="all"/>
  </log>
</config>

В моменты зависания проанализируем созданные логи. Если в файлах журнала фиксируются записи типа HeartbeatThreadImpl.cpp с текстом descr=10038(0x00002736): Сделана попытка выполнить операцию на объекте, не являющемся сокетом, это говорит о разрыве фоновых соединений между службой сервера и клиентами.

Шаг 2. Настройка перезапуска процессов 32-битной платформы

Если временно нет возможности перевести кластер 1С на 64-разрядную платформу, необходимо настроить автоматический контроль ресурсов рабочего процесса в консоли администрирования кластера 1С:

Откроем консоль Администрирование серверов 1С Предприятия.
Перейдем в свойства локального кластера.
Установим значение параметра Предельный объем виртуальной памяти (например, 1600000 КБ, что соответствует ~1.5 ГБ).
Зададим параметр Интервал перезапуска рабочих процессов равеным 86400 секунд (24 часа) или укажем допустимое количество соединений на один рабочий процесс (например, 10–15 сеансов).

Благодаря этим настройкам кластер 1С будет автоматически создавать новый процесс rphost.exe и плавно переносить сеансы до того, как текущий процесс исчерпает память и зависнет.

Шаг 3. Очистка кеша и корректное обновление конфигурации

Выясним причину возможного повреждения метаданных. При систематическом применении динамического обновления кеш на сервере может содержать устаревшие или поврежденные скомпилированные модули. Для полного исправления проблемы выполним следующие шаги:

Завершим работу службы 1C:Enterprise 8.3 Server Agent (ragent).
Очистим каталог серверов 1С от временных файлов кеша (папки с именами GUID в каталоге %PROGRAMDATA%\1C\1cv8\srvinfo\reg_1541).
Запустим службу ragent.
В Конфигураторе выполним выгрузку конфигурации в файл (.cf), после чего сделаем полный запуск обновления базы без применения динамического режима.

Шаг 4. Оптимизация параметров MS SQL Server 2016

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

В SQL Server Management Studio (SSMS) откроем свойства информационной базы.
В разделе Files (Файлы) изменим параметры Autogrowth (Автоувеличение): вместо процентного приращения по умолчанию (10%) установим фиксированный размер (например, 512 MB или 1024 MB) для файла данных и файла журнала транзакций.
Предоставим учетной записи службы MS SQL Server право в локальной политике безопасности Windows: Выполнение задач по обслуживанию тома (Perform Volume Maintenance Tasks). Это позволит SQL Server мгновенно выделять место на диске без предварительного заполнения файла нулями.
В свойствах сервера SQL в разделе Advanced установим параметр Max Degree of Parallelism (MAXDOP) равным 1 (или от 2 до 4 в зависимости от количества ядер), чтобы предотвратить взаимные блокировки паралельных потоков выполнения запросов.

Шаг 5. Настройка виртуальной сети и параметров Hyper-V

При наличии ошибки сокетов 10038 в технологическом журнале причиной зависания часто выступает виртуальный сетевой адаптер Hyper-V. Для предотвращения сброса TCP-соединений отключим функции аппаратной разгрузки на сетевом адаптере виртуальной машины:

В операционной системе виртуального сервера откроем Диспетчер устройств.
В свойствах сетевого адаптера перейдем на вкладку Дополнительно (Advanced).
Отключим следующие параметры:
- IPv4 Checksum Offload
- Large Send Offload v2 (IPv4) / LSO
- Virtual Machine Queue / VMQ

Описанный комплекс мер позволяет полностью ликвидировать причины внезапного зависания информационной базы 1С 8.3 и обеспечить стабильную работу пользователей без необходимости регулярного перезапуска служб.