Приветствуем вас! Каждый администратор баз данных и разработчик 1С рано или поздно сталкивается с ситуацией, когда пользователи начинают жаловаться на внезапные вылеты системы с ошибкой «Недостаточно памяти на сервере 1С:Предприятия» или «Ошибка выделения памяти». Особенно обидно, когда это происходит на мощном физическом сервере, где установлено, например, 130 ГБ оперативной памяти, а диспетчер задач показывает, что свободными остаются еще десятки гигабайт. В этой статье мы подробно разберем, почему так происходит, заглянем «под капот» механизма динамического обновления, выясним физику этого процесса и рассмотрим эффективные методы решения этой проблемы.
Динамическое обновление конфигурации (в обиходе системных администраторов часто именуемое «демоническим») — это удобный инструмент, позволяющий вносить изменения в базу данных без отключения пользователей. Однако за это удобство приходится платить стабильностью работы сервера. Давайте проанализируем, как устроен этот процесс изнутри.
Когда мы нажимаем кнопку «Обновить конфигурацию базы данных» в режиме динамического обновления, сервер 1С не заменяет старую конфигурацию в памяти работающего процесса rphost. Вместо этого происходит следующее:
rphost будет одновременно держать в оперативной памяти 3–5 различных версий одной и той же конфигурации.Для крупных баз (таких как 1С:ERP, 1С:Комплексная автоматизация или 1С:Управление торговлей), где метаданные сами по себе занимают сотни мегабайт, это лавинообразно увеличивает потребление памяти. Старые версии конфигураций выгружаются из ОЗУ только тогда, когда базу покинут абсолютно все пользователи, зашедшие под этой версией.
Проанализируем ситуацию, описанную автором темы: на сервере установлено 130 ГБ оперативной памяти, свободными остаются более 20 ГБ, но пользователи всё равно получают ошибку нехватки памяти. Причина сбоя кроется в использовании 32-разрядной версии сервера 1С:Предприятие и архитектурных ограничениях операционной системы:
rphost физически не может адресовать более 2 ГБ (в редких случаях до 3 ГБ при ручной настройке операционной системы Windows с помощью ключа increaseuserva) виртуальной памяти. Сколько бы физической ОЗУ ни стояло на сервере, один процесс rphost упрется в этот невидимый барьер.rphost сильно фрагментирована. Даже если суммарно внутри процесса есть свободные мегабайты, операционная система не может выделить один большой непрерывный кусок памяти, что и приводит к ошибке (при этом диспетчер задач сервера будет рапортовать о гигабайтах свободной ОЗУ).Перейдем к практическим шагам. Рассмотрим как кардинальные способы решения, так и тонкие настройки, которые помогут обойтись без мгновенных финансовых затрат на покупку лицензий.
Это самый надежный, правильный и рекомендуемый способ. 64-разрядный рабочий процесс rphost способен адресовать практически неограниченный объем оперативной памяти (в пределах возможностей вашей ОС и физического железа). Переход на 64-бита полностью решает проблему фрагментации и лимита в 2 ГБ. Если у вас крупная база данных и много активных пользователей, обновление лицензии сервера до 64-разрядной версии — это первоочередная задача.
Если организация временно не может перейти на 64-битный сервер, мы можем оптимизировать работу существующего 32-битного кластера. Разберем необходимые настройки по шагам:
rphost:
Откроем утилиту «Администрирование серверов 1С:Предприятия». Перейдем в свойства нашего рабочего сервера. По умолчанию параметр «Количество соединений на один рабочий процесс» может быть равен 128 или 256. Уменьшим его (например, до 15-20), а параметр «Количество рабочих процессов» настроим в значение «Авто». Это принудительно запустит на сервере несколько параллельных процессов rphost. Пользователи распределятся между ними. Если один процесс начнет «пухнуть» от накопившихся версий метаданных или тяжелого отчета, это затронет только часть пользователей, а не всю базу.
В свойствах кластера настроим параметр «Интервал перезапуска рабочих процессов» (рекомендуется установить 86400 секунд — раз в сутки). Процессы будут плавно перезапускаться в фоновом режиме, передавая активные сеансы новым процессам без прерывания работы пользователей.
Настроим параметры «Допустимый объем памяти» и «Выключать процессы при превышении лимита». Для 32-битной системы критический порог одного rphost лучше установить в районе 1.5–1.8 ГБ (1500000–1800000 КБ). Как только процесс приблизится к этому порогу, кластер безопасно остановит его и перенаправит сеансы на новые рабочие процессы.
Если пользователи начали массово получать ошибки памяти, выполним процедуру экстренной очистки. Проанализируем действия:
1C:Enterprise 8.3 Server Agent).C:\Program Files (x86)\1cv8\srvinfo) и удалим временные папки кэша (папки формата snccntry*), предварительно убедившись, что не затронуты важные файлы базы данных.%userprofile%\AppData\Local\1C\1Cv8 и %userprofile%\AppData\Roaming\1C\1Cv8.Часто некорректно завершенное динамическое обновление оставляет «мусор» непосредственно в таблицах базы данных SQL. Из-за этого сервер начинает циклически перечитывать метаданные, нагружая память процесса rphost. Опытные администраторы баз данных могут решить эту проблему через СУБД (MS SQL Server Management Studio или pgAdmin для PostgreSQL).
Важно! Перед выполнением любых операций в СУБД обязательно создайте резервную копию вашей базы данных!
Проанализируем и очистим таблицу Config от зависших временных файлов обновления с помощью следующего запроса:
DELETE FROM dbo.Config WHERE FileName = 'commit';
DELETE FROM dbo.Config WHERE FileName = 'dbStruFinal';
После выполнения данного запроса запустим Конфигуратор 1С и выполним стандартное (не динамическое) обновление конфигурации базы данных для восстановления целостности метаданных.
Чтобы избежать подобных проблем в будущем, рассмотрим альтернативные методы внесения изменений, которые предлагает современная платформа «1С:Предприятие 8.3»:
rphost.Применяя данные подходы комплексно, мы сможем полностью избавить пользователей от внезапных вылетов, повысить общую отказоустойчивость системы и сделать работу в 1С комфортной и безопасной!