☰

AWS/GCP での CPU の分離: cpuset のマウント エラー

tag-icon • tag-icon amazon-web-services google-cloud-platform cgroup cpuset cset
AWS/GCP での CPU の分離: cpuset のマウント エラー

AWS/GCP に 32 vCPU インスタンスが 2 つあります。CPU 0、1 がシステムによって使用され、CPU 2 ～ 31 がシールドされてユーザー空間スレッドによってのみ明示的に使用されるように、CPU シールドを設定しようとしています。

システム情報：

Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:    22.04
Codename:   jammy

$ cat /proc/filesystems | grep cpuset
nodev   cpuset

しかし、 を実行しようとするとcset shield、マウントに関するエラーが発生します。

mount: /cpusets: none already mounted on /run/credentials/systemd-sysusers.service.
cset: **> mount of cpuset filesystem failed, do you have permission?

csetのコードを少し調べてみたところ、失敗した呼び出しは

$ sudo mount -t cpuset cpuset /cpusets
mount: /cpusets: cpuset already mounted or mount point busy.

/cpusets新しく作成されたフォルダーであり、$ cat /proc/mounts | grep cpuset空です。そのため、cpuset は他の場所にマウントされていないようです。

おそらく関連がある:

$ cat /proc/mounts | grep cgroup
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0

私の推測では、AWS/GCP はハイパーバイザーに cpuset などを使用していると思います。AWS/GCP で CPU を分離することは可能ですか? どうすればいいですか?

答え1

すでにv2（「統合」）cgroupsをマウントしているsystemdを使用しているので、コントロールグループを管理するのはあなたではなく、systemdです。CPUAffinity= ファイル[Manager]のセクション内の関連オプション/etc/systemd/system.conf.d/50-my-cpuset-options.confCPUAffinity=その後、グローバル デフォルトから除外する特定の unit.service ファイルに対して、 (空の場合はリセット、空でない場合は追加) を使用できます。

systemd API を使用して、コマンドを介してすでに実行中のサービスのリソース オプションを一時的に (再起動するまで) 変更することもできますsystemctl --runtime set-property example.service ExampleOption=Value。これを使用して、結果として得られる cgroup 設定を確認し、それがシステム パフォーマンスに与える影響を測定します。CPU を 100% 使用するスケジューラの機能を損なうのではなく、その機能を完全に向上させると、グローバル デフォルトではなく、輻輳時のシステム信頼性が測定可能なほど向上すると思います。実行したいがシステムの他の部分に影響を与えたくない特定の低優先度の非同期バックグラウンド タスクで と を使用して、優先度をより厳密にNice=一致IOSchedulingClass=させます。ただし、アフィニティの強力な機能は使用しないでください。

理論的には、次のようなユーティリティは設定system.slice代わりにcgroup2システムマネージャとインターフェースし、バックグラウンドでsystemdとユニットのデフォルトを変更しながら、以前と実質的に同一の抽象化を提供するように更新できますが、この議論はこれまで誰もそんなことはしていません。すべてを網羅する巨大なCの塊カーネルが学習したすべての優れた機能をより豊富に、十分に文書化され、おそらくより多用途に制御できるため、もはやその必要はないかもしれません。

答え2

前述のように、systemd は独自の cgroup2 階層を作成しますが、私のニーズからすると、これは cset とうまく連携しません。

Ubuntu 22.10 でこの動作を無効にするために、/etc/default/grub の GRUB_CMDLINE_LINUX_DEFAULT 値の先頭に次のコードを追加しました。

完了すると、行は次のようになります。

GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=false <your_other_params>"

完了したら、root として実行する必要があります。

update-grub
grub-install

その後再起動します。再起動後、CSETを使用してRyzen CPUのCCXを正常にシールドし、すべてのユーザーランドとシステムタスクを移行することができました。

さらに詳しい背景を知りたい場合に備えて、この問題に関して私が見つけた参考資料を以下に示します。 https://github.com/systemd/systemd/issues/13477#issuecomment-528113009 参考:

関連情報