UbuntuでCgroupsを使用してプロセスのCPUとRAMの使用を制限する方法

Ubuntu では、cgroups を使用してワークロードを制限する最も安全な一般的な方法は、systemd にコントロール グループの作成と管理を任せることです。systemd-run今すぐ起動するコマンドに使用するか、再起動後も制限を維持する必要がある場合は systemd サービスを構成します。CPUCPUQuota=時間の上限を厳密に設定し、MemoryHigh=負荷の場合は 、MemoryMax=メモリの上限の場合は から選択します。これらの制限は、ユニットとその子プロセスの両方に適用されます。

cgroup（コントロールグループ）は、Linuxカーネルのメカニズムであり、システムがプロセスのリソース使用量を把握し制御できるようにプロセスを整理します。Ubuntuのsystemdは既にサービスをcgroupに配置するため、ほとんどのユーザーは/sys/fs/cgroup手動でディレクトリを作成する必要はありません。以下の例ではsystemdのリソース制御インターフェースを使用しているため、ご使用のUbuntuリリースにインストールされているsystemdのバージョンに合わせて確認してください。

問題に合ったコントロールを選択してください。

ほとんどの対話型Ubuntuマシンでは、一時的なスコープが最も迅速かつ容易に元に戻せる選択肢です。本番サービスの場合は、サービスユニットを使用してポリシーを文書化し、起動時に復元するようにしてください。cgroupファイルを直接使用するのは、委任された階層を意図的に管理する場合、またはコンテナ/ランタイムワークフローを構築する場合に限ってください。

制限を設定する前にUbuntuシステムを確認してください

まず、systemdが利用可能であること、およびcgroupファイルシステムが統合v2であるかどうかを確認してください。

systemctl --version
stat -fc %T /sys/fs/cgroup

2 番目のコマンドの結果は、cgroup2fs統合された cgroup v2 ファイルシステムを示しています。Ubuntu のリリースやカスタマイズされたシステムでは異なる場合があるため、すべてのマシンが同じ階層構造や systemd 機能を持っているとは限りません。最初のコマンドで現在の systemd バージョンを確認することもできます。cgroup マウントが v2 でない場合、リソースのプロパティやコントローラの動作が異なる可能性があります。設定をコピーする前に、インストールされているリリースの Ubuntu マニュアルページを参照してください。

ワークロードを測定してから値を選択してください。システムの他の部分のための余裕を残し、ユーザーサービスに設定された制限は、その親スライスに設定された制限にも影響されることに注意してください。子cgroupは、親cgroupが許可する以上のリソースを受け取ることはできません。

これから開始するコマンドを制限する

自分のユーザーセッションでコマンドを実行するには、`transient scope` を使用してコマンドを起動しますsystemd-run --user --scope。例:

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

Python コマンドを、実際に実行する必要のあるプログラムに置き換えてください。この例では、cgroup の最大 CPU 帯域幅を 1 つの CPU の半分に相当し、メモリ負荷処理を 700 MiB 付近から開始し、ハードメモリの最大値を 900 MiB に設定します。メモリ値は systemd の 1024 を基本単位として使用します。クォータは100%最大で 1 つの CPU 分の時間を表します。200%利用可能な場合は最大で 2 つの CPU 分の時間を使用できます。これは、コンピュータのすべてのコアの割合を意味するものではありません。

このコマンドはスコープであるため、フォアグラウンドで実行されます。終了すると、一時的なユニットは消滅します。--userシステムマネージャを使用する予定があり、必要な権限を持っている場合にのみ削除してください。システム全体の一時的なユニットの場合は、適切なコマンドオプションを指定してコマンドを実行してsudoください。マネージャまたはcgroupコントローラがサポートしていない場合、リソース設定が拒否されることがあります。

永続的な systemd サービスに制限を設定する

のようなサービスの場合worker.service、ベンダーユニットファイルを編集する代わりにドロップインを作成します。 を実行しsudo systemctl edit worker.serviceて以下を追加します。

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

ドロップインを保存し、systemdのユニット定義を再読み込みしてサービスを再起動すると、プロセスは改訂されたポリシーの下で開始されます。

sudo systemctl daemon-reload
sudo systemctl restart worker.service

メモリ上限は慎重に設定してください。サービスがメモリを十分に解放できない場合MemoryMax、カーネルはcgroup内のメモリ不足キラーを起動する可能性があります。これにより、サービスグル​​ープ内の1つ以上のプロセスが終了し、作業が中断される可能性があります。より安全な方法は、メモリのMemoryHigh解放とスロットリングが許容できるレベルに設定し、MemoryMax最終的な境界としてより高い値を設定することです。厳しい上限を設定する前に、現実的なピーク負荷でテストしてください。

ユニットを検証し、その動作を確認してください。

過渡現象スコープについては、指定したユニット名を使用してステータスを確認してください。

systemctl --user status worker-capped.scope
systemd-cgtop

システムサービスの場合は、--userステータスコマンドで省略します。ステータスビューでは、ユニットが存在しアクティブであることを確認し、systemd-cgtopコントロールグループごとのリソース使用状況をリアルタイムで表示します。構成済みのプロパティを確認するには、ユニットに直接クエリを実行します。例:

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

cgroup に報告されるメモリ量は、必ずしも個々のプロセスの常駐セット値と同じではありません。これはグループに割り当てられたメモリ量であり、ワークロードの子孫プロセスも含まれる可能性があります。監視は、ワークロードが時間とともにどのように変化するかを示す証拠として捉え、盲目的に最適化するための単一の数値として扱うべきではありません。

プロセスが既に実行中の場合はどうなりますか？

systemd-run新しいユニット内で新しいコマンドを開始します。既存の任意の PID を取得してそのスコープに移動することはありません。プロセスが systemd サービスに属している場合は、ドロップインを使用してそのサービスに設定を適用するか、一時的な変更の場合は を使用しますsudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M。この--runtime形式は一時的なものであり、永続的なサービス構成を置き換えるものではありません。

プロセスがデスクトップ セッション内の通常のプログラムである場合、安全で簡単な方法は、通常、それを停止して で再起動することですsystemd-run。ユーザー スライス全体など、より広いスライスにプロパティを適用すると、多くの無関係なアプリケーションに影響を与える可能性があります。PID を cgroup ファイルに書き込むことでプロセスを移動するには、関連する委任階層の制御が必要であり、cgroup v2 のプロセス配置ルールを遵守する必要があります。推測で systemd が管理するディレクトリに書き込まないでください。

CPUとメモリポリシーの選択方法

• CPU使用率の上限を厳密に設定する必要がありますか？それなら、を選択してくださいCPUQuota=。値を小さくするとCPU使用率のピークは下がりますが、処理速度が遅くなり、キュー時間が長くなる可能性があります。
• 優先度を低く設定したい場合、割り当て量ではなくウェイトを検討してくださいCPUWeight=。ウェイトは競合状況に応じてCPUを相対的に割り当てます。固定の割合を確保したり、アイドル状態のCPUの使用を妨げたりすることはありません。
• 即座に強制停止することなくメモリ負荷をかけたいですか？MemoryHigh=メインの負荷しきい値として設定し、レイテンシとメモリ解放の動作を観察してください。
• 最終的な境界が必要ですか？通常のピーク時に対応できる十分な余裕を持たせてくださいMemoryMax=。境界が守れなくなった場合、メモリ不足（OOM）が発生する可能性があることを覚悟しておいてください。
• 既にコンテナを使用している場合は、コンテナマネージャがサポートするCPUおよびメモリフラグを優先してください。これらのフラグは、そのコンテナのcgroupを設定し、ライフサイクルに適合させます。

すべてのワークロードに対して理想的な制限値は存在しません。デスクトップのバッチジョブであれば、低いクォータと中程度のメモリ制限でも問題ないかもしれませんが、レイテンシに敏感なサービスでは、CPUMemoryHighリソースの解放に伴う一時停止を避けるために、より多くのCPUヘッドルームと高いクォータが必要になる場合があります。まずは控えめな設定から始め、代表的なピーク時にユニットを監視し、一度に1つの設定ずつ調整してください。

参考文献

• Ubuntuドキュメント：cgroupsとsystemdのリソース制御
• Ubuntuのマニュアルページ：systemd-run
• Ubuntuのマニュアルページ：systemd.resource-control
• Linuxカーネルのドキュメント：コントロールグループv2