コア Cgroups 関連の概念と Docker コンテナの実装のクラウドネイティブの詳細な分析

1. Cgroup の概要

Cgroupsは、Linuxシステムカーネルが提供する仕組みで、一連のシステムタスクやマシンサブタスクを、要件に応じてリソース区分ごとに登録された異なるグループに統合または分離することで、システムリソース管理の枠組みを提供します。簡単に言えば、Cgroup は、タスクグループが使用する物理グループメンバー (CPU、メモリ、IO など) を制限および記録することができ、コンテナ仮想化の基本的な保証を提供し、次のような一連の仮想化管理ツールを構築する基礎となります。ドッカーとして。
2013 年のオープンソース Docker の発売と 2014 年のオープンソース Kubernetes の出現から、現在のクラウドネイティブテクノロジとエコシステムの普及と人気に至るまで、コンテナテクノロジは徐々に主流の基本的なクラウドネイティブの 1 つになりました。テクノロジー。コンテナーテクノロジーを使用すると、リソースレベルの制限と分離を十分に実現できます。これらはすべて、Linux システムカーネルによって提供される Cgroup および名前空間テクノロジーに依存します。
Cgroup は主にリソースの割り当てと制限を管理するために使用され、Namespace は主にリソースの抽象化、制限、分離をカプセル化して、名前空間内のプロセスが独自のグローバルリソースを持つようにするために使用されます。Linux カーネルによって提供される Cgroup および Namespace テクノロジは、コンテナ仮想化の基本的な保証を提供し、Docker などの一連の仮想化管理ツールを構築する基礎となります。
Cgroups はコントロールグループの略で、プロセスグループが使用する物理リソース (CPU、メモリ、IO など) を制限、記録、隔離するために Linux カーネルによって提供されるメカニズムです。

ここに画像の説明を挿入

Cgroup を使用すると、システム管理者は、システムリソースの割り当て、並べ替え、拒否、管理、監視をきめ細かく制御できます。ハードウェアリソースをアプリケーションとユーザー間でインテリジェントに割り当てることができるため、全体的な効率が向上します。これはもともと Google のエンジニアによって提案され、後に Linux カーネルに統合されました。Linux カーネルは、現在の軽量仮想化テクノロジ XC (Linux Container) の基礎の 1 つでもあります。
Cgroups はプロセスをグループ化するという点で Namespace に似ていますが、その目的は Namespace とは異なります。Namespace はプロセスグループ間でリソースを分離するのに対し、Cgroups はプロセスのグループに対して統合されたリソースの監視と制限を実行します。
Cgroups は v1 と v2 の 2 つのバージョンに分かれており、v1 のほうが先に実装されており、機能も充実していますが、機能が分散して実装されているため、計画性が低く、使用上やメンテナンス上で不便な点があります。 , v2 の登場は、v1 でのこの問題を解決することです。最新の 4.5 カーネルでは、Cgroups v2 は実稼働環境で使用できると主張していますが、サポートされる機能はまだ非常に限られています。Cgroups、Namespace、v1、およびv2 を混在させることもできますが、より複雑になるため、一般的には誰も使用しません。

2. Cgroups の主な構造

Cgroups は、Linux の下でグループ内のプロセスを管理するためのメカニズムです。ユーザー層の観点から見ると、Cgroups テクノロジは、システム内のすべてのプロセスを独立したツリーに編成します。各ツリーには、システムのすべてのプロセスが含まれます。ツリーの各ノードはプロセスグループであり、各ツリーは 1 つ以上のサブシステムに関連付けられています。ツリーの機能はプロセスをグループ化することであり、サブシステムの機能はこれらのグループを操作することです。Cgroup の主な構造は次のとおりです:

ここに画像の説明を挿入

Cgroup には主に次の 2 つの部分が含まれます。
- サブシステム: サブシステムはカーネルモジュールであり、cgroup ツリーに関連付けられると、ツリーの各ノード (プロセスグループ) で特定の操作を実行します。サブシステムは、主に各プロセスグループのリソースをスケジュールしたり制限したりするために使用されるため、リソースコントローラーと呼ばれることがよくありますが、この記述は完全に正確ではありません。なぜなら、監視を行ったりステータスを監視したりするためだけにプロセスをグループにグループ化することがあるためです。 perf_event サブシステム。これまでのところ、Linux は、CPU 使用時間の制限、メモリ使用量の制限、CPU 使用量のカウント、プロセスグループのフリーズと再開など、12 のサブシステムをサポートしています。
- 階層: 階層は cgroup ツリーとして理解でき、ツリーの各ノードはプロセスグループであり、各ツリーは 0 個以上のサブシステムに関連付けられています。ツリーには Linux システム内のすべてのプロセスが含まれますが、各プロセスは 1 つのノード (プロセスグループ) にのみ属することができます。システムには多数の cgroup ツリーが存在する可能性があり、各ツリーは異なるサブシステムに関連付けられます。プロセスは複数のツリーに属することができます。つまり、プロセスは複数のプロセスグループに属することができますが、これらのプロセスグループは異なるサブシステムに関連付けられます。
現在、Linux は 12 種類のサブシステムをサポートしていますが、どのサブシステムにも関連付けられていない状況 (systemd がこれに該当します) を考慮しなければ、Linux では最大 12 個の cgroup ツリーを構築でき、各ツリーはもちろん、構築できるツリーは 1 つだけで、このツリーにすべてのサブシステムを関連付けることができます。cgroup ツリーがどのサブシステムにも関連付けられていない場合は、ツリーがプロセスをグループ化するだけであることを意味し、グループ化に基づいて何を行うかについては、systemd の場合と同様にアプリケーション自体が決定します。

3. Cgroup が必要な理由は何ですか?

Linux では、セッショングループ、進捗グループなど、プロセスをグループ化する概念と需要が常にありました。その後、メモリや IO の使用状況を追跡する必要があるなど、これに対するニーズがますます高まっています。プロセスのグループ化状況などを考慮して、プロセスを一律にグループ化し、グループ化に基づいてプロセスやリソース制御管理を監視する cgroup が登場しました。
たとえば、ウイルス対策ソフトウェア ESET または ClamAV が Linux システムにインストールされている場合、ウイルス対策ソフトウェアはシステムリソースを大量に消費し、システムの業務運営に影響を与えます。単一の仮想マシンプロセスまたは Docker プロセスが使用するリソースが多すぎる場合はどうすればよいですか? 単一の Java リソースがシステムメモリを大量に占有する場合はどうすればよいですか? Cgroup は、上記の問題を制御および解決できるツールであり、Linux カーネルに実装され、Linux システムリソースの制御に使用されます。

4. Cgroup はどのように実装されますか?

CentOS 7 システム (Red Hat Enterprise Linux 7 を含む) では、cgroup 階層システムを systemd ユニットツリーにバンドルすることで、リソース管理設定をプロセスレベルからアプリケーションレベルに移動できます。デフォルトでは、systemd はスライス、スコープ、サービスユニットの階層を自動的に作成し (具体的な意味については後で説明します)、cgroup ツリーに統一された構造を提供します。
この構造は、systemctl コマンドでカスタムスライスを作成することでさらに変更できます。システムのリソースを 1 つのパイとみなすと、すべてのリソースはデフォルトで 3 つの cgroup (システム、ユーザー、マシン) に分割されます。各 cgroup はスライスであり、次の図に示すように、各スライスは独自のサブスライスを持つことができます。

ここに画像の説明を挿入

CPU リソースを例として、上の図に表示されるいくつかのキーワードを説明します。上の図に示すように、システムはデフォルトで 3 つのトップレベルスライス (システム、ユーザー、マシン) を作成し、user.slice が必要に応じて、各スライスは同じ CPU 使用時間を取得します (CPU がビジーな場合のみ)。 100% の CPU 使用時間を取得し、この時点で CPU が比較的アイドル状態であれば、user.slice は必要なものを取得できます。これら 3 つのトップレベルスライスの意味は次のとおりです。
- system.slice: すべてのシステムサービスのデフォルトの場所。
- user.slice: すべてのユーザーセッションのデフォルトの場所。各ユーザーセッションは、このスライスの下にサブスライスを作成します。同じユーザーがシステムに複数回ログインした場合でも、同じサブスライスが使用されます。
- machine.slice: すべての仮想マシンと Linux コンテナのデフォルトの場所。CPU リソースの使用を制御する方法の 1 つはシェアです。シェアは CPU の相対値 (重みとして理解できます) を設定するために使用されます。すべての CPU (コア) が対象です。デフォルト値は 1024 であるため、上の図では、httpd、sshd、crond、および gdm の CPU シェアはすべて 1024 で、System、User、および Machine の CPU シェアも 1024 です。
システム上で 4 つのサービスが実行されており、2 人のユーザーがログインし、仮想マシンも実行されていると仮定し、各プロセスが可能な限り多くの CPU リソースを必要としている (すべてのプロセスが非常にビジーである) と仮定すると、次のようになります。
- system.slice は CPU 使用時間の 33.333% を取得し、各サービスは system.slice によって割り当てられたリソースから CPU 使用時間の 1/4、つまり CPU 使用時間の 8.25% を取得します。
- user.slice は 33.333% の CPU 使用時間を取得し、ログインしている各ユーザーは 16.5% の CPU 使用時間を取得します。これは、tom と jack という 2 人のユーザーがいると仮定します。tom がログアウトするか、ユーザーセッションプロセスですべてのユーザーを強制終了すると、jack CPU 使用時間の 33.333% を使用できます。
- machine.slice は CPU 使用時間の 33.333% を取得します。仮想マシンがシャットダウンまたはアイドル状態にある場合、system.slice と user.slice は CPU リソースの 33.333% から CPU リソースの 50% を取得します。その後、両方がサブスライスに割り当てられます。

5、Cgroupの役割

Cgroups の最初の目標は、リソース管理のための統一フレームワークを提供することです。これは、cpuset などの既存のサブシステムを統合するだけでなく、将来の新しいサブシステムを開発するためのインターフェイスも提供します。現在の cgroup は、単一プロセスのリソース制御から OS レベルの仮想化 (OS レベルの仮想化) の実現まで、さまざまなアプリケーションシナリオに適しています。フレームワーク図は次のとおりです。

ここに画像の説明を挿入

Cgroup は次の機能を提供します。
- プロセスグループが使用できるリソースの数を制限します (リソース制限)。たとえば、メモリサブシステムは、プロセスグループのメモリ使用制限を設定できます。プロセスグループが使用するメモリが制限に達すると、メモリが適用されます。 ; OOM (メモリ不足) が発生します。
- プロセスグループの優先順位制御 (優先順位付け) の例: CPU サブシステムを使用して、特定の CPU シェアをプロセスグループに割り当てることができます。
- プロセスグループ (アカウンティング) によって使用されるリソースの数を記録します。たとえば、cpuacct サブシステムを使用して、プロセスグループによって使用される CPU 時間を記録できます。
- プロセスグループの分離 (Isolation) 例: ns サブシステムを使用すると、異なるプロセスグループが異なる名前空間を使用して分離の目的を達成できます。異なるプロセスグループには独自のプロセス、ネットワーク、およびファイルシステムのマウントスペースがあります。
- プロセスグループ制御 (Control) 例: フリーザーサブシステムを使用して、プロセスグループを一時停止および再開します。

6. Cgroups 関連の概念と相互関係

①関連概念

タスク (task): cgroups では、タスクはシステムのプロセスです。
コントロールグループ（コントロールグループ）：コントロールグループとは、何らかの基準に従って分割されたプロセスのグループです。Cgroups におけるリソース制御はコントロールグループ単位で実現されます。プロセスはコントロールグループに参加したり、あるプロセスグループから別のコントロールグループに移行したりできます。プロセスグループのプロセスは、cgroups によって制御グループ単位で割り当てられたリソースを使用でき、cgroups によって制御グループ単位で設定された制限に従います。
階層: コントロールグループは、階層形式、つまりコントロールグループツリーで編成できます。コントロールグループツリー上の子ノードコントロールグループは、親ノードコントロールグループの子であり、親コントロールグループの特定の属性を継承します。
サブシステム: サブシステムはリソースコントローラーです。たとえば、CPU サブシステムは CPU 時間の割り当てを制御するコントローラーです。サブシステムが機能するには、レベルに接続する必要があります。サブシステムが特定のレベルに接続されると、このレベルのすべての制御グループがこのサブシステムによって制御されます。

②相互関係

システムに新しいレベルが作成されるたびに、システム内のすべてのタスクがそのレベルのデフォルトの cgroup (ルート cgroup と呼ばれます。この cgroup はレベルの作成時に自動的に作成され、その後そのレベルで作成される cgroup はすべてこの cgroup の子孫) の初期メンバー。
サブシステムは最大 1 つのレベルにのみ接続できます。
階層には複数のサブシステムを接続できます。
タスクは複数の cgroup のメンバーになることができますが、これらの cgroup は異なるレベルにある必要があります。
システム内のプロセス (タスク) が子プロセス (タスク) を作成すると、子タスクは自動的に親プロセスが存在する cgroup のメンバーになり、必要に応じて子タスクを別の cgroup に移動できます。常に最初にその親タスクの cgroup を継承します。

7、Cgroups サブシステム

① サブシステムサブシステム

/sys/fs/cgroup の下には、cpu やmemory などの多くのサブディレクトリがあり、サブシステムサブシステムとも呼ばれます。

ここに画像の説明を挿入

これはリソース制御モジュールのセットであり、通常は次の項目が含まれます。
- net_cls: cgroup 内のプロセスによって生成されたネットワークパケットを分類し、Linux の tc (トラフィックコントローラー) が分類に従って cgroup からのパケットを区別し、電流制限または監視を実行できるようにします。このサブシステムはクラス識別子 (classid) を使用して、ネットワークパケットをマークします。これにより、Linux トラフィック制御プログラム (tc) が特定の cgroup から生成されたパケットを識別できるようになります。
- net_prio: cgroup 内のプロセスによって生成されるネットワークトラフィックの優先順位を設定します。
- メモリ: cgroup 内のプロセスのメモリ使用量を制御します。
- cpuset: マルチコアマシン上の cgroup 内のプロセスで利用可能な CPU とメモリを設定します。このサブシステムは、cgroup 内のタスクに独立した CPU (マルチコアシステムの) とメモリノードを割り当てます。
- freezer: cgroup 内のプロセスを一時停止および再開 (再開) します。このサブシステムは cgroup 内のタスクを一時停止または再開します。
- blkio: ブロックデバイス (ハードディスクなど) の入出力に対するアクセス制御を設定します。このサブシステムは、物理デバイス (ディスク、SSD、USB など) などのブロックデバイスの入出力制限を設定します。
- cpu: cgroup 内のプロセスの CPU 使用率を設定します。このサブシステムはスケジューラを使用して cgroup タスクに CPU へのアクセスを提供します。
- cpuacct: cgroup 内のプロセスの CPU 使用率の統計。このサブシステムは、cgroup 内のタスクによって使用される CPU レポートを自動的に生成します。
- devices: cgroups 内のプロセスによるデバイスへのアクセスを制御 16 このサブシステムは、cgroups 内のタスクによるデバイスへのアクセスを許可または拒否します。

② 現在のシステムがサポートしているサブシステムを確認するにはどうすればよいですか?

次のように、/proc/cgroups (Linux 2.6.24 以降) を表示することで、現在のシステムがサポートしているサブシステムを知ることができます。

#subsys_name hierarchy num_cgroups enabled 
cpuset 11 1 1 
cpu 3 64 1 
cpuacct 3 64 1 
blkio 8 64 1 
memory 9 104 1 
devices 5 64 1 
freezer 10 4 1 
net_cls 6 1 1 
perf_event 7 1 1 
net_prio 6 1 1 
hugetlb 4 1 1 
pids 2 68 1

各列の説明:
- subsys_name: サブシステム名;
- 階層: サブシステムに関連付けられた cgroup ツリーの ID。複数のサブシステムが同じ cgroup ツリーに関連付けられている場合、それらのフィールドは同じになります。たとえば、ここでの cpu と cpuacct は同じであり、それらがバインドされていることを示します次の場合、このフィールドは 0 になります。
- - 現在のサブシステムはどの cgroup ツリーにもバインドされていません。
- - 現在のサブシステムは cgroup v2 のツリーにバインドされています。
- - 現在のサブシステムはカーネルによって有効になっていません。
- num_cgroups: サブシステムに関連付けられた cgroup ツリー内のプロセスグループの数、つまりツリー上のノードの数。
- Enabled: 1 は有効であることを意味し、0 は有効でないことを意味します (カーネル起動パラメータ cgroup_disable を設定することで、サブシステムの有効化を制御できます)。

③ Cgroups 配下の CPU サブシステム

CPU サブシステムは、cgroup 内のすべてのプロセスで使用できる CPU タイムスライスを制御するために使用されます。CPU サブシステムには主に、cpu.cfs_period_us、cpu.cfs_quota_us、cpu.shares、cpu.rt_period_us、cpu.rt_runtime_us.cpu の 5 つのインターフェイスが含まれます。
cfs_period_us: cfs_period_us は、CPU の帯域幅 (CPU コア数 * cfs_period_us cpu) であるシステムの合計 CPU 帯域幅をマイクロ秒単位で表します。
cfs_quota_us: cfs_quota_us は、Cgroup が使用できる CPU 帯域幅をマイクロ秒単位で示します。cfs_quota_us は -1 です。これは、使用される CPU が cgroup によって制限されないことを意味します。cfs_quota_us の最小値は 1 ミリ秒 (1000)、最大値は 1 秒です。 cfs_period_us と組み合わせると、プロセスが使用する CPU を制限できます。たとえば、cfs_period_us=10000 および cfs_quota_us=2000 を構成します。これにより、プロセスは 2 つの CPU コアを使用できるようになります。
cpu.shares: cfs_period_us および cfs_quota_us を通じて、cgroup の CPU 使用量を絶対比率で制限できます。つまり、 cfs_quota_us/cfs_period_us はプロセスが使用できる CPU コアに等しく、この値を超えることはできませんが、cpu.shares は制限します。 cgroup の CPU を相対的に比例させます。例: 両方の cgroup で cpu.shares が 1 に設定されているタスクの CPU 時間は同じですが、cgroup で cpu.shares が 2 に設定されているタスクは、cgroup の cpu と同じくらい CPU 時間を使用できます。 1 に設定すると、2 倍の CPU 時間を使用できます。
cpu.rt_runtime_us: 一定期間内の cgroup 内のタスクの CPU リソースへの最長連続アクセス時間をマイクロ秒 (μs、ここでは「us」で表します) 単位で指定します。この制限は、cgroup 内のタスクが CPU 時間を独占するのを防ぐために確立されました。cgroup 内のタスクが 5 秒ごとに 4 秒間 CPU リソースにアクセスする必要がある場合は、cpu.rt_runtime_us を 4000000 に設定し、cpu.rt_period_us を 5000000 に設定します。
cpu.rt_period_us: 一定期間内の cgroup による CPU リソースアクセスの再割り当ての頻度をマイクロ秒 (μs、ここでは「us」で表します) 単位で指定します。cgroup 内のタスクが 5 秒ごとに 4 秒間 CPU リソースにアクセスする必要がある場合は、cpu.rt_runtime_us を 4000000 に設定し、cpu.rt_period_us を 5000000 に設定します。なお、sched_rt_runtime_us はリアルタイムタスクの保証時間と最大占有時間であり、リアルタイムタスクを使用しない場合は非リアルタイムタスクに割り当てることができ、最終的にリアルタイムタスクが占有する時間は確保できません。 sched_rt_runtime_us および sched_rt_period_us については、Linux-85 を参照してください。cpu.rt_period_us パラメータの制限は、親ディレクトリ内の同じ名前のパラメータ値より小さくなければならないことです。
cpu.rt_runtime_us の制限は次のとおりです。

Sum_{
    
    i} runtime_{
    
    i} / global_period <= global_runtime / global_period

たった今：

Sum_{
    
    i} runtime_{
    
    i} <= global_runtime

現在のリアルタイムプロセススケジューリングアルゴリズムにより、一部のリアルタイムプロセスが枯渇してしまう可能性があります。次のように、A と B は並列であり、A の実行時間は B の実行時間をカバーするだけです。

* group A: period=100000us, runtime=50000us
- this runs for 0.05s once every 0.1s
 
* group B: period= 50000us, runtime=25000us
- this runs for 0.025s twice every 0.1s (or once every 0.05 sec).

リアルタイムグループスケジューリングでは、最初に終了するリアルタイムプロセスのスケジューリングを優先するSCHED_EDF（Earliest Deadline Firstスケジューリング）の開発が提案されている。

④CentOSにCgroupをインストールする

#若系统未安装则进行安装，若已安装则进行更新
yum install libcgroup 
 
#查看运行状态，并启动服务 
[root@localhost ~] service cgconfig status 
Stopped 
 
[root@localhost ~] service cgconfig start 
Starting cgconfig service: [ OK ] 
service cgconfig status 9 Running 1011 
 
#查看是否安装cgroup
[root@localhost ~] grep cgroup /proc/filesystems

⑤サービスがどのcgroupに属しているかを確認してください。

systemctl status [pid] | grep CGroup 23 
cat /proc/[pid]/cgroup 
cd /sys/fs/ && find * ‐name "*.procs" ‐exec grep [pid] {
    
    } /dev/null \; 2> /dev/null 
 
#查看进程cgroup的最快方法是使用以下bash脚本按进程名： 
#!/bin/bash 
THISPID=`ps ‐eo pid,comm | grep $1 | awk '{
    
    print $1}'` 
cat /proc/$THISPID/cgroup

8. Cgroup の使用方法は?

①systemctlでcgroupを設定する

コマンド systemctl set-property を使用する場合、タブ補完を使用できます。

$ systemctl set‐property user‐1000.slice 
AccuracySec= CPUAccounting= Environment= LimitCPU= LimitNICE= LimitSIGPEN DING= SendSIGKILL= 
BlockIOAccounting= CPUQuota= Group= LimitDATA= LimitNOFILE= LimitSTACK= U ser= 
BlockIODeviceWeight= CPUShares= KillMode= LimitFSIZE= LimitNPROC= MemoryA ccounting= WakeSystem= 
BlockIOReadBandwidth= DefaultDependencies= KillSignal= LimitLOCKS= LimitR SS= MemoryLimit=
BlockIOWeight= DeviceAllow= LimitAS= LimitMEMLOCK= LimitRTPRIO= Nice= 
BlockIOWriteBandwidth= DevicePolicy= LimitCORE= LimitMSGQUEUE= LimitRTTIM E= SendSIGHUP=

ここで設定できるプロパティは多数ありますが、すべてのプロパティが cgroup の設定に使用されるわけではなく、Block、CPU、Memory にのみ注意する必要があります。構成ファイルを使用して cgroup を設定する場合、サービスは対応する構成ファイルを /etc/systemd/system/xxx.service.d ディレクトリーに直接作成し、スライスを /run/systemd/ に直接置くことができます。 system/xxx.slice.d ディレクトリ以下の対応する設定ファイルを作成します。実際、systemctl コマンドラインツールを使用して cgroup を設定すると、次のディレクトリ内の構成ファイルにも書き込まれます。

$ cat /run/systemd/system/user‐1000.slice.d/50‐CPUQuota.conf 
[Slice] 
CPUQuota=20%

② CPUリソース使用量の上限を設定する

CPU リソースを厳密に制御したい場合は、CPU リソースの上限を設定します。つまり、CPU がビジーであるかどうかに関係なく、CPU リソースの使用がこの上限を超えてはなりません。次の 2 つのパラメータで設定できます。
- cpu.cfs_period_us = CPU 使用時間をカウントする期間。単位はマイクロ秒 (us) です。
- cpu.cfs_quota_us = 1 サイクルで許可される CPU 時間 (シングルコアの時間を参照、マルチコアは設定時に累積する必要があります);
systemctl は、CPUQuota パラメータを通じて CPU リソース使用量の上限を設定できます。たとえば、ユーザー tom の CPU リソース使用量制限を 20% に設定したい場合は、次のコマンドを実行します。

$ systemctl set‐property user‐1000.slice CPUQuota=20%

③設定ファイル(/etc/cgconfig.conf)でcgroupを設定します。

cgroup 構成ファイルの場所は /etc/cgconfig.conf で、デフォルトの構成ファイルの内容は次のとおりです。

mount {
    
    
cpuset = / cgroup / cpuset ;
cpu = / cgroup / cpu ;
cpuacct = / cgroup / cpuacct ;
memory = / cgroup / memory ;
devices = / cgroup / devices ;
freezer = / cgroup / freezer ;
net_cls = / cgroup / net_cls ;
blkio = / cgroup / blkio ;
}

次のコマンドを実行するのと同じです。

mkdir /cgroup/cpuset 
mount ‐t cgroup ‐o cpuset red /cgroup/cpuset
…… 
mkdir /cgroup/blkio 
 
[root@localhost ~] vi /etc/cgrules.conf 
[root@localhost ~] echo 524288000 > /cgroup/memory/foo/memory.limit_in_b ytes

cgroup を使用してプロセスを一時的に調整し、コマンドを直接渡すだけです。プロセスを永続的に制御したい場合、つまり再起動後もプロセスが有効な場合は、設定ファイル /etc/cgconfig.conf に書き込む必要があります。 /etc/cgrules.conf。

9、Cgroup を表示

① systemd 経由で cgroup を表示する

systemd-cgls コマンド:
- systemd-cgls コマンドを実行すると、システム全体の cgroup レベルが返されます。cgroup ツリーの最上位は、以下に示すようにスライスで構成されます。

$ systemd‐cgls ‐‐no‐page 
 
├─1 /usr/lib/systemd/systemd ‐‐switched‐root ‐‐system ‐‐deserialize 22 
├─user.slice 
│ ├─user‐1000.slice 
│ │ └─session‐11.scope 
│ │ ├─9507 sshd: tom [priv] 
│ │ ├─9509 sshd: tom@pts/3 
│ │ └─9510 ‐bash 
│ └─user‐0.slice 
│ └─session‐1.scope 
│ ├─ 6239 sshd: root@pts/0 
│ ├─ 6241 ‐zsh 
│ └─11537 systemd‐cgls ‐‐no‐page 
└─system.slice 15 ├─rsyslog.service 
│ └─5831 /usr/sbin/rsyslogd ‐n 
├─sshd.service 18 │ └─5828 /usr/sbin/sshd ‐D 
├─tuned.service 
│ └─5827 /usr/bin/python2 ‐Es /usr/sbin/tuned ‐l ‐P 21 ├─crond.service 
│ └─5546 /usr/sbin/crond ‐n

- システム cgroup 階層の最上位層は user.slice と system.slice で構成されていることがわかります。システム内で仮想マシンやコンテナが実行されていないため、machine.slice が存在しないため、CPU がビジー状態になると、user.slice と system.slice がそれぞれ CPU 使用時間の 50% を取得します。
- user.slice の下には user-1000.slice と user-0.slice という 2 つのサブスライスがあり、各サブスライスにはユーザー ID (UID) が付けられているため、どのスライスがどのユーザーに属しているかを簡単に識別できます。。たとえば、上記の出力情報から、user-1000.slice はユーザー tom に属し、user-0.slice はユーザー root に属していることがわかります。
systemd-cgtop コマンド:
- systemd-cgls コマンドは、cgroup レベルでの静的情報のスナップショットのみを提供します。cgroup レベルで動的情報を表示するには、systemd-cgtop コマンドを使用して表示できます。

$ systemd‐cgtop 
 
Path Tasks %CPU Memory Input/s Output/s 
/ 161 1.2 161.0M ‐ ‐ 5 /system.slice ‐ 0.1 ‐ ‐ ‐ 
/system.slice/vmtoolsd.service 1 0.1 ‐ ‐ ‐ 
/system.slice/tuned.service 1 0.0 ‐ ‐ ‐ 
/system.slice/rsyslog.service 1 0.0 ‐ ‐ ‐ 
/system.slice/auditd.service 1 ‐ ‐ ‐ ‐ 
/system.slice/chronyd.service 1 ‐ ‐ ‐ ‐ 
/system.slice/crond.service 1 ‐ ‐ ‐ ‐ 
/system.slice/dbus.service 1 ‐ ‐ ‐ ‐ 
/system.slice/gssproxy.service 1 ‐ ‐ ‐ ‐ 
/system.slice/lvm2‐lvmetad.service 1 ‐ ‐ ‐ ‐ 
/system.slice/network.service 1 ‐ ‐ ‐ ‐ 
/system.slice/polkit.service 1 ‐ ‐ ‐ ‐ 
/system.slice/rpcbind.service 1 ‐ ‐ ‐ ‐ 
/system.slice/sshd.service 1 ‐ ‐ ‐ ‐ 
/system.slice/system‐getty.slice/getty@tty1.service 1 ‐ ‐ ‐ ‐ 
/system.slice/systemd‐journald.service 1 ‐ ‐ ‐ ‐ 
/system.slice/systemd‐logind.service 1 ‐ ‐ ‐ ‐ 
/system.slice/systemd‐udevd.service 1 ‐ ‐ ‐ ‐ 
/system.slice/vgauthd.service 1 ‐ ‐ ‐ ‐ 
/user.slice 3 ‐ ‐ ‐ ‐ 
/user.slice/user‐0.slice/session‐1.scope 3 ‐ ‐ ‐ ‐ 
/user.slice/user‐1000.slice 3 ‐ ‐ ‐ ‐ 
/user.slice/user‐1000.slice/session‐11.scope 3 ‐ ‐ ‐ ‐ 
/user.slice/user‐1001.slice/session‐8.scope

- scope systemd-cgtop によって提供される統計データと制御オプションは top コマンドに似ていますが、このコマンドはリソース統計が有効になっているサービスとスライスのみを表示します。sshd.service のリソース統計機能を有効にする場合は、次の手順を実行できます。

$ systemctl set‐property sshd.service CPUAccounting=true MemoryAccounting=true 
 
#该命令会在 /etc/systemd/system/sshd.service.d/ 目录下创建相应的配置文件： 
$ ll /etc/systemd/system/sshd.service.d/ 
总用量 8 
4 ‐rw‐r‐‐r‐‐ 1 root root 28 5月 31 02:24 50‐CPUAccounting.conf 
4 ‐rw‐r‐‐r‐‐ 1 root root 31 5月 31 02:24 50‐MemoryAccounting.conf 
 
$ cat /etc/systemd/system/sshd.service.d/50‐CPUAccounting.conf 
[Service] 
CPUAccounting=yes 1415 
 
$ cat /etc/systemd/system/sshd.service.d/50‐MemoryAccounting.conf 
[Service] 
MemoryAccounting=yes 1819 
 
#配置完成之后，再重启 sshd 服务： 
$ systemctl daemon‐reload 21 $ systemctl restart sshd

- この時点で、systemd-cgtop コマンドを再度実行すると、sshd のリソース使用量の統計を確認できます。

② proc経由でcgroupを表示する

現在のプロセスがどの cgroup に属しているかを確認する方法次のように /proc/[pid]/cgroup (Linux 2.6.24 以降) を表示することで、指定されたプロセスがどの cgroup に属しているかを確認できます。

$ cat /proc/777/cgroup 
 
11:cpuset:/ 
10:freezer:/ 
9:memory:/system.slice/cron.service 
8:blkio:/system.slice/cron.service 
7:perf_event:/ 7 6:net_cls,net_prio:/ 
5:devices:/system.slice/cron.service 
4:hugetlb:/ 
3:cpu,cpuacct:/system.slice/cron.service 
2:pids:/system.slice/cron.service 
1:name=systemd:/system.slice/cron.service

各行にはコロンで区切られた 3 つの列が含まれており、これは次のことを意味します。

cgroup树的ID ：和cgroup树绑定的所有subsystem ：进程在cgroup树中的路径

- cgroup ツリーの ID は、/proc/cgroups ファイル内の ID に対応します。
- cgroup ツリーにバインドされているすべてのサブシステムはカンマで区切られています。ここで name=systemd は、どのサブシステムにもバインドされていないことを意味しますが、systemd という名前が付けられます。
- cgroup ツリー内のプロセスのパス、つまり、プロセスが属する cgroup のマウントポイントからの相対パス。

③ /sys 経由で cgroup を表示する

cgroup で CPU リソースの使用制限を表示します。

$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user‐1000.slice/cpu.cfs_perio d_us 
100000 
 
$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user‐1000.slice/cpu.cfs_quota _us 
20000

これは、ユーザー tom が 1 回の使用サイクル (100 ミリ秒) で 20 ミリ秒の CPU 時間を使用できることを意味します。CPU がアイドル状態であるかどうかに関係なく、このユーザーが使用する CPU リソースはこの制限を超えることはありません。
CPUQuota の値は 100% を超えることができます。たとえば、システムの CPU がマルチコアで、CPUQuota の値が 200% の場合、スライスは 2 コアの CPU 時間を使用できます。

コア Cgroups 関連の概念と Docker コンテナの実装のクラウド ネイティブの詳細な分析

1. Cgroup の概要

2. Cgroups の主な構造

3. Cgroup が必要な理由は何ですか?

4. Cgroup はどのように実装されますか?

5、Cgroupの役割

6. Cgroups 関連の概念と相互関係

①関連概念

②相互関係

7、Cgroups サブシステム

① サブシステム サブシステム

② 現在のシステムがサポートしているサブシステムを確認するにはどうすればよいですか?

③ Cgroups 配下の CPU サブシステム

④CentOSにCgroupをインストールする

⑤サービスがどのcgroupに属しているかを確認してください。

8. Cgroup の使用方法は?

①systemctlでcgroupを設定する

② CPUリソース使用量の上限を設定する

③設定ファイル(/etc/cgconfig.conf)でcgroupを設定します。

9、Cgroup を表示

① systemd 経由で cgroup を表示する

② proc経由でcgroupを表示する

③ /sys 経由で cgroup を表示する

おすすめ

コア Cgroups 関連の概念と Docker コンテナの実装のクラウドネイティブの詳細な分析

① サブシステムサブシステム