5 分間の技術的な楽しみ | Linux Cgroup 階層ルールの簡単な分析

パート 01 cgroup の概要

#cgroup はコントロール グループです。の略語で、プロセスまたはプロセス グループの物理リソース (CPU、メモリ、デバイス IO など) を制限、分離、およびカウントできる Linux カーネルによって提供されるメカニズムです。 cgroup のユーザー空間管理は cgroup ファイル システムを通じて実現されますが、Linux の仮想ファイル システムのおかげでファイル システムの詳細は隠蔽され、ユーザーは関連する制御ファイルを通じてこの機能の使用を実現します。

cgroup は、2.6 カーネル時代に Google によって導入されました。これは、Linux カーネルにおけるリソース仮想化の技術的基盤であり、LXC (Linux Containers) の基盤です。 ) と Docker コンテナーのテクノロジーの基礎。 cgroup には次の関連概念があります:

• #タスク: #プロセスのエイリアス;
• コントロール グループ: 特定の A 氏によると、規格によって分割された一連のプロセス。 Cgroupにおけるリソース制御はコントロールグループ単位で実現されます。プロセスはコントロール グループに追加したり、あるプロセス グループから別のプロセス グループに移行したりできます。プロセス グループ内のプロセスは、cgroup によって制御グループ単位で割り当てられたリソースを使用でき、cgroup によって制御グループ単位で設定されたリソース制限の対象となります。
• 階層: ツリーを使用して、グループの階層関係を制御します。構造的には、子ノードの制御グループは親ノードのリソース設定属性を継承します。
• サブシステム: サブシステムはリソース制御です。たとえば、CPU サブシステムです。図 1 に示すように、プロセスの CPU 使用時間の割り当てを制御できます。サブシステムが機能するには、レベルに接続する必要があります。サブシステムが特定のレベルに接続されると、このレベルのすべての制御グループがこのサブシステムによって制御されます。

##パート 02 cgroup サブシステム ## cgroup サブシステムはカーネルのバージョンに関連しており、カーネルの反復により、制限できるリソースはますます増えており、一般に次のサブシステムが含まれます。

➤

##blkio：##物理デバイス (ディスク、SSD、USB など) などのブロックデバイスへの入出力アクセスに制限を設定します。 ➤

cpu：CPU スケジュールのタイム スライス割り当てを含めて、プロセスの CPU 使用量を制限します。 ➤

##cpuacct： cgroup 内のタスクによって使用される CPU レポートを自動的に生成します。 ➤

##cpuset：

##独立した CPU (マルチコア システム) とメモリ ノードを cgroup 内のタスクに割り当てます。

➤ devices: cgroup 内のタスク アクセスを許可または拒否します。装置。

➤ 冷凍庫：# #cgroup でタスクを一時停止または再開します。

➤ ##メモリ： cgroup 内のタスクで使用されるメモリ制限を設定し、それらのタスクで使用されるメモリ リソースに関するレポートを自動的に生成します。

➤ ##net_cls： #ネットワーク パケットにクラス識別子を付けると、Linux ワンダリング制御プログラムが特定の cgroup から生成されたパケットを識別できるようになります。 ➤

ns：namespace サブシステム。 パート 03

cgroup 階層ルール cgroup 階層と組み合わせると、ツリーとして理解できます。ツリーの各ノードはプロセス グループであり、各ツリーは 1 つ以上のサブシステムに関連付けられます。ツリーには Linux システム内のすべてのプロセスが含まれますが、各プロセスは 1 つのノード (プロセス グループ) にのみ属することができます。システムには多数の cgroup ツリーが存在する可能性があり、各ツリーは異なるサブシステムに関連付けられます。プロセスは複数のツリーに属することができます。つまり、プロセスは複数のプロセス グループに属することができますが、これらのプロセス グループは異なるサブシステムに関連付けられます。現在、Linux は最大 12 個の cgroup ツリーを構築でき、各ツリーはサブシステムに関連付けられます。もちろん、ツリーを 1 つだけ構築し、このツリーをすべてのサブシステムに関連付けることもできます。 cgroup ツリーがどのサブシステムにも関連付けられていない場合、ツリーはプロセスをグループ化するだけであることを意味し、グループ化に基づいて何を行うかはアプリケーション自体によって決定されます (Systemd がその例です)。

レベルの構成には 4 つのルールがあり、次のように説明されます。

ルール 1: 単一の階層には 1 つ以上のサブシステムを含めることができます。図 1 に示すように、/cpu_memory_cg レベルは、cgroup1 と cgroup2 に対して CPU とメモリの 2 つのサブシステムを設定します。

図 1 階層ルール 1

# ルール 2: サブシステムがすでに 1 つのレベルにアタッチされている場合、それらのサブシステムを別のレベルの構造にアタッチすることはできません。図 2 に示すように、レベル A の cpu_cg が最初に CPU サブシステムを管理します。その後、レベル B の cpu_mem_cg が CPU サブシステムを管理できなくなります。

#図 2 cgroup 階層ルール 2

ルール 3: システム上に新しい階層が作成されるたびに、システム上のすべてのタスクは、最初はその階層のデフォルト cgroup (ルート cgroup と呼ばれます) のメンバーになります。作成された単一の階層では、システム上の各タスクをその階層の cgroup メンバーにすることができます。各 cgroup が異なるサブシステム階層内にある限り、タスクは複数の cgroup 内に存在できます。タスクが同じ階層内の 2 番目の cgroup のメンバーになると、そのタスクは階層内の最初の cgroup から削除されます。つまり、同じ階層内の 2 つの無関係な cgroup が同じタスクを持つことはありません。これは、特定のプロセスに対して特定のタイプの cgroup サブシステムを制限する 1 つの方法にすぎません。最初の階層を作成すると、システム上のすべてのタスクは少なくとも 1 つの cgroup (ルート cgroup) のメンバーとなるため、cgroup を使用する場合、図 3 に示すように、すべてのシステム タスクは常に少なくとも 1 つの cgroup に属します。

#図 3 cgroup 階層ルール 3

ルール 4: システム上で生成されたプロセスはすべて、子プロセス (またはスレッド) を作成します。子プロセスは、その親の cgroup メンバーシップを自動的に継承しますが、必要に応じて他の cgroup に移動できます。移動後は、図 4 に示すように、親プロセスと子プロセスは完全に独立します。

#図 4 cgroup 階層ルール 4

パート 04

cgroup の階層関係の分析

プロセスの観点から開始し、ソース コード内のデータ構造を結合して、cgroups 関連データ間の関係を分析します。まず、Linux では、管理プロセスのデータ構造は task_struct であり、cgroup に関連するメンバーは次のとおりです。

cgroup は、プロセスに関連する cgroups 情報を格納する css_set 構造体を指します。 cg_list は同じ css_set を使用したプロセスリンクリストです。 css_set の構造は次のとおりです。

# # 構造体 body の要素情報は以下のように説明されます。

refcount は複数のプロセスで共有できる css_set の参照数です。これらのプロセスの cgroups 情報が同じである限り。たとえば、作成されたすべての階層内の同じ cgroup 内のプロセス。
hlist は、すべての css_set をハッシュ テーブルに構築するために使用され、カーネルは特定の css_set をすぐに見つけることができます。
#タスクは、この css_set を参照するすべてのプロセスをリンク リストにリンクします。
cg_links は、構造体 cg_group_link で構成されるリンク リストを指します。
subsys は配列です。ポインターのセットには、cgroup_subsys_state へのポインターのセットが格納されます。 cgroup_subsys_state は、プロセスおよび特定のサブシステムに関連する情報です。このポインターを通じて、プロセスは対応する cgroups 制御情報を取得できます。

次に、cgroup_subsys_state 構造体を見てみましょう:

構造体の cgroup ポインタは、cgroup 構造体とプロセスを指します。サブシステムの影響を受ける cgroup は特定のレベルにあり、サブシステムはそのレベルに接続されているため、リソース制御は実際には特定の cgroup サブシステムを追加することによって実現されます。

cgroup の構造を見てみましょう。

• 兄弟、子 親を持つ 3 つのリンクされたリストは、同じレベルの cgroup をツリーに接続する役割を果たします。
• #susys は、前に説明したサブシステム ポインター配列です。
• root は、cgroupfs_root 構造体を指します。これは、cgroup が配置されているレベルに対応する構造体です。
• root->top_cgroup は、現在のレベルのルート cgroup を指します。これは、Fantasy Sword レベルで自動的に作成される cgroup です。 cgroup->root->top_cgroup を通じて階層のルート cgroup を取得できます。
• css_sets は、cg_cgroup_link のリンクされたリストを指します。これは、css_set の cg_links と一致します。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃のためのcss_set と cgroup の関係を理解するには、中間層の cg_cgroup_link 構造も分析する必要があります。構造データは次のとおりです。

##構造内のデータは次のように記述されます:

cgrp_link_list は cgroup->css_sets が指すリンク リストにリンクされます。

cgrp は、この cg_cgroup_link に関連するグループを指します。

cg_link_list は、css_set->cg_links が指すリンク リストにリンクされています。

cg は、cg_cgroup_link に関連する css_set を指します。

cgroup と css_set は実際には多対多の関係であり、この 2 つを結合するには中間構造 cgrp を追加する必要があることがわかります。および cg in cg_group_link 要素はジョイントであり、2 つのリンク リスト cgrp_link_list と cg_link_list は、ポーリングを容易にする接続された cgroup および css_set エンティティです。

cgroup の階層規則から、プロセスのグループが同じレベルにない cgroup に属することができることがわかります。プロセスルートの各サブシステムに関連する情報のグループを保存します。サブシステムは異なる cgroup レベルからのものであるため、css_set に保存される cgroup_subsys_state は複数の cgroup に対応できます。一方、cgroup レベルには、cgroup が配置されているレベルに接続されているサブシステムから取得される cgroup_subsys_state のセットも格納されます。cgroup には複数のプロセスを持つことができ、プロセスの css_set は必ずしも同じである必要はありません。プロセスでは複数のレベルが使用される可能性があるため、cgroup は複数の css_set に対応する必要もあります。図 5 は、多対多のフック関係を詳細に示しています。

#図 5 プロセスと cgroup の多対多の関係図

パート05 結論

この記事は、というコンセプトに基づいています。 cgroup. cgroup とプロセス間の多対多の関係が解体され、読者が cgroup の階層関係と使用法をよりよく理解できるように、関連する構造内の変数のフックからその特定のコード実装が分析されます。

以上が5 分間の技術的な楽しみ | Linux Cgroup 階層ルールの簡単な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。