← На главную

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

Анализ причин роста потребления памяти

Менеджер кластера rmngr является «мозгом» всей инфраструктуры 1С. Он отвечает за хранение информации о сеансах, соединениях, блокировках и конфигурациях. Рост его аппетитов к RAM обычно связан со следующими факторами:

1. Формат журнала регистрации: Одним из самых частых виновников в версиях платформы 8.3.8 – 8.3.11 является использование формата SQLite для хранения журнала регистрации. Он часто приводит к постепенной утечке памяти, которую сложно отследить без перезапуска службы.
2. Накопление сеансовых данных: Если в системе много зависших сеансов или ошибок, связанных с их некорректным закрытием, rmngr вынужден держать эти данные в оперативной памяти.
3. Объем метаданных: При работе большого количества конфигураций или активном использовании расширений кэш метаданных, удерживаемый менеджером, может достигать значительных размеров.

Шаг 1: Проверка и настройка журнала регистрации

Если вы используете версию платформы 8.3.11 и ниже, первым делом обратите внимание на журнал регистрации. Как показывает практика, переход на классический текстовый формат lgf позволяет существенно снизить нагрузку на память.

Разберем, как минимизировать негативное влияние ЖР:

• Чистка журнала: Регулярно проводите архивацию и удаление старых записей. Даже если вы не меняете формат, сокращение объема хранимых данных помогает уменьшить нагрузку на процесс менеджера кластера.
• Переход на текстовый формат: Начиная с версии 8.3.12, компания 1С вернула возможность использования текстового формата по умолчанию. Если ваша версия платформы позволяет, настройте использование формата lgf в консоли администрирования серверов 1С. Это стандарт, проверенный годами, который работает надежно и предсказуемо.

Шаг 2: Мониторинг и перезапуск служб

Если проблема сохраняется, стоит внедрить практику планового обслуживания. Помните, что rmngr не всегда эффективно «отдает» память обратно в операционную систему после выполнения ресурсоемких задач.

Рекомендации по обслуживанию:

1. Плановый перезапуск: Если объем памяти, занимаемой rmngr, стабильно растет, рассмотрите возможность еженедельного перезапуска службы сервера 1С в часы минимальной нагрузки (например, в ночь на воскресенье). Это простой, но самый эффективный способ «очистки» памяти и сброса кэшей.
2. Наблюдение за ростом: После перезапуска замерьте объем памяти, который занимает rmngr. Если через короткий промежуток времени он снова достигает критических значений, это повод для более глубокого анализа дампов памяти или обращения к техническим специалистам.

Шаг 3: Техническая оптимизация кластера

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

• Анализ сеансовых данных: Убедитесь, что в системе нет «зависших» сеансов. Используйте встроенные средства администрирования для проверки времени жизни сеансов и их активности.
• Разделение баз: Если на одном кластере работает очень много информационных баз, подумайте об их разделении на несколько независимых кластеров. Это позволит локализовать проблему потребления памяти: если один менеджер кластера начнет потреблять избыточные ресурсы, это не затронет работу других баз.
• Настройка регламентных процедур: Установите корректные лимиты на потребление памяти рабочими процессами rphost. Хотя rmngr — это отдельный процесс, общая нагрузка на сервер часто бывает взаимосвязана.

Подводим итоги

Потребление оперативной памяти процессом rmngr на уровне 30-45 Гб является аномальным для большинства стандартных конфигураций, но может встречаться в нагруженных средах. Начните с перехода на текстовый журнал регистрации и организации периодического перезапуска сервера. Если же эти методы не помогают, мы рекомендуем собрать дампы памяти в момент пикового потребления и проанализировать их совместно с системными администраторами для выявления специфических объектов, удерживающих память.

Помните: стабильность системы важнее постоянной работы без перезагрузок. Плановое обслуживание — это не признак слабости инфраструктуры, а признак зрелого подхода к администрированию 1С.