☰

SLAB回収不能メモリを無限に増やす原因をどのように知ることができますか？

tag-icon • tag-icon linux cache ram
SLAB回収不能メモリを無限に増やす原因をどのように知ることができますか？

私のSLAB回収不能メモリ（SUnreclaim）は無制限に増えていますが、これが私のシステムが最終的にRAMが不足してクラッシュするまで交換を試み始める理由のようです。これは過去数日間のSReclaimチャートです。 16GB サーバーでは、一般的な RAM 使用量は約 5 GB です。 SReclaimが約10.xGBに達すると、無制限の交換が開始されます。

グラフはますます大きくなっていることを示しています。どちらの場合も、システムが自発的に死ぬ前にRAMを確保するために再起動しました。

ここに画像の説明を入力してください。

これは、2番目の再起動前のスラブの一部です。

---------------------------------- 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。

おすすめ記事