Systemdを使用した制御グループの管理

この項では、次の円グラフの例に示すように、systemdがデフォルトの各カーネル・コントローラ(たとえば、CPU、memoryおよびblkio)をスライスと呼ばれる部分に分割する方法を確認します:

前述の円グラフが示すように、デフォルトでは、各リソース・コントローラは次の3つのスライス間で均等に分割されます:

• System (system.slice)。

• User (user.slice)。

• Machine (machine.slice)。

次のリストは、各スライスをさらに詳しく示します。説明のために、リストの例ではCPUコントローラに焦点を当てています。

システム(system.slice)

このリソース・スライスは、デーモンおよびサービス・ユニット間のリソース割当てを管理するために使用されます。

前述の円グラフの例に示すように、システム・スライスはさらにサブスライスに分割されます。たとえば、CPUリソースの場合、次のようにサブスライスの割当てがシステム・スライス内に存在する可能性があります:

• httpd.service (CPUWeight=100)

• sshd.service (CPUWeight =100)

• crond.service (CPUWeight =100)

• app1.service (CPUWeight =100)

• app2.service (CPUWeight =100)

前述のリストでは、app1.serviceおよびapp2.serviceは、システムで実行される可能性のあるカスタム・アプリケーション・サービスを表します。

ユーザー(user.slice)

このリソース・スライスは、ユーザー・セッション間のリソース割当てを管理するために使用されます。関連付けられたユーザーがサーバーでアクティブになっているログインの数に関係なく、UIDごとに1つのスライスが作成されます。円グラフの例に続いて、サブスライスは次のようになります:

• user1 (CPUWeight=100、UID=982)

• user2 (CPUWeight=100、UID=1001)

マシン(machine.slice)

このリソース・スライスは、KVMゲストやLinuxコンテナなどのホストされた仮想マシン間のリソース割当ての管理に使用されます。マシン・スライスは、サーバーが仮想マシンまたはLinuxコンテナをホストしている場合にのみサーバーに存在します。

前述の項で使用されている円グラフから類類推すると、リソースの区分をスライスに概念化できる便利な方法です。ただし、構造的な組織では、制御グループは階層に配置されます。systemd-cglsコマンドを次のように実行して、システム上のsystemd制御グループ階層を表示できます:

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のバス・インタフェースを使用してプログラムで作成される一時cgroupです。

たとえば、次のサンプル・コードでは、UID 1001のユーザーがsystemd-cglsコマンドを実行しており、出力には、systemdとは関係なくユーザーが生成したプロセス(コマンド自体のプロセス21380 sudo systemd-cglsを含む)に対してsession-2.scopeが作成されていることが示されています:

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)