- Вопрос или проблема
- Ответ или решение
- 1. Анализ начальных данных
- 2. Поиск источников утечки памяти
- 2.1. Пользовательские процессы
- 2.2. Проверка инкапсулированных процессов
- 2.3. Мониторинг системных вызовов
- 2.4. Проверка приложений
- 3. Анализ системных логов
- 4. Предложения по улучшению мониторинга
- 5. Патчинг и обновление
- 6. Обратная связь с сообществом
- Заключение
Вопрос или проблема
У меня есть сервер Rocky9 (похожий на RHEL) с рабочей нагрузкой только NFS.
Очевидно, есть утечка памяти, и процент использования памяти MemUsed% поступательно увеличился с 1% до 99%. Но нет программ в пространстве пользователей, использующих память (oom-killer убил почти все, прежде чем система зависла), и также лептонизм довольно низкий. Как выяснить, кто съел память?
Уже обновлён до актуальной версии из репозитория дистрибутива. Также пробовал последний ванильный ядро LTS из el-repo.
/proc/meminfo за несколько мгновений до того, как произошла OOM и сбой:
MemTotal: 394292660 kB
MemFree: 1551296 kB
MemAvailable: 6776108 kB
Buffers: 1712 kB
Cached: 7340144 kB
SwapCached: 4308 kB
Active: 325936 kB
Inactive: 7071836 kB
...
KReclaimable: 129816 kB
Slab: 331596 kB
SReclaimable: 129816 kB
SUnreclaim: 201780 kB
...
VmallocUsed: 319528 kB
Подал сообщение об ошибке на kernel.org, но ответа не последовало даже через неделю. Логи, такие как dmesg, vmallocinfo и lsmod, были прикреплены туда.
Ответ или решение
Диагностика и устранение OOM (Out Of Memory) на сервере Rocky 9 с низкой нагрузкой
Ситуация, с которой вы сталкиваетесь на вашем сервере Rocky 9, является сложной, однако есть несколько шагов, которые вы можете предпринять для поиска источника утечки памяти и устранения проблемы. Проанализируем ваше описание более подробно.
1. Анализ начальных данных
Согласно предоставленным данным /proc/meminfo, наблюдается следующая картина:
- MemTotal: 394,292,660 кБ
- MemFree: 1,551,296 кБ
- MemAvailable: 6,776,108 кБ
- Cached: 7,340,144 кБ
- Active: 325,936 кБ
- Inactive: 7,071,836 кБ
- Slab: 331,596 кБ
- VmallocUsed: 319,528 кБ
Эти значения показывают, что система фактически использовала почти все доступные ресурсы, что свидетельствует о возможной утечке памяти, хотя на первый взгляд активные процессы не отображают использования значительных ресурсов.
2. Поиск источников утечки памяти
2.1. Пользовательские процессы
Убедитесь, что в системе нет процессов, использующих аномальное количество памяти. Используйте команды top, htop или ps aux для получения информации о текущих процессах. Обратите внимание на столбец RSS (Resident Set Size) и VSZ (Virtual Memory Size).
ps aux --sort=-%mem | head -n 102.2. Проверка инкапсулированных процессов
Некоторые процессы в Linux, в том числе ksoftirqd, могут использовать память, но не отображаются в стандартном выводе. Вы можете использовать cat /proc/[pid]/status для каждого процесса с высоким RSS, чтобы понять, сколько памяти используется.
2.3. Мониторинг системных вызовов
Используйте strace, чтобы отследить системные вызовы и выявить потенциальные утечки. Это потребует запустить strace на подозреваемых процессах и проанализировать их исключения и ошибки.
2.4. Проверка приложений
Поскольку вы упомянули о NFS, проверьте конфигурации и параметры кэша. Иногда проблемы могут исходить от некорректной конфигурации NFS или от использования нестабильных версий клиентских и серверных приложений.
3. Анализ системных логов
Логи системы могут содержать важную информацию о том, что происходило перед срабатыванием OOM. Проверьте следующие файлы:
/var/log/messages/var/log/syslog/var/log/dmesg
Эти логи могут предоставить контекст относительно затухающих процессов и других системных событий.
4. Предложения по улучшению мониторинга
Установите утилиты для мониторинга использования памяти в реальном времени, такие как free, vmstat и sar. Это даст вам возможность отслеживать использование ресурсов и время возникновения всплесков памяти.
5. Патчинг и обновление
Учитывая, что вы уже использовали последние версии ядра, убедитесь, что все зависимости и конфигурации на сервере также обновлены. Иногда проблемы могут происходить из-за устаревших библиотек или неправильных конфигураций NFS.
6. Обратная связь с сообществом
Поскольку вы подали отчет об ошибке на kernel.org, присоединяйтесь к обсуждениям и ищите похожие случаи в других ресурсах (форумы, стек операторов). Можно также обратиться к сообществу Rocky Linux и обсудить обнаруженные проблемы.
Заключение
Устранение проблемы утечки памяти на сервере Rocky 9 требует системного подхода. Следуя предложенным шагам, вы сможете постепенно установить источник проблемы и оптимизировать использование ресурсов системы. Удачи в вашем анализе, и не забывайте, что системное администрирование всегда требует бдительности и готовности к поиску нестандартных решений.