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

← На главную

Периодические коллективные зависания базы данных 1С:Предприятие в клиент-серверном режиме — одна из самых неприятных проблем при сопровождении высоконагруженных систем. Ситуация, когда работа всех пользователей парализуется на 10–20 минут, а затем работа программы самопроизвольно восстанавливается, свидетельствует о возникновении системных блокировок, зависании рабочих процессов или некорректной работе СУБД. Разберем по шагам основные причины подобного поведения и способы их устранения.

1. Проверка и очистка последствий динамического обновления

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

Проанализируем наличие «хвостов» динамических обновлений в таблице Config базы данных. Для этого выполним запрос в SQL Server Management Studio (SSMS):

SELECT * FROM Config WHERE FileName LIKE '%dyn%'

Если запрос возвращает строки с именами файлов, содержащими dyn, это говорит о наличии остатков динамических обновлений. Для полного устранения поврежденных метаданных рекомендуется:

Создать полную резервную копию информационной базы.
Выгрузить информационную базу в файл формата .dt через конфигуратор.
Создать чистую базу данных на MS SQL Server.
Загрузить файл .dt в новую базу и проверить работу пользователей.

2. Настройка параметров MS SQL Server

Неоптимальная конфигурация экземпляра MS SQL Server часто приводит к тому, что операции ввода-вывода полностью блокируют выполнение транзакций.

Разберем параметры, которые требуют обязательной проверки:

Автоувеличение файлов базы данных (Auto-growth): Убедимся, что шаг прироста файлов базы данных (.mdf) и журнала транзакций (.ldf) задан в мегабайтах (например, фиксированный прирост от 256–512 МБ до 1–2 ГБ), а не в процентах. Процентный прирост при больших объемах базы вызывает длительные дисковые задержки.
Мгновенная инициализация файлов (Instant File Initialization, IFI): Предоставим учетной записи службы SQL Server системную привилегию «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks) в локальных политиках безопасности Windows. Это исключит обнуление выделяемого дискового пространства и зависание базы при росте файлов данных.
Отключение автосжатия и автозакрытия: Проверим свойства базы данных: параметры AUTO_SHRINK и AUTO_CLOSE должны быть строго установлены в значение OFF.
Асинхронное обновление статистики: Включим параметр AUTO_UPDATE_STATISTICS_ASYNC = ON. Это позволит СУБД обновлять устаревшие статистические данные в фоновом режиме, не замораживая пользовательские запросы.
Режим версионирования строк (RCSI): Для конфигураций на управляемых блокировках (например, «Управление торговлей 11») активируем версионирование на уровне базы SQL:
```
ALTER DATABASE [Имя_Базы] SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Базы] SET ALLOW_SNAPSHOT_ISOLATION ON;
```
Это минимизирует взаимные блокировки при параллельном чтении и записи данных.

3. Оптимизация рабочих процессов кластера серверов 1С

Выясним причину зависания процессов rphost. Если в кластере серверов 1С работает только один рабочий процесс, любая неоптимальная операция одного пользователя может заблокировать все остальные сеансы.

Настроим кластер серверов 1С для предотвращения деградации:

Количество рабочих процессов: В консоли администрирования кластера серверов 1С разделим нагрузку, увеличив количество процессов rphost (из расчета 1 процесс на каждые 15–20 активных пользователей или на 2–4 ядра процессора).
Контроль утечек памяти: В свойствах кластера зададим лимиты:
- «Допустимый объем памяти» — ограничим максимальный объем ОЗУ на один процесс;
- «Интервал превышения допустимого объема памяти» — укажем интервал, по истечении которого перегруженный rphost будет автоматически перезапущен;
- «Интервал перезапуска процессов» (например, 86400 секунд) для регулярного сброса фрагментированной памяти.

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

Для точной локализации зависаний настроим сбор технологического журнала сервера 1С. Создадим файл logcfg.xml в каталоге conf платформы 1С:Предприятие.

Рассмотрим структуру файла конфигурации для отслеживания длительных операций и блокировок:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\1C_TECHLOG" history="24">
        <event>
            <eq property="name" value="TLOCKS"/>
            <ge property="duration" value="10000000"/>
        </event>
        <event>
            <eq property="name" value="TTIMEOUT"/>
        </event>
        <event>
            <eq property="name" value="DEADLOCK"/>
        </event>
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

События TLOCKS, TTIMEOUT и DEADLOCK помогут выявить конкретные объекты метаданных и участки исходного кода, вызывающие длительные ожидания на управляемых блокировках.

5. Настройка электропитания и сети операционной системы

Проанализируем системное окружение Windows Server:

Схема электропитания: В панели управления Windows выставим план электропитания «Высокая производительность» (High Performance). Режимы экономии энергии переводят ядра процессора в состояние энергосбережения (C-States / Core Parking), что провоцирует микрозадержки при резких всплесках нагрузки.
Сетевые адаптеры: В свойствах сетевой карты сервера отключим аппаратную разгрузку (параметры Large Send Offload / LSO и TCP Chimney Offload), чтобы предотвратить зависания сетевого стека при интенсивном обмене данными между клиентами, сервером приложений и СУБД.