Как узнать, что делает мою SLAB Unreclaimable Memory бесконечно растущей?

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

Моя SLAB-некоторые память (SUnreclaim) растет безгранично, и это, по-видимому, является причиной, по которой моя система в конце концов выходит за пределы RAM и начинает обмен до тех пор, пока не умирает. Вот график моего SUreclaim за несколько дней. Мое типичное использование RAM составляет около 5 ГБ на сервере с 16 ГБ. Когда SUreclaim достигает около 10.x ГБ, начинается бесконечный обмен.

Эти графики показывают его бесконечный рост и мое перезапуск системы для освобождения RAM, в этих 2 случаях, до того, как она приводит мою систему к ее смерти.

введите описание изображения

Вот частичный slabtop непосредственно перед вторым перезапуском.

---------------------------------- 20180730164416 ----------------------------------
 Active / Total Objects (% used)    : 34014938 / 35150125 (96.8%)
 Active / Total Slabs (% used)      : 1098114 / 1098114 (100.0%)
 Active / Total Caches (% used)     : 120 / 147 (81.6%)
 Active / Total Size (% used)       : 7332279.93K / 7831039.90K (93.6%)
 Minimum / Average / Maximum Object : 0.01K / 0.22K / 22.88K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
8433792 8349318  98%    0.06K 131778       64    527112K pid                    
4253942 4250995  99%    0.09K  92477       46    369908K anon_vma               
3011640 2929311  97%    0.20K 150582       20    602328K vm_area_struct         
2994831 2908345  97%    0.19K 142611       21    570444K dentry                 
2068096 2033715  98%    0.03K  16157      128     64628K kmalloc-32             
1953024 1932838  98%    0.02K   7629      256     30516K kmalloc-16             
1820128 1618465  88%    0.25K 113758       16    455032K filp                   
1149438 1149438 100%    0.04K  11269      102     45076K pde_opener             
1014336 891822  87%    0.06K  15849       64     63396K kmalloc-64             
954051 953969  99%    0.19K  45431       21    181724K cred_jar               
757224 752612  99%    0.10K  19416       39     77664K buffer_head            
627368 627368 100%    0.07K  11203       56     44812K eventpoll_pwq          
564900 535453  94%    0.09K  13450       42     53800K kmalloc-96             
372690 336229  90%    0.13K  12423       30     49692K kernfs_node_cache      
362528 362365  99%    0.12K  11329       32     45316K seq_file               
329937 327195  99%    1.06K  21455       30    686560K signal_cache         

task_struct также обычно очень высок и обычно составляет около 1.5 ГБ до того, как я должен перезапускаться.

Несколько вопросов:
1) Как определить, какие SLAB-кэши содержат некогда RAM?
2) Есть ли что-то еще, что я могу сделать, чтобы выяснить, почему RAM не может быть восстановлен?

Отклик. В настоящее время разбираюсь с той же проблемой.

 Active / Total Objects (% used)    : 27175932 / 27473124 (98.9%)
 Active / Total Slabs (% used)      : 844076 / 844076 (100.0%)
 Active / Total Caches (% used)     : 77 / 108 (71.3%)
 Active / Total Size (% used)       : 12915527.98K / 12995852.27K (99.4%)
 Minimum / Average / Maximum Object : 0.01K / 0.47K / 15.25K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
24418488 24418393  99%    0.50K 763083       32  12209328K kmalloc-512
853984 853984 100%    0.12K  26687       32    106748K kmalloc-128
801528 643979  80%    0.19K  19085       42    152680K kmalloc-192
401792 401792 100%    0.06K   6278       64     25112K kmalloc-64

kmalloc-512 кажется виновником. Включена опция отладки ядра для отслеживания kmalloc-512 выделения.

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

Теория

SLAB-аллокатор в Linux является механизмом управления памятью, который упрощает и ускоряет выделение и освобождение объектов фикcированного размера. В памяти системы существуют SLAB-кэши, которые разделяются на reclaimable (восстанавливаемые) и unreclaimable (невосстанавливаемые). SUnreclaim (SLAB Unreclaimable Memory) представляет собой объем памяти, который не может быть освобожден и возвращен системе.

Непрерывный рост SUnreclaim может указывать на проблему с памятью, вызванную утечками или неверным управлением памятью на уровне ядра или приложения. Безграничный рост этой памяти приводит к тому, что операционная система вынуждена использовать свопинг, чтобы освободить пространство, что заметно снижает производительность и, в конечном итоге, может привести к краху системы.

Пример

В предоставленных данных основной рост SLAB Unreclaimable Memory наблюдается в кэше kmalloc-512, что показывает значительное потребление памяти в этой области. Кроме того, отмечается высокая активность в таких кэшах, как pid, anon_vma, и vm_area_struct, что требует внимания, поскольку их потребление памяти также значительно.

Применение

  1. Определение проблемных SLAB-кэшей:

    • Используйте утилиту slabtop, чтобы определить кэши, которые занимают наиболее значительное количество невосстанавливаемой памяти. Обратите внимание на процент использования, общий размер, и наиболее активные объекты.
  2. Диагностика и отладка:

    • Включите режим отладки в вашем ядре Linux, чтобы отслеживать выделение памяти для определенных SLAB-кэшей. Это может быть выполнено путем редактирования конфигурации ядра и активации соответствующих флагов отладки, таких как CONFIG_DEBUG_SLAB и CONFIG_DEBUG_KMEMLEAK.
  3. Анализ использования приложения:

    • Проверьте ваши приложения и процессы, чтобы выявить потенциальные утечки памяти. Инструменты профилирования, такие как Valgrind или санитайзеры (AddressSanitizer), могут помочь в выявлении утечек на уровне приложений.
  4. Обновление и оптимизация:

    • Убедитесь, что используемая вами версия ядра Linux и серверное ПО обновлены до последних версий, так как потенциальные проблемы с памятью могут быть исправлены в более новых релизах.
  5. Мониторинг и управление ресурсами:

    • Настройте систему мониторинга (например, Prometheus, Grafana), чтобы наблюдать за использованием SLAB памяти в реальном времени. Это поможет оперативно реагировать на возрастание потребления и предотвратить возможные проблемы.

Заключение: Детальная диагностика вашего окружения, отладка ядра и контроль за использованием памяти критически важны для решения проблемы безграничного роста SLAB Unreclaimable Memory.

Оцените материал
Добавить комментарий

Капча загружается...