Каждый системный администратор или разработчик 1С рано или поздно сталкивается с парадоксальной ситуацией: на сервере установлены десятки или даже сотни гигабайт оперативной памяти, диспетчер задач показывает большой объем доступной ОЗУ, но платформа 1С упорно завершает работу с ошибкой «Недостаточно свободной памяти на сервере 1С». Особенно часто эта проблема проявляет себя при запуске тяжелых отчетов или обработок в базах на управляемых формах, в то время как старые конфигурации на обычных формах продолжают работать как ни в чем не бывало.
В этой статье мы подробно разберем, почему операционная система Windows Server блокирует выделение памяти для 1С, почему управляемые формы настолько чувствительны к этому механизму, и как пошагово решить эту проблему раз и навсегда.
Для начала проанализируем, как операционная система Windows управляет оперативной памятью. Вся физическая ОЗУ распределяется по нескольким категориям:
По заверениям Microsoft, память из категории Standby является «доступной». Это значит, что как только любому приложению (например, рабочему процессу 1С rphost) потребуется память, диспетчер операционной системы должен мгновенно очистить кэш и передать ресурсы программе. Однако на практике этот алгоритм часто дает сбой по следующим техническим причинам:
Standby сильно фрагментирован, операционная система физически не успевает быстро пересобрать и дефрагментировать свободные страницы памяти в один сплошной кусок. В результате процесс получает отказ выделения памяти и аварийно завершается.Многие замечают, что в одной и той же среде старая конфигурация (например, Управление торговлей 10.3) работает стабильно, а новые (Бухгалтерия предприятия 3.0 или ЗУП 3.1) регулярно вылетают. Выясним причину такого поведения.
Обычные формы используют преимущественно двухзвенную архитектуру, где основные расчеты интерфейса происходят на стороне клиента, а данные передаются порциями. Управляемые формы построены на строгом трехзвенном принципе с жестким разделением контекста:
rphost и отправляются обратно. Этот процесс порождает колоссальное количество временных объектов в памяти.rphost операционная система выделяет максимум 2 ГБ (в редких случаях с ключом оптимизации — до 3 ГБ) виртуального адресного пространства. При формировании отчета на управляемых формах этот лимит исчерпывается за секунды. Даже если на физическом сервере свободно 256 ГБ ОЗУ, 32-битный процесс физически не может адресовать более 2 ГБ и падает с ошибкой нехватки памяти.---
Для построения отказоустойчивой системы нам необходимо применить комплексный подход: устранить архитектурные ограничения, правильно распределить ресурсы между СУБД и 1С, а также автоматизировать очистку неэффективного кэша операционной системы.
Это главное и наиболее эффективное решение. Если вы используете 32-битную платформу сервера 1С, ее необходимо заменить на 64-битную. 64-разрядные процессы rphost практически не имеют лимита на размер виртуального адресного пространства (ограничение составляет более 8 ТБ), что полностью нивелирует проблему нехватки непрерывных блоков памяти в пределах 2 ГБ.
Если СУБД MS SQL Server и сервер приложений 1С установлены на одном физическом или виртуальном сервере, они начинают вести войну за оперативную память. SQL Server по умолчанию настроен на захват всей доступной ОЗУ под свой буферный пул. Чтобы избежать этого, выполним следующие действия:
Для предотвращения утечек памяти и повышения стабильности настроим параметры рабочих процессов в консоли администрирования кластера 1С:
rphost. Если в одной из баз произойдет критический сбой или утечка памяти, упадет только один рабочий процесс, а пользователи других баз продолжат работу без прерывания сеанса.rphost (например, 80-90% от выделенного серверу объема), по достижении которого сервер 1С мягко перезапустит процесс, перенаправив пользователей на новый, "чистый" экземпляр.86400 секунд, что равняется 24 часам). Это позволит раз в сутки полностью обновлять процессы и очищать накопленные утечки памяти, вызванные несовершенством кода конфигураций.Чтобы операционная система не накапливала гигабайты неиспользуемого кэша, который мешает выделению памяти процессам 1С, настроим автоматическую очистку с помощью утилиты EmptyStandbyList.exe. Это консольная утилита, работающая быстрее и эффективнее, чем графический RAMMap.
Рассмотрим процесс настройки автоматизации по шагам:
EmptyStandbyList.exe и сохраним ее в системную папку, например, C:\Tools\.clear_ram.bat.
@echo off
C:\Tools\EmptyStandbyList.exe workingsets
C:\Tools\EmptyStandbyList.exe standbylist
Этот скрипт сначала оптимизирует рабочие наборы простаивающих служб и приложений (перенося их неиспользуемые страницы в файл подкачки), а затем полностью очищает список ожидания (Standby-кэш), переводя эту память в статус абсолютно свободной.
В качестве альтернативного варианта для автоматического фонового мониторинга можно рассмотреть утилиту ISLC (Intelligent Standby List Cleaner). Она работает как служба и очищает Standby-список автоматически, как только объем свободной памяти опускается ниже заданного вами порога.
Мы выяснили, что падение 1С с ошибкой нехватки памяти при наличии свободных ресурсов — это комплексная проблема несовместимости 32-битных процессов с аппетитами управляемых форм и неэффективного кэширования Windows. Перевод сервера 1С на 64-разрядную архитектуру, жесткое квотирование памяти СУБД и внедрение скрипта автоматической очистки Standby-листа гарантируют бесперебойную работу вашей системы даже при самых тяжелых аналитических нагрузках.