我的 SLAB 不可回收内存 (SUnreclaim) 无限制地增长,这似乎是我的系统最终耗尽 RAM 并开始尝试交换直至崩溃的原因。这是我几天来的 SReclaim 的图表。在 16GB 服务器上,我的典型 RAM 使用量约为 5GB。当 SReclaim 达到大约 10.xGB 时,无限交换开始。
这些图表显示它不断增长,在这两种情况下,我重新启动它以释放 RAM,然后才导致我的系统自行死亡。
这是第二次重新启动之前的部分平板。
---------------------------------- 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.5GB。
有几个问题:
1)如何确定哪些 SLAB 缓存包含不可回收的 RAM?
2) 我还能做些什么来找出 RAM 不可回收的原因吗?
答案1
弹跳。目前正在解决同样的问题。
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
分配。