Linuxカーネルのスラブキャッシュのクリーニングアルゴリズムを最適化した方法と理由

コンテナの人気が高まり、コントロールグループと組み合わせて使用​​することにより、深刻なスケーラビリティの問題が明らかになり、大型マシンのパフォーマンスが大幅に低下します。 問題は、SLABキャッシュバイパス時間がコンテナの数に二次的に依存し、短時間で大量のメモリをアクティブに消費すると、システムがビジーループに陥り、プロセッサ時間が100％消費される可能性があることです。 今日は、memcgコントロールグループを使用してSLABキャッシュオブジェクトを使用するためのアカウンティングアルゴリズムを変更し、shrink_slab（）関数を最適化することで、この問題を解決した方法を説明します。







カーネル内のプロセスの最適化の問題が発生したのはなぜですか？ すべては、コンテナとメモリ制御グループ（memcg）を積極的に使用しているお客様の1人が、時々発生するCPU消費の奇妙なピークに注意を向けたことから始まりました。 通常のシステム負荷は約50％であり、ピーク時にはプロセッサ時間の100％が使用され、そのほぼすべてがカーネル（sys時間）によって消費されました。

ノード自体はマルチユーザーであり、約200個のOpenVZコンテナーが起動されました。 分析の結果、多数のユーザーがネストされたDockerコンテナーとメモリ制御グループのマルチレベル階層を作成したことがわかりました。 各ユーザーレベルの最上位コンテナには、systemdによって作成された約20個のマウントポイントと20個の制御メモリグループ（memcg）が含まれていました。 さらに、前述のDockerによって作成されたマウントポイントとコントロールグループがありました。 簡単に言えば、ノードの負荷が大きく、その負荷は他のすべての顧客の平均よりもはるかに強かったのです。 同じ問題があまり目立たない混雑していないマシンで発生する可能性があるため、これらのピークが現れる理由を見つけることに興味がありました（たとえば、システム時間+ 5％のピークを与えるとパフォーマンスが低下します）。



perfを操作することで、ピークをキャッチしてトレイルを削除することができました。 プロセッサ時間のほとんどが、スラブキャッシュ、つまりスーパーブロックキャッシュのクリアに費やされていることが判明しました。

- 100,00% 0,00% kswapd0 [kernel.vmlinux] [k] kthread - 99,31% balance_pgdat - 82,11% shrink_zone - 61,69% shrink_slab - 58,29% super_cache_count + 54,56% list_lru_count_one
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、この問題について詳細に説明し、説明する価値があります。 最終的にメモリを解放する前に、カーネルが未使用のデータをしばらくキャッシュすることは誰もが知っています。 カーネルはこの原則を広範に使用します。 たとえば、ページキャッシュにはファイルに関連するデータのページが含まれており、読み取り時にページへの繰り返しアクセスを大幅に高速化します（ディスクに再度アクセスする必要がないため）。 この場合、2つのLRUリスト（s_dentry_lruおよびs_inode_lru）に含まれるスーパーブロックメタデータキャッシュで問題が発生しました。



LRU（最近最も使用されていない）



struct lru_listはリンクリストの配列を指し、各アクティブなmemcgはこの配列の1つの要素（list_lru_one）に対応します。 特定のSLABオブジェクトがカーネルによって使用されなくなると、カーネルはそれを配列のリンクリストの1つに追加します（オブジェクトが属するmemcg、または大まかに言って、このオブジェクトを作成したときに使用されたプロセスのmemcgによって異なります）。 配列自体は次のように記述されます（lru_list :: node :: memcg_lrus）：

 struct list_lru_memcg { struct rcu_head rcu; /* array of per cgroup lists, indexed by memcg_cache_id */ struct list_lru_one *lru[0]; /*    */ }; struct list_lru_one { struct list_head list; /*    */ /* may become negative during memcg reparenting */ long nr_items; /*     */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

lru [0]は、ID 0のmemcgに関連するオブジェクトのリストを示します。

lru [1]は、ID 1のmemcgに関連するオブジェクトのリストを示します。

...

lru [n]は、ID nのmemcgに関連するオブジェクトのリストを示します。



LRUリストs_dentry_lruとs_inode_lruが問題に現れており、名前から推測できるように、未使用のdentryおよびiノードファイルシステムオブジェクトが含まれています。

将来、システムまたは特定のmemcgに十分なメモリがない場合、リスト項目の一部が最終的に解放され、シュリンクと呼ばれる特別なメカニズムがこれを行います。



シュリンク



カーネルがメモリページを割り当てる必要があるが、NUMAノードまたはシステムに空きメモリがない場合、それをクリーニングするメカニズムが開始されます。 彼は、一定量のディスクをスローまたは破棄しようとしています。1）ページキャッシュからファイルのコンテンツのページ。 2）スワップ内の匿名メモリに関連するページ、3）キャッシュされたSLABオブジェクト（発生した問題はそれらに関連しています）。



キャッシュされたSLABオブジェクトの一部を破棄しても、ページのリリースには直接影響しません。原則として、サイズはページサイズよりも大幅に小さく、1ページには何百ものオブジェクトが含まれます。 オブジェクトの一部が解放されると、SLABページに空きメモリギャップが表示され、他のSLABオブジェクトの作成に使用できます。 このアルゴリズムはカーネルで意図的に受け入れられています。シンプルで非常に効率的です。 興味のある読者は、do_shrink_slab（）関数でクリーニングするオブジェクトの一部を選択する式を見ることができます。



この関数は、オブジェクトの一部の実際のクリーニングを実行します。これは、構造体シュリンクで渡された説明に従って行われます。

 static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, struct shrinker *shrinker, int priority) { … /*   */ freeable = shrinker->count_objects(shrinker, shrinkctl); if (freeable == 0) return 0; total_scan = _(freeable); while (total_scan >= batch_size) { /*   */ ret = shrinker->scan_objects(shrinker, shrinkctl); total_scan -= shrinkctl->nr_scanned; } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シュリンクスーパーブロックに関連して、これらの機能は次のように実装されます。 各スーパーブロックは、関連する未使用オブジェクトの独自のs_dentry_lruおよびs_inode_lruリストを保持します。

 struct super_block { ... struct shrinker s_shrink; /* per-sb shrinker handle */ ... struct list_lru s_dentry_lru; struct list_lru s_inode_lru; … };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.count_objectsメソッドは、オブジェクトの数を返します。

 static unsigned long super_cache_count(struct shrinker *shrink, struct shrink_control *sc) { total_objects += list_lru_shrink_count(&sb->s_dentry_lru, sc); total_objects += list_lru_shrink_count(&sb->s_inode_lru, sc); /*     ) */ total_objects = vfs_pressure_ratio(total_objects); return total_objects; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.scan_objectsメソッドは実際にオブジェクトを解放します：

 static unsigned long super_cache_scan(struct shrinker *shrink, struct shrink_control *sc) { /*     s_dentry_lru */ prune_dcache_sb(sb, sc); /*     s_inode_lru */ prune_icache_sb(sb, sc); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

解放するオブジェクトの数はscパラメーターで渡されます。 また、memcgが示されており、そのオブジェクトはLRUからスローされる必要があります。

 struct shrink_control { int nid; /* ID NUMA  */ unsigned long nr_to_scan; /*   */ struct mem_cgroup *memcg; /* memcg */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、prune_dcache_sb（）は配列struct list_lru_memcg :: lru []からリンクリストを選択し、それを使用します。 Prune_icache_sb（）は同じことを行います。



古いシュリンクバイパスアルゴリズム



標準的なアプローチでは、メモリ不足でスラブからオブジェクトを「排出」します

sc-> target_mem_cgroupは次のように発生します。

 shrink_node() { … struct mem_cgroup *root = sc->target_mem_cgroup; /*      sc->target_mem_cgroup  */ memcg = mem_cgroup_iter(root, NULL, &reclaim); do { … shrink_slab(memcg, ...); … } while ((memcg = mem_cgroup_iter(root, memcg, &reclaim))); ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての子memcgを調べて、それぞれに対してshrink_slab（）を呼び出します。 次に、shrink_slab（）関数で、すべてのシュリンクを実行し、それぞれに対してdo_shrink_slab（）を呼び出します。

 static unsigned long shrink_slab(gfp_t gfp_mask, int nid, struct mem_cgroup *memcg, int priority) { list_for_each_entry(shrinker, &shrinker_list, list) { struct shrink_control sc = { .nid = nid, .memcg = memcg, }; ret = do_shrink_slab(&sc, shrinker, ...); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スーパーブロックごとに、独自のシュリンクがこのリストに追加されることを思い出してください。 20個のmemcgとそれぞれ20個のマウントポイントを持つ200個のコンテナがある場合に、do_shrink_slab（）が何回呼び出されるかをカウントしましょう。 合計で、200 * 20のマウントポイントと200 * 20のコントロールグループがあります。 最上位のmemcgに十分なメモリがない場合、そのすべての子memcg（つまり、一般的にすべて）をバイパスするように強制され、それぞれについて、shrinker_listから各シュリンクを呼び出します。 したがって、カーネルはdo_shrink_slab（）関数を200 * 20 * 200 * 20 = 16000000呼び出します。



同時に、この関数の圧倒的な数の呼び出しは役に立たなくなります。通常、コンテナはコンテナ間で隔離され、CT1がCT2で作成されたsuper_block2を使用する可能性は一般的に低くなります。 または、memcg1がCT1からの制御グループである場合、super_block2-> s_dentry_lru-> node-> memcg_lrus-> lru [memcg1_id]配列の対応する要素は空のリストになり、do_shrink_slab（）を呼び出す意味はありません。



この問題は、単純なbashスクリプトを使用してモデル化できます（後でカーネルに渡されるパッチセットからのデータは、ここで使用されます）。

 $echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy $mkdir /sys/fs/cgroup/memory/ct $echo 4000M > /sys/fs/cgroup/memory/ct/memory.kmem.limit_in_bytes $for i in `seq 0 4000`; do mkdir /sys/fs/cgroup/memory/ct/$i; echo $$ > /sys/fs/cgroup/memory/ct/$i/cgroup.procs; mkdir -ps/$i; mount -t tmpfs $is/$i; touch s/$i/file; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュリセットプロシージャを連続して5回呼び出すとどうなるかを見てみましょう。

 $time echo 3 > /proc/sys/vm/drop_caches
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュされたオブジェクトが実際にメモリ内にあるため、最初の反復は14秒続きます： 0.00ユーザー13.78システム0：13.78が 99％CPUを経過しました 。

2番目の反復には5秒かかりますが、オブジェクトはもうありません。0.00user5.59system 0：05.60elapsed 99％CPU。

3番目の反復には5秒かかります： 0.00user 5.48system 0：05.48elapsed 99％CPU

4回目の反復には8秒かかります： 0.00user 8.35system 0：08.35elapsed 99％CPU

5回目の繰り返しには8秒かかります： 0.00user 8.34system 0：08.35elapsed 99％CPU



バニラコアで使用されるシュリンクバイパスアルゴリズムは最適ではないことが明らかになり、スケーラビリティの観点からそれを変更する必要があります。



新しいシュリンクバイパスアルゴリズム



新しいアルゴリズムから、私は以下を達成したかった：

1. 老人の傷から彼を解放し、
2. 新しいロックを追加しないでください。 do_shrink_slab（）は、意味がある場合（つまり、s_dentry_lru配列またはs_inode_lru配列からの対応するリンクリストが空ではない場合）にのみ呼び出しますが、リンクリストメモリには直接アクセスしません。

これは、異種のシュリンクの上にある新しいデータ構造によってのみ提供できることは明らかでした（スーパーブロックシュリンクだけでなく、この記事で説明されていない他のデータオブジェクトもあります。読者は、キーワードprealloc_shrinker（）カーネルコード内）。 新しいデータ構造では、「do_shrink_slab（）を呼び出しても意味があります」と「do_shrink_slab（）を呼び出しても意味がありません」という2つの状態のコーディングが可能になります。



IDAタイプのデータ構造が拒否された理由は 彼らは自身の中でロックを使用します。 ビットフィールドのデータ構造は、この役割に完全に適しています。個々のビットをアトミックに変更でき、メモリバリアと組み合わせて、ロックを使用せずに効率的なアルゴリズムを構築できます。



各シュリンクは独自の一意のID（シュリンク:: ID）を取得し、各memcgは現在登録されているIDの最大IDを含むことができるビットマップを取得します。 最初の要素がs_dentry_lru-> node-> memcg_lrus-> lru [memcg_id]リストに追加されると、対応するmemcgビットマップは番号シュリンク-> idで1ビットに設定されます。 s_inode_idでも同じです。



これで、shrink_slab（）のループは、必要なシュリンクのみをバイパスするように最適化できます。

 unsigned long shrink_slab() { … for_each_set_bit(i, map, shrinker_nr_max) { … shrinker = idr_find(&shrinker_idr, i); … do_shrink_slab(&sc, shrinker, priority); … } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ビットクリーニングは、シュリンクが「do_shrink_slab（）を呼び出しても意味がありません。詳細については、Githubのコミットを参照してください。



キャッシュリセットテストを繰り返した場合、新しいアルゴリズムを使用すると、大幅に優れた結果が示されます。

 $time echo 3 > /proc/sys/vm/drop_caches
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の反復： 0.00user 1.10system 0：01.10elapsed 99％CPU

2回目の反復： 0.00user 0.00system 0：00.01elapsed 64％CPU

3回目の反復： 0.00user 0.01system 0：00.01elapsed 82％CPU

4回目の反復： 0.00user 0.00system 0：00.01elapsed 64％CPU

5回目の反復： 0.00user 0.01system 0：00.01elapsed 82％CPU

2回目から5回目の繰り返しの期間は0.01秒で、 以前よりも548倍高速です。



マシンのメモリ不足ごとにキャッシュをリセットする同様のアクションが発生するため、この最適化により、多数のコンテナとメモリ制御グループを持つマシンの動作が大幅に改善されます。 パッチのセット （17個）がバニラコアに受け入れられており、バージョン4.19からそれを見つけることができます。



パッチをレビューする過程で、Googleの従業員が現れ、同じ問題を抱えていることが判明しました。 そのため、パッチは異なるタイプの負荷でさらにテストされました。

その結果、パッチセットは9回目の反復から採用されました。 そして、バニラコアへの進入には約4か月かかりました。 また、今日、パッチセットはバージョンvz7.71.9以降の独自のVirtuozzo 7カーネルに含まれています。