Рано или поздно каждый системный администратор или специалист 1С сталкивается с ситуацией, когда сервер приложений начинает работать медленно или выдает ошибки нехватки ресурсов. Естественным решением кажется простое физическое увеличение объема оперативной памяти (RAM) на сервере. Однако после апгрейда часто обнаруживается странное поведение системы: 1С начинает потреблять даже меньше памяти, чем раньше, а пользователи продолжают жаловаться на тормоза. Еще хуже, когда при выполнении тяжелых регламентных операций (например, при обновлении конфигурации «1С:Бухгалтерия» с версии 2.0 на 3.0) возникает критическая ошибка: «Превышен максимальный расход памяти сервера за один вызов».
В этой статье мы подробно разберем внутренние механизмы управления памятью в кластере серверов 1С:Предприятие 8.3, выясним причины такого поведения системы и пошагово настроим параметры сервера для обеспечения максимальной производительности.
Проанализируем стандартную ситуацию. На сервере приложений было установлено 8 Гб оперативной памяти. Периодически возникали предупреждения о том, что свободно лишь 200–500 Мб. Администраторы добавили память до 12 Гб (или 16 Гб) и скорректировали лимиты в консоли администрирования 1С. После этого среднее потребление памяти процессами rphost упало до 4–6 Гб. Почему так произошло?
Дело в том, что в условиях жесткого дефицита ресурсов и заниженных лимитов в кластере постоянно срабатывал механизм перезапуска рабочих процессов. Рассмотрим эту схему подробнее:
rphost достигает установленного лимита (например, старого ограничения в 2 Гб), кластер серверов помечает его как «выключаемый» и запускает новый, так называемый «подменный» (дублирующий) рабочий процесс.Когда лимиты были увеличены (например, до 3.9 Гб), процессы перестали постоянно превышать этот порог. Необходимость в частых перезапусках и создании дублирующих процессов отпала. Сеансы стабильно работают в рамках одного процесса rphost, который использует ровно столько памяти, сколько реально необходимо для текущих задач. «Падение» потребления памяти — это признак того, что система перестала совершать лишнюю паразитную работу по постоянной миграции сеансов.
Данная ошибка чаще всего возникает при выполнении объемных транзакций, групповой обработке данных или при переходе на новые редакции конфигураций (например, при обновлении конфигурации «1С:Бухгалтерия» 2.0 на 3.0), когда выполняются тяжелые обработчики обновления.
Выясним причину ее появления. За этот лимит отвечает параметр «Безопасный расход памяти за один вызов» (SafeCallMemoryLimit), который настраивается в свойствах конкретного Рабочего сервера, входящего в кластер (а не в свойствах самого кластера).
Рассмотрим, как платформа рассчитывает этот лимит, если параметры оставлены по умолчанию (равны 0):
0 означает, что лимит рассчитывается автоматически и составляет ровно 5% от значения параметра Максимальный объем памяти рабочих процессов.Максимальный объем памяти рабочих процессов также установлен в значение 0, то платформа принимает его равным 80% от общего объема физической памяти сервера.Для исправления ситуации выполним пошаговую настройку параметров рабочего сервера в консоли администрирования 1С:
localhost или имя вашего сервера приложений).13 500 000 Кб (около 12.8 Гб).-1.4 194 304 Кб (4 Гб) или 6 291 456 Кб (6 Гб). Это гарантирует, что тяжелые процедуры обновления не прервутся.Для стабильной работы сервера приложений 1С недостаточно просто поменять цифры в консоли. Проанализируем сопутствующие факторы, которые напрямую влияют на производительность.
В некоторых версиях платформы (особенно в ветке 8.3.13, например 8.3.13.1513) присутствовали критические ошибки, связанные с утечками памяти в менеджере кластера. В этих релизах изменение параметра «Безопасный расход памяти» в значение -1 могло игнорироваться системой, продолжавшей применять дефолтные 5%. Настоятельно рекомендуется обновить платформу до актуальных стабильных веток (например, 8.3.22 или выше), где алгоритмы распределения ресурсов были существенно переработаны и оптимизированы.
Если сервер приложений 1С и SQL-сервер работают на одной физической или виртуальной машине, они вступают в жесткую конкуренцию за оперативную память. SQL-сервер по умолчанию спроектирован так, чтобы захватить всю доступную оперативную память под свой кэш (Buffer Pool). Если не ограничить аппетиты SQL-сервера, он вытеснит процессы 1С (rphost) в файл подкачки (виртуальную память на диске), что приведет к катастрофическому падению производительности («тормозам» даже на простых операциях).
Правило настройки: Обязательно зайдите в свойства СУБД MS SQL Server (раздел Memory) и жестко ограничьте параметр Maximum server memory. Оставьте операционной системе и процессам 1С как минимум 4–6 Гб свободной памяти (в зависимости от общего объема ОЗУ).
Даже на 64-битных версиях сервера 1С, способных адресовать терабайты памяти, процессы подвержены внутренней фрагментации. Процесс rphost может работать неделями, постепенно накапливая фрагментированные участки. В определенный момент серверу потребуется выделить один непрерывный блок памяти под тяжелую операцию, но из-за фрагментации система не сможет этого сделать, хотя суммарно свободной памяти будет предостаточно. Результат — та же ошибка нехватки памяти.
Решение: Настройте регулярный автоматический перезапуск рабочих процессов. В свойствах кластера серверов задайте параметры:
86400 секунд (раз в сутки, желательно в ночное время).Для автоматизации администрирования можно использовать скрипты перезапуска служб. Рассмотрим пример PowerShell-скрипта, который можно запускать по расписанию через Планировщик задач Windows глубокой ночью для полной очистки кэша памяти:
# Скрипт безопасного перезапуска службы сервера 1С:Предприятие
$ServiceName = "1C:Enterprise 8.3 Server Agent"
Write-Host "Останавливаем службу $ServiceName..."
Stop-Service -Name $ServiceName -Force
Start-Sleep -Seconds 10
# Проверяем, не зависли ли процессы rphost или rmngr, и принудительно их завершаем
$Processes = Get-Process -Name "rphost", "rmngr", "ragent" -ErrorAction SilentlyContinue
if ($Processes) {
Write-Host "Обнаружены зависшие процессы 1С, принудительно завершаем..."
$Processes | Stop-Process -Force
}
Write-Host "Запускаем службу $ServiceName..."
Start-Service -Name $ServiceName
Write-Host "Служба успешно перезапущена!"
Если сервер 1С развернут в среде виртуализации (Hyper-V, VMware vSphere), просто добавить память в свойствах виртуальной машины может быть недостаточно. При высокой нагрузке на гипервизор может включиться механизм динамического распределения памяти (Dynamic Memory / Ballooning), который заберет «неиспользуемую», по мнению гипервизора, память у 1С и отдаст ее соседней ВМ. Когда 1С попытается выполнить тяжелый запрос, возникнет резкая задержка выделения ресурсов.
Рекомендация: Всегда настраивайте жесткое резервирование оперативной памяти (Memory Reservation) в параметрах виртуальной машины с сервером 1С. Это гарантирует, что вся выделенная память физически закреплена за сервером приложений и не будет у него изъята.
Для устранения проблем с памятью на сервере 1С выполните следующие действия:
-1.rphost раз в сутки для борьбы с фрагментацией и утечками памяти.