Рассмотрим ситуацию, которая часто встречается в крупных внедрениях 1С:ERP и Документооборота: сервер под управлением Windows Server 2019 с установленным MSSQL 2019 стабильно работает в течение 8–10 дней, после чего «наглухо» зависает с загрузкой процессора 100%. При этом системные журналы Windows не фиксируют явных ошибок перед крахом, а помогает только жесткая перезагрузка виртуальной машины. Проанализируем причины этого явления, разберем настройки гипервизора Proxmox, конфигурацию SQL-сервера и особенности платформы 1С:Предприятие.
Когда мы работаем в среде KVM (Proxmox), важно понимать, что взаимодействие гостевой ОС Windows с «железом» происходит через слой драйверов VirtIO. Одной из главных причин внезапных зависаний баз данных является механизм Memory Ballooning. Рассмотрим, как он работает: гипервизор пытается «забрать» неиспользуемую оперативную память у одной виртуалки и отдать другой. Однако MSSQL Server по своей природе стремится занять всю выделенную ему память под кэш (Buffer Pool) и крайне неохотно ее возвращает.
Когда драйвер баллонинга пытается сжать память внутри Windows, возникает конфликт приоритетов, который приводит к резкому росту прерываний CPU и «замиранию» системы. Рекомендация: для серверов MSSQL и 1С необходимо использовать только фиксированный объем оперативной памяти (Fixed RAM). В настройках Proxmox убедимся, что параметры Minimum memory и Maximum memory совпадают, а лучше — полностью отключим устройство Balloon в оборудовании виртуальной машины.
Также проанализируем настройки дисковой подсистемы. Для высоконагруженных баз данных 1С крайне важно использовать контроллер VirtIO SCSI с включенной опцией iothread=1. Это позволяет вынести обработку операций ввода-вывода в отдельный поток процесса QEMU на хосте, предотвращая блокировку основных ядер процессора при интенсивной записи в tempdb или лог транзакций.
В рассматриваемой нами ситуации серверу выделено 12 ядер процессора. Если физический сервер имеет двухпроцессорную конфигурацию (два сокета), важно правильно пробросить топологию в виртуальную машину. Разберем по шагам:
Numa: 1.Кроме того, выясним, нет ли переподписки (overcommit) по ресурсам CPU на хосте. Если сумма ядер всех виртуальных машин значительно превышает количество физических потоков, возникают задержки планировщика (CPU Wait), которые внутри гостевой ОС выглядят как 100% загрузка процессора «в никуда».
Проблема может крыться и в настройках самого SQL-сервера. Проанализируем параметр Max Degree of Parallelism (MAXDOP). Для 1С рекомендуется устанавливать это значение в зависимости от количества ядер в одном NUMA-узле (обычно от 1 до 8). Если оставить значение 0 (использовать все доступные ядра для одного запроса), тяжелый отчет или некорректное регламентное задание может монополизировать все 12 ядер, вызывая зависание всей ОС.
Посмотрим на настройки памяти SQL Server. Необходимо ограничить Maximum server memory таким образом, чтобы операционной системе оставалось как минимум 4–8 Гб для собственных нужд и работы процессов rphost сервера 1С. Если SQL займет все 60 Гб, Windows начнет активно использовать файл подкачки (swap), что на виртуальных дисках мгновенно «кладет» производительность системы до нуля.
Как было отмечено в обсуждении, одной из причин может быть некорректная работа сетевого стека. В драйверах VirtIO-Net по умолчанию включены функции разгрузки (Offloading), такие как Large Send Offload (LSO) и Checksum Offload. В некоторых реализациях стека Windows Server 2019 это вызывает «шторм прерываний» при интенсивном обмене данными между сервером приложений 1С и SQL-сервером.
Выполним следующие действия в гостевой ОС Windows:
Offload.Это заставит центральный процессор обрабатывать сетевые пакеты более предсказуемо, устраняя риск внезапных зависаний сетевого драйвера.
Если штатные средства (Просмотр событий Windows) не дают ответа, нам необходимо настроить сбор данных в момент зависания. Рассмотрим вариант создания простого скрипта, который будет записывать состояние системы в файл. Это поможет понять, какой именно процесс (sqlservr.exe или rphost.exe) потребляет ресурсы перед коллапсом.
Создадим PowerShell-скрипт и добавим его в планировщик задач с запуском каждые 5 минут:
$Date = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
$TopProcesses = Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
$Output = "--- $Date ---`n" + ($TopProcesses | Out-String)
Add-Content -Path "C:\Logs\ServerMonitor.log" -Value $Output
Что касается технологического журнала 1С, то для поиска причин зависания системы стоит настроить минимальный конфиг, отслеживающий только длительные операции и события EXCP (исключительные ситуации). Рассмотрим пример файла logcfg.xml:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<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>
Важно помнить, что если сервер зависает «наглухо», техжурнал может не успеть сбросить буфер на диск. Поэтому использование внешней системы мониторинга (например, Zabbix или Nagios), как предложили коллеги на форуме, является наиболее эффективным способом поймать момент «смерти» сервера и проанализировать графики нагрузки на CPU, диск и память в динамике.
Несмотря на то, что автор темы утверждает об отключении заданий, выясним одну деталь: платформа 1С может инициировать процессы обслуживания даже при пустой консоли заданий. Например, Обновление индекса полнотекстового поиска или Пересчет итогов. При базах объемом 140 Гб эти операции могут быть крайне ресурсоемкими. Проанализируем в консоли кластера 1С, не остаются ли «висящие» сеансы фоновых заданий, которые могли войти в бесконечный цикл из-за ошибок в коде доработок ERP или Документооборота.
Подведем итог: если вы столкнулись с подобной проблемой, в первую очередь исключите влияние механизмов динамического распределения памяти гипервизора (Ballooning), проверьте сетевые настройки VirtIO и убедитесь, что SQL-сервер не «душит» операционную систему, оставляя ей достаточно ресурсов для работы драйверов и системных служб.