RHEL + systemctl service показывает значительно большее использование памяти, чем PID процесса.

Вопрос или проблема

systemctl status presto.service
● presto.service - Perforce Server
.
.
.
 Main PID: 3683651 (presto-server)
    Tasks: 284 (limit: 3297083)
   Memory: 298.1G 
   CGroup: /system.slice/presto.service

more /sys/fs/cgroup/memory/system.slice/presto.service/memory.usage_in_bytes
31329787904 --> ~32G

[Service]
User=presto
Group=presto_group
MemoryMax=64000M
MemoryHigh=60000M

# The type should always be set to "forking" to support
# multiple Perforce processes:
Type=forking


# The command used to start Perforce:
ExecStart=/home/presto/server/bin/launcher start
ExecStop=/home/presto/server/bin/launcher stop

Restart=always
RestartSec=30s
StartLimitInterval=0
StartLimitBurst=5

RemainAfterExit=no
LimitNOFILE=65536

[Install]
# Describes the target for this service -- this will always
# be 'multi-user.target':
WantedBy=multi-user.target

Ответ или решение

Ваша проблема касается разницы в отображении использования памяти между выводом systemctl status и фактическим потреблением памяти PID в RHEL 8.6 при работе с системой и службой, такой как Presto.

Теория

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

• CGroup (Control Groups): Контролируют и ограничивают ресурсы, такие как CPU и память, выделенные для набора процессов. CGroups также следят за памятью, используемой дочерними процессами.

• Ожидание и кэш: CGroups могут учитывать не только активное использование памяти, но и файловый кэш, буферы и другие ресурсы памяти, которые могут оставаться неиспользованными, но зарезервированными процессом.

• Различие в отображении: Параметры, такие как MemoryMax и MemoryHigh, влияют на то, сколько памяти может быть выделено в группе CGroup, что может отражаться как превышение лимитов в systemctl status.

Пример

В вашем случае, systemctl status может отображать память, включающую как память непосредственно инициирующего процесса, так и всех его дочерних процессов, а также общую память, выделенную, но всё ещё не полностью использующуюся, включая кэш и другие вспомогательный данные, поддерживаемые CGroup.

1. Direct Memory Consumption by PID:

   • Команда more /sys/fs/cgroup/memory/system.slice/presto.service/memory.usage_in_bytes возвращает память, фактически используемую процессом в данный момент времени. Она может не учитывать память, используемую дополнительными или дочерними процессами.

2. Memory Displayed by Systemctl:

   • systemctl status часто показывает предельное использование памяти, которое может включать резервную память, которая была когда-либо выделена процессу или его дочерним процессам.

Применение

Для лучшего понимания и управления памяти, есть несколько шагов:

1. Мониторинг с использование инструмента иллюстрации процессов, таких как htop или top: Эти утилиты позволяют отслеживать использование памяти в режиме реального времени, показывая, как виртуальная и резидентная память распределяются по процессам.

2. Конфигурирование CGroup границ:

   • Указание ключей MemoryMax и MemoryHigh помогает управлять пределами памяти CGroup. Это предотвратит использование процессом избыточных ресурсов, но также это может быть причиной, по которой отображается больше выделенной памяти, чем фактически используется.

[Service]
User=presto
Group=presto_group
MemoryMax=64000M
MemoryHigh=60000M

3. Анализа логов системы и CGroup:

   • Пересмотрите журналы, доступные в /var/log/messages, а также файлы логов, связанные с Presto и системными процессами для понимания, когда память выделялась и освобождалась.

4. Проверка вариантов Parallel/Threading в Presto:

   • В конфигурациях или текущих запусках убедитесь, что Presto эффективно работает с потоками и задачами, с минимальной ненагруженной памятью.

5. Понимание системных служб:

   • Каталог ExecStart и его скрипты могут генерировать дополнительные задачи или дочерние процессы, которые создают блоки, потребляющие виртуальную память.

Итак, ваша ключевая задача — контролировать и корректировать параметры CGroup, настроить конфигурации конту, чтобы исключить лишние затраты на память и обеспечить эффективное распределение ресурсов. Черпайте лучшее из инструментов мониторинга, чтобы своевременно реагировать на изменения в системе использования памяти.