systemdを使用したcgroups v2の管理
cgroups v2
を使用してリソース割当てを管理するための優先される方法は、systemd
によって提供される制御グループ機能を使用することです。
デフォルトでは、systemd
は、ホストに設定されたsystemd
サービスごとにcgroup
フォルダを作成します。systemd
は、servicename.service
という形式を使用してこれらのフォルダに名前を付けます。servicenameは、フォルダに関連付けられたサービスの名前です。
systemd
がサービスに対して作成するcgroup
フォルダのリストを表示するには、次のサンプル・コード・ブロックに示すように、cgroup
ファイル・システムのsystem.slice
ブランチでls
コマンドを実行します:
ls /sys/fs/cgroup/system.slice/
... ... ...
app_service1.service cgroup.subtree_control httpd.service
app_service2.service chronyd.service ...
... crond.service ...
cgroup.controllers dbus-broker.service ...
cgroup.events dtprobed.service ...
cgroup.freeze firewalld.service ...
... gssproxy.service ...
... ... ...
-
フォルダapp_service1.
service
およびapp_service2.service
は、システム上に存在する可能性のあるカスタム・アプリケーション・サービスを表します。
systemd
では、サービス制御グループに加えて、ホスト上のユーザーごとにcgroup
フォルダも作成されます。各ユーザーに対して作成されたcgroup
を確認するには、次のサンプル・コード・ブロックに示すように、cgroup
ファイル・システムのuser.slice
ブランチでls
コマンドを実行します:
ls /sys/fs/cgroup/user.slice/
cgroup.controllers cgroup.subtree_control user-1001.slice
cgroup.events cgroup.threads user-982.slice
cgroup.freeze cgroup.type ...
... ... ...
... ... ...
... ... ...
前述のコード・ブロックの内容は次のとおりです:
-
各ユーザーの
cgroup
フォルダには、user
-UID.slice
という形式を使用して名前が付けられます。したがって、制御グループuser-1001.slice
は、たとえばUID
が1001のユーザー用です。
systemd
は、cgroup
およびカーネル・リソース・コントローラ機能への高レベルのアクセスを提供するため、ファイル・システムに直接アクセスする必要はありません。たとえば、app_service1.service
というサービスのCPUの重みを設定するには、次のようにsystemctl set-property
コマンドを実行します:
sudo systemctl set-property app_service1.service CPUWeight=150
したがって、systemd
を使用すると、systemd
機能を使用せずにcgroup
を構成するときに使用されるプロセスのPIDレベルではなく、アプリケーション・レベルでリソース配分を管理できます。
systemdでのスライスとリソース割当てについて
この項では、次の円グラフの例に示すように、systemd
がデフォルトの各カーネル・コントローラ(たとえば、CPU
、memory
およびblkio
)をスライスと呼ばれる部分に分割する方法を確認します:
ノート:
「リソース・コントローラ・オプションの設定およびカスタム・スライスの作成」の項に示すように、リソース配分用に独自のカスタム・スライスを作成することもできます。図7-1 CPUやメモリーなどのリソース・コントローラの配分を示す円グラフ

前述の円グラフが示すように、デフォルトでは、各リソース・コントローラは次の3つのスライス間で均等に分割されます:
-
System (
system.slice
)。 -
User (
user.slice
)。 -
Machine (
machine.slice
)。
次のリストは、各スライスをさらに詳しく示します。説明のために、リストの例ではCPUコントローラに焦点を当てています。
- System (
system.slice
) -
このリソース・スライスは、デーモンおよびサービス・ユニット間のリソース割当てを管理するために使用されます。
前述の円グラフの例に示すように、システム・スライスはさらにサブスライスに分割されます。たとえば、CPUリソースの場合、次のようにサブスライスの割当てがシステム・スライス内に存在する可能性があります:-
httpd.service
(CPUWeight
=100) -
sshd.service
(CPUWeight
=100) -
crond.service
(CPUWeight
=100) -
app1.
service
(CPUWeight
=100) -
app2.
service
(CPUWeight
=100)
service
およびapp2.service
は、システムで実行している可能性のあるカスタム・アプリケーション・サービスを表します。 -
- User (
user.slice
) - このリソース・スライスは、ユーザー・セッション間のリソース割当てを管理するために使用されます。関連付けられたユーザーがサーバーでアクティブになっているログインの数に関係なく、
UID
ごとに1つのスライスが作成されます。円グラフの例に続いて、サブスライスは次のようになります:-
user1 (
CPUWeight
=100,UID
=982) -
user2 (
CPUWeight
=100,UID
=1001)
-
- Machine (
machine.slice
) - このリソース・スライスは、KVMゲストやLinuxコンテナなどのホストされた仮想マシン間のリソース割当ての管理に使用されます。マシン・スライスは、サーバーが仮想マシンまたはLinuxコンテナをホストしている場合にのみサーバーに存在します。
ノート:
共有割当てでは、リソースの最大制限は設定されません。
たとえば、前述の例では、スライスuser.slice
には、user1およびuser2の2人のユーザーがあります。各ユーザーには、親user.slice
で使用可能なCPUリソースの等しい共有が割り当てられます。ただし、user1に関連付けられたプロセスがアイドル状態であり、CPUリソースを必要としない場合、そのCPU共有は必要に応じてuser2への割当てに使用できます。このような状況では、他のユーザーが必要とする場合、親user.slice
に割り当てられているCPUリソース全体がuser2に割り当てられることもあります。
CPUリソースを制限するには、CPUQuota
プロパティを必要な割合に設定する必要があります。
cgroup階層内のスライス、サービスおよびスコープ
前述の項で使用されている円グラフから類推すると、リソースの区分をスライスに概念化できます。ただし、構造的な組織では、制御グループは階層に配置されます。systemd-cgls
コマンドを次のように実行すると、システム上のsystemd
制御グループ階層を表示できます:
ヒント:
次の例のように、ルート・スライス-.slice
から始まるcgroup
階層全体を表示するには、制御グループ・マウント・ポイント/sys/fs/cgroup/
の外部からsystemd-cgls
を実行してください。それ以外の場合、/sys/fs/cgroup/
内からコマンドを実行すると、コマンドの実行元のcgroup
の場所から出力が開始されます。詳細は、systemd-cgls(1)
を参照してください。
systemd-cgls
Control group /:
-.slice
...
├─user.slice (#1429)
│ → user.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
│ ├─user-982.slice (#4131)
│ │ → user.invocation_id: 9d0d94d7b8a54bcea2498048911136c8
│ │ ├─session-c1.scope (#4437)
│ │ │ ├─2416 /usr/bin/sudo -u ocarun /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
│ │ │ └─2494 /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand
│ │ └─user@982.service … (#4199)
│ │ → user.delegate: 1
│ │ → user.invocation_id: 37c7aed7aa6e4874980b79616acf0c82
│ │ └─init.scope (#4233)
│ │ ├─2437 /usr/lib/systemd/systemd --user
│ │ └─2445 (sd-pam)
│ └─user-1001.slice (#7225)
│ → user.invocation_id: ce93ad5f5299407e9477964494df63b7
│ ├─session-2.scope (#7463)
│ │ ├─20304 sshd: oracle [priv]
│ │ ├─20404 sshd: oracle@pts/0
│ │ ├─20405 -bash
│ │ ├─20441 systemd-cgls
│ │ └─20442 less
│ └─user@1001.service … (#7293)
│ → user.delegate: 1
│ → user.invocation_id: 70284db060c1476db5f3633e5fda7fba
│ └─init.scope (#7327)
│ ├─20395 /usr/lib/systemd/systemd --user
│ └─20397 (sd-pam)
├─init.scope (#19)
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 28
└─system.slice (#53)
...
├─dbus-broker.service (#2737)
│ → user.invocation_id: 2bbe054a2c4d49809b16cb9c6552d5a6
│ ├─1450 /usr/bin/dbus-broker-launch --scope system --audit
│ └─1457 dbus-broker --log 4 --controller 9 --machine-id 852951209c274cfea35a953ad2964622 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
...
├─chronyd.service (#2805)
│ → user.invocation_id: e264f67ad6114ad5afbe7929142faa4b
│ └─1482 /usr/sbin/chronyd -F 2
├─auditd.service (#2601)
│ → user.invocation_id: f7a8286921734949b73849b4642e3277
│ ├─1421 /sbin/auditd
│ └─1423 /usr/sbin/sedispatch
├─tuned.service (#3349)
│ → user.invocation_id: fec7f73678754ed687e3910017886c5e
│ └─1564 /usr/bin/python3 -Es /usr/sbin/tuned -l -P
├─systemd-journald.service (#1837)
│ → user.invocation_id: bf7fb22ba12f44afab3054aab661aedb
│ └─1068 /usr/lib/systemd/systemd-journald
├─atd.service (#3961)
│ → user.invocation_id: 1c59679265ab492482bfdc9c02f5eec5
│ └─2146 /usr/sbin/atd -f
├─sshd.service (#3757)
│ → user.invocation_id: 57e195491341431298db233e998fb180
│ └─2097 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
├─crond.service (#3995)
│ → user.invocation_id: 4f5b380a53db4de5adcf23f35d638ff5
│ └─2150 /usr/sbin/crond -n
...
前述のサンプル出力は、すべての*.slice
制御グループがルート・スライス-.slice
の下にどのように存在しているかを示しています。ルート・スライスの下には、 user.slice
およびsystem.slice
制御グループがあり、それぞれに子cgroup
サブスライスがあります。
systemd-cgls
コマンドの出力を確認すると、ルート-.slice
を除いて、すべてのプロセスがリーフ・ノード上にあることがわかります。この配置は、cgroups
v2によって"内部プロセスなし"ルールと呼ばれるルールで強制されます。"内部プロセスなし"ルールの詳細は、cgroups (7)
を参照してください。
前述のsystemd-cgls
コマンド例の出力では、スライスにsystemd
スコープの子制御グループを含める方法も示しています。systemd
スコープについては、次の項で説明します。
systemdスコープ
systemd
スコープは、systemd
とは無関係に起動されたシステム・サービス・ワーカー・プロセスをグループ化するsystemd
ユニット・タイプです。スコープ・ユニットは、systemd
のバス・インタフェースを使用してプログラムで作成される一時cgroup
です。
たとえば、次のサンプル・コードでは、UID
1001のユーザーがsystemd-cgls
コマンドを実行しており、出力には、systemd
とは関係なくユーザーが生成したプロセス(コマンド自体のプロセス21380 sudo systemd-cgls
を含む)に対してsession-2.scope
が作成されていることが示されています:
ノート:
次の例では、制御グループのマウント・ポイント/sys/fs/cgroup/
内からコマンドが実行されています。したがって、ルート・スライスのかわりに、コマンドの実行元のcgroup
の場所から出力が開始されます。
sudo systemd-cgls
Working directory /sys/fs/cgroup:
...
├─user.slice (#1429)
│ → user.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
│ → trusted.invocation_id: 604cf5ef07fa4bb4bb86993bb5ec15e0
...
│ └─user-1001.slice (#7225)
│ → user.invocation_id: ce93ad5f5299407e9477964494df63b7
│ → trusted.invocation_id: ce93ad5f5299407e9477964494df63b7
│ ├─session-2.scope (#7463)
│ │ ├─20304 sshd: oracle [priv]
│ │ ├─20404 sshd: oracle@pts/0
│ │ ├─20405 -bash
│ │ ├─21380 sudo systemd-cgls
│ │ ├─21382 systemd-cgls
│ │ └─21383 less
│ └─user@1001.service … (#7293)
│ → user.delegate: 1
│ → trusted.delegate: 1
│ → user.invocation_id: 70284db060c1476db5f3633e5fda7fba
│ → trusted.invocation_id: 70284db060c1476db5f3633e5fda7fba
│ └─init.scope (#7327)
│ ├─20395 /usr/lib/systemd/systemd --user
│ └─20397 (sd-pam)
リソース・コントローラ・オプションの設定およびカスタム・スライスの作成
systemd
には、システムでのリソース割当てをカスタマイズするために、CPUWeight
、CPUQuota
などのリソース・コントローラ・オプションを設定するための次の方法が用意されています:
-
サービス・ユニット・ファイルの使用。
-
ドロップイン・ファイルの使用。
-
systemctl set-property
コマンドの使用。
次の項では、これらの各方法を使用してシステム内のリソースとスライスを構成する手順の例を示します。
systemctl set-propertyの使用
systemctl set-property
コマンドは、構成ファイルを次の場所に配置します:
/etc/systemd/system.control
注意:
systemctl set-propertyコマンドで作成されるファイルを手動で編集しないでください。
ノート:
systemctl set-property
コマンドでは、このトピックで前述したシステム・ユニット・ファイルおよびドロップイン・ファイルで使用されるすべてのリソース制御プロパティが認識されるわけではありません。
次の手順では、systemctl set-property
コマンドを使用してリソース割当てを構成する方法を示します: