Почему сервер 1С периодически загружает процессор на 100% и как решить эту проблему?

← На главную

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

Феномен виртуального буксования памяти (Memory Thrashing)

Проанализируем ситуацию, описанную администратором на форуме. На виртуальной машине под управлением Hyper-V выделено всего 24 Гб оперативной памяти под сервер 1С. Периодически загрузка процессора подскакивает до 100%, причем нагрузка «размазана» по множеству рабочих процессов rphost, и явного процесса-лидера в диспетчере задач нет. Как только администратор вернул частый (каждые 2 часа) перезапуск рабочих процессов, нагрузка на ЦП снизилась до 60%, а потребление памяти упало.

На первый взгляд это кажется парадоксом: частый перезапуск процессов и миграция сеансов пользователей должны создавать дополнительную нагрузку на процессор. Однако здесь мы имеем дело с классическим эффектом виртуального буксования памяти (Memory Thrashing). Разберем его механику по шагам:

Накопление утечек и фрагментация: Платформа «1С:Предприятие» (особенно устаревших релизов) при длительной непрерывной работе неизбежно накапливает фрагментацию памяти внутри процессов rphost. Объем используемой ОЗУ постепенно растет.
Достижение физического лимита: Когда объем занятой памяти на виртуальной машине приближается к критической отметке (в нашем случае 23.5 Гб из 24 Гб доступных), операционная система Windows Server начинает принудительно вытеснять неактивные страницы памяти из ОЗУ в файл подкачки pagefile.sys на жестком диске.
Постоянные прерывания и Page Faults: Как только пользователям или фоновым заданиям требуются данные, которые только что были сброшены в своп, операционная система вынуждена приостанавливать работу потоков 1С, считывать данные с медленного диска обратно в ОЗУ, вытесняя туда другие страницы. Этот процесс происходит непрерывно тысячи раз в секунду.
Иллюзия загрузки процессора: В этот момент процессор виртуальной машины тратит почти все свое время не на выполнение полезного кода встроенного языка 1С, а на обслуживание прерываний ввода-вывода и диспетчеризацию памяти. В диспетчере задач мы видим 100% загрузку процессора всеми процессами rphost, хотя реальные вычисления в базах данных практически стоят.

Таким образом, перезапуск rphost каждые 2 часа выступал в роли «костыля», который просто высвобождал забитую оперативную память до того, как операционная система уходила в жесткий свопинг. Как только интервал перезапуска увеличили до 24 часов, память забилась, и сервер мгновенно ушел в пике.

Архитектурная ошибка: Избыточное количество процессов rphost

Выясним причину столь быстрого расхода оперативной памяти. В кластере автора настроено обслуживание по схеме «1 информационная база на 1 рабочий процесс». При наличии 22 рабочих процессов на сервере с 24 Гб ОЗУ это является грубейшей системной ошибкой.

Рассмотрим подробнее накладные расходы на содержание инфраструктуры кластера 1С:

Каждый запущенный и активный процесс rphost, даже при отсутствии активных пользователей в базе, требует для своей инициализации от 500 до 800 Мб оперативной памяти. Эти ресурсы уходят на хранение кэша метаданных конфигурации, загрузку программных модулей и инициализацию внутренних структур платформы.
При наличии 22 запущенных процессов rphost только на поддержание «холостого» хода кластера тратится от 11 до 17 Гб оперативной памяти.
В результате на полезную работу пользователей и кэширование реальных данных остается менее половины физического объема ОЗУ ВМ. При возникновении тяжелых отчетов или регламентных заданий память мгновенно переполняется.

Для стабильной работы 100–200 сеансов пользователей оптимальным является наличие всего 2–3 рабочих процессов rphost (примерно один процесс на 50–70 активных сеансов). Это позволит сэкономить более 10 Гб драгоценной оперативной памяти, полностью предотвратит свопинг и снизит паразитную нагрузку на процессор.

Влияние виртуализации Hyper-V и устаревшего железа

В рассматриваемом кейсе используется сервер на базе процессора Intel Xeon X5650. Это архитектура Westmere, выпущенная в 2010 году. Использование виртуализации на столь старом оборудовании накладывает дополнительные жесткие ограничения:

NUMA-архитектура: Процессоры этого поколения критически чувствительны к локальности памяти. Если виртуальной машине выделяется объем оперативной памяти, выходящий за пределы одного физического узла NUMA (или если включена динамическая память), задержки обращения к ОЗУ возрастают лавинообразно. В сочетании с нехваткой памяти это моментально парализует работу сервера приложений.

Сетевой стек виртуализации: Сервер 1С находится внутри виртуальной машины, а СУБД MS SQL Server — на физическом хосте. Общение между ними происходит через виртуальный сетевой адаптер по протоколу TCP/IP. Это создает колоссальные накладные расходы на процессор виртуальной машины, который вынужден постоянно упаковывать и распаковывать сетевые пакеты. Если перенести сервер приложений 1С на физический хост к СУБД, они смогут взаимодействовать по сверхбыстрому протоколу Shared Memory (общая память), минуя сетевые протоколы. Это не только высвободит ресурсы ЦП, но и увеличит общую производительность системы в разы.

Ограничения ПРОФ и КОРП лицензий

Стоит обратить внимание, что тонкая настройка параметров рабочих процессов (таких как количество информационных баз на процесс, лимиты памяти на процесс и т.д.) начиная с платформы версии 8.3.15 требует наличия лицензий уровня КОРП. На лицензиях уровня ПРОФ данные параметры игнорируются платформой или принудительно сбрасываются к дефолтным значениям (не более 8 ИБ на один процесс rphost). Попытка искусственно обойти эти ограничения может приводить к непредсказуемой и нестабильной работе кластера.

Как правильно диагностировать зависания сервера приложений?

Автор темы пытался диагностировать проблему с помощью Технологического журнала (ТЖ), настроив его на события DBMSSQL. Поскольку проблема крылась не в СУБД, а на самом сервере приложений (из-за дефицита памяти и CPU), этот сбор логов ничего не показал.

Для выявления реальных причин высокой нагрузки на стороне 1С необходимо действовать следующим образом:

Шаг 1. Настройка Технологического журнала на сбор процессорного времени. Нам необходимо собирать события CALL и SDBL с фильтрацией по длительности использования процессора CpuTime. Создадим файл конфигурации logcfg.xml следующего содержания:


<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\v8_logs\cpu_heavy" history="24">
    <event filter="CALL">
      <eq property="Name" value="v8.1c.ru/v8/tech-log/CALL"/>
      <gt property="CpuTime" value="10000000"/> <!-- Более 10 секунд CPU -->
    </event>
    <event filter="SDBL">
      <gt property="CpuTime" value="10000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Этот лог покажет нам конкретные методы встроенного языка 1С или неоптимальные запросы СУБД, которые выполняются непосредственно в оперативной памяти сервера приложений и нагружают процессор.

Шаг 2. Анализ системных счетчиков ОС (Performance Monitor). Нам понадобятся следующие показатели:

Memory\Pages/sec — количество страниц в секунду, считываемых или записываемых на диск для разрешения конфликтов виртуальной памяти. Если значение стабильно превышает 100-200, ваша система находится в режиме жесткого свопинга.
Paging File\% Usage — процент использования файла подкачки. Поможет оценить реальный дефицит физической ОЗУ.
Processor Queue Length — длина очереди процессора. Значение, систематически превышающее удвоенное количество ядер процессора, однозначно указывает на нехватку вычислительной мощности.

Комплексный план действий по стабилизации сервера 1С

Для того чтобы полностью избавить сервер от периодических 100% зависаний, необходимо выполнить следующий комплекс мероприятий:

Оптимизировать параметры кластера 1С: Переведите настройки рабочих процессов в режим по умолчанию (или близкий к нему). Установите параметр «Количество ИБ на процесс» равным 8 (или 0 — без ограничений), а «Количество соединений на процесс» — не менее 128. Это позволит сократить число запущенных процессов rphost до 2–3 штук и сэкономит более 10 Гб ОЗУ.
Увеличить объем оперативной памяти: Выделите под виртуальную машину с сервером 1С как минимум 32-48 Гб оперативной памяти, чтобы полностью исключить обращение операционной системы к файлу подкачки в моменты пиковых нагрузок.
Рассмотреть возможность ухода от виртуализации: Если есть техническая возможность, перенесите сервер приложений 1С из виртуальной машины на физический хост, где развернута СУБД MS SQL Server. Настройте их взаимодействие через протокол Shared Memory.
Настроить адекватный перезапуск рабочих процессов: Полностью отключать интервал перезапуска процессов (выставлять значение 0) на старых платформах не рекомендуется из-за фрагментации памяти. Однако и перезапуск каждые 2 часа — это деструктивный костыль. Оптимальным решением является настройка перезапуска процессов один раз в сутки в нерабочее время (например, в 3:00 ночи) со временем принудительного завершения зависших процессов в 600 секунд.