Как устранить резкие скачки производительности 1С на виртуальном сервере?

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

Настройка Технологического журнала для локализации проблемы

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

Настроим ТЖ на сбор событий DBMSSQL и CALL с длительностью более нескольких секунд. Это позволит увидеть, на чем именно уходит время — на выполнение запроса к СУБД или на исполнение кода на сервере 1С. Пример конфигурационного файла logcfg.xml:

<config xmlns="http://v8.1c.ru/7.4/puls/config">
  <log location="C:\LOGS\1C" history="24">
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <gt property="Duration" value="10000000"/>
    </event>
    <event>
      <eq property="Name" value="CALL"/>
      <gt property="Duration" value="10000000"/>
    </event>
    <property name="All"/>
  </log>
</config>

Если ТЖ показывает длительные ожидания на уровне DBMSSQL при низкой загрузке CPU, мы имеем дело с проблемами дисковой подсистемы или блокировками.

Проблема «двойного кэширования» и сброса кэша на диск

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

В определенные моменты происходит так называемый «сброс кэша» на физический диск. Если объем накопленных данных велик, а физическая дисковая система занята другими задачами, ВМ буквально «замирает», ожидая завершения записи. Чтобы минимизировать этот эффект, проанализируем следующие рекомендации:

1. Отказ от динамического распределения памяти: Гипервизоры умеют выделять память «по требованию» (Memory Ballooning), но для 1С это критично. Установите фиксированный объем RAM для ВМ.
2. Прямой проброс дисков: Для высоконагруженных баз рекомендуется отдавать физические диски (LUN) виртуальной машине напрямую (Pass-through), минуя уровень виртуальных файловых систем типа VMFS или VHDX.
3. Использование SSD NVMe: Скорость случайного доступа на таких дисках позволяет нивелировать задержки, возникающие при очистке кэша.

Оптимизация работы SQL Server в виртуальной среде

Посмотрим на настройки SQL Server. Часто системные администраторы оставляют параметр Max Server Memory по умолчанию, что позволяет SQL «отъедать» всю доступную память ВМ. Это приводит к тому, что операционной системе Windows не хватает ресурсов для системных процессов и драйверов, что вызывает свопинг (использование файла подкачки).

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

1. Ограничим Max Server Memory так, чтобы у ОС оставалось не менее 15–20% оперативной памяти (или минимум 4–8 Гб).
2. Включим опцию Lock Pages in Memory (LPIM). Это предотвратит вымывание кэша SQL Server в файл подкачки, если гипервизор решит «забрать» память у гостевой ОС.

Планировщик гипервизора и CPU Ready

Проанализируем ситуацию с процессором. Даже если внутри гостевой ОС загрузка ядер составляет 10%, 1С может тормозить из-за параметра CPU Ready. Это время, которое виртуальная машина проводит в очереди, ожидая доступа к физическим ядрам процессора.

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

Решение: уменьшите количество vCPU до разумного минимума (например, до 4 или 8). Часто уменьшение количества виртуальных процессоров парадоксальным образом увеличивает скорость работы 1С в разы.

Настройки электропитания и BIOS

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

1. На уровне физического сервера (BIOS/UEFI): Установите режим Static High Performance (Максимальная производительность). Это отключит динамическое управление частотой, которое вносит микрозадержки при выполнении кода 1С.
2. Внутри Windows: Выберите схему управления электропитанием «Высокая производительность» (High Performance).

Диагностика через счетчики производительности

Чтобы подтвердить теорию о дисковых тормозах, воспользуемся монитором ресурсов Windows. Нас интересуют не проценты загрузки, а параметр «Длина очереди диска» и «Время отклика (Latency)».

Если в моменты проведения документа Latency прыгает выше 10–20 мс (для SSD это уже очень много), значит, проблема в физическом хранилище или в контроллере. Проверьте состояние батарейки на RAID-контроллере (BBU) — если она вышла из строя, контроллер отключает кэш на запись, и производительность падает в десятки раз.

Итоги и чек-лист для проверки

Подводя итог, если вы столкнулись со скачками производительности в типовой УТ на виртуалке, пройдите по шагам:

• Проверьте CPU Ready на уровне хоста (не более 5%).
• Ограничьте память для SQL Server и включите Lock Pages in Memory.
• Убедитесь, что в BIOS и в Windows стоит режим High Performance.
• Проверьте задержки диска (Latency) в мониторе ресурсов в моменты лагов.
• Настройте Технологический журнал, чтобы исключить влияние блокировок самой 1С.

Такой комплексный подход позволит вам выявить скрытую причину тормозов, которая не видна в обычном диспетчере задач.