私は約3年間、cgroupv1でこれを使用して他の仮想ホストへのWeb要求を処理したときに生成されたサブプロセスを自動的に分類しましたapache2-mpm-itk。それはうまくいきました。特定の仮想ホストがCPU / RAMを占有しすぎると、大きな問題が発生します。処理され、残りは無視されます。cgrulesengdapache2-mpm-itk
私は現在新しいDebian 11サーバーを準備していますが、今cgroup v2を使用する必要があることに気付きました。だから私は私のリソース制御ソリューションを新しい世界に持ち込みたいと思います。
そのユーザーのリソース制御を使用して例を作成すると、上記のようにフォークされた/etc/systemd/system/user-UID.slice.d/override.confプロセスでは機能しません。代わりに、親とすべての子はまだ同じapache2.serviceスライスに属します。cgrulesengdsystemd-cgls
システムによって生成されたプロセス以外のcgroup内のプロセスの子プロセスを自動的に分類する方法はありますか？
ベストアンサー1
メーリングリストに次の質問を投稿しましたsystemd-devel。
https://lists.freedesktop.org/archives/systemd-devel/2022-January/047257.html
Benjamin Bergの答えは次のとおりです。
https://lists.freedesktop.org/archives/systemd-devel/2022-January/047260.html
Benjaminの答えはとても役に立ちました。以下は2つの抜粋です。
systemd will not help you with managing the cgroup sub-hierarchy
underneath the daemon. I suppose the most generic solution would be
something like cgrulesengd for cgroup v2. No idea if something like
that exists.
そして：
Managing the cgroup hierarchy is quite simple in principle (mkdir and
then a write to cgroup.procs). Or, even better by using
CLONE_INTO_CGROUP when creating the processes. It is not that hard to
write small daemon that does this.
編集する:
cgconfigparserとcgrulesengdがcgroupv2をサポートするように更新されているようです。
この記事を書くときは、ソースからビルドする必要があります。
パッケージは次の場所からダウンロードできます。
https://github.com/libcgroup/libcgroup/releases/tag/v2.0
次に、次の手順に従います。たとえば、次のようになります。
./configure
make
cgconfig.confのコントローラパラメータ名は異なる可能性があるため、新しい環境ではcgroupv2パラメータ名を使用する必要があります。