パート1では、システム管理とパフォーマンス調整のためのcgroupの機能と使用法について説明しました。パート2では、cgroupsとCPUSharesの値の複雑さに注目しました。ここパート3では、cgroupの手動管理タスクに焦点を当てます。
cgroupsがsystemdとどのように連携するかについては、パート4を読むことを忘れないでください。
cgroupsを難しい方法で実行する
周囲にツールを使用せずにcgroupを作成する方法を見てみましょう。本質的に、cgroupsはcgroups
を備えた単なるディレクトリ構造です。 それらにマウントされます。これらはファイルシステムのどこにでも配置できますが、システムで作成されたcgroupは/sys/fs/cgroup
にあります。 デフォルトでは。では、どのようにcgroupを作成しますか?次のトップレベルディレクトリを作成することから始めます。
# mkdir -p /my_cgroups
これを作成したら、使用するコントローラーを決定します。 cgroupsバージョン1の構造は次のようになっていることに注意してください。
/my_cgroups
├── <controller type>
│ ├── <group 1>
│ ├── <group 2>
│ ├── <group 3>
[読者も気に入りました:crunの紹介、高速でメモリフットプリントの少ないコンテナランタイム]
作成するすべてのグループは、各コントローラータイプの下に個別にネストされます。したがって、 group1 コントローラのmemory
の下 group1から完全に独立しています blkio
で 。それを念頭に置いて、基本的なCPUSharesの例を作成しましょう。
簡単にするために、次のコマンドを実行してシステムに負荷をかけます。
# cat /dev/urandom
これにより、システムに人為的な負荷がかかり、測定が容易になります。これは実際の負荷の例ではありませんが、CPUSharesの要点を強調しています。また、計算を非常に簡単にするために、単一のvCPUを備えたCentOS8を実行する仮想マシンをセットアップしました。そのことを念頭に置いて、最初のステップは、cgroupコントローラー用のいくつかのディレクトリを作成することです。
# mkdir -p /my_cgroups/{memory,cpusets,cpu}
次に、cgroupsを次のフォルダーにマウントします。
# mount -t cgroup -o memory none /my_cgroups/memory
# mount -t cgroup -o cpu,cpuacct none /my_cgroups/cpu
# mount -t cgroup -o cpuset none /my_cgroups/cpusets
独自のcgroupを作成するには、使用するコントローラーの下に新しいディレクトリを作成するだけです。この場合、私はファイルcpu.shares
を扱っています 、cpu
にあります ディレクトリ。それでは、cpu
の下にいくつかのcgroupを作成しましょう。 コントローラー:
# mkdir -p /my_cgroups/cpu/{user1,user2,user3}
ディレクトリはコントローラによって自動的に入力されることに注意してください:
# ls -l /my_cgroup/cpu/user1/
-rw-r--r--. 1 root root 0 Sep 5 10:26 cgroup.clone_children
-rw-r--r--. 1 root root 0 Sep 5 10:26 cgroup.procs
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.stat
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_all
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu_sys
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu_user
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_sys
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_user
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.cfs_period_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.cfs_quota_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.rt_period_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.rt_runtime_us
-rw-r--r--. 1 root root 0 Sep 5 10:20 cpu.shares
-r--r--r--. 1 root root 0 Sep 5 10:26 cpu.stat
-rw-r--r--. 1 root root 0 Sep 5 10:26 notify_on_release
-rw-r--r--. 1 root root 0 Sep 5 10:23 tasks
いくつかのcgroupを設定したので、次は負荷を生成します。このために、3つのSSHセッションを開き、フォアグラウンドで次のコマンドを実行します。
# cat /dev/urandom
結果はtop
で確認できます :
重要な注意事項 :CPUSharesはトップレベルのcgroupに基づいていることに注意してください。これは、デフォルトでは制約されていません。これは、ツリーの上位のプロセスがCPUSharesを要求した場合、システムがそのプロセスを優先することを意味します。これは人々を混乱させる可能性があります。混乱を避けるために、システム上にcgroupレイアウトを視覚的に表現することが重要です。
上のスクリーンショットでは、すべてのcat
プロセスは、ほぼ同じ量のCPU時間を受け取ります。これは、デフォルトで、cgroupsにcpu.shares
で値1024が指定されているためです。 。前述のように、これらの共有は、親と他のcgroupとの関係によって制約されます。この例では、親の体重を調整していません。したがって、すべての親cgroupが同時にリソースを要求する場合、デフォルトの重みである1024CPUSharesが適用されます。
例に戻ると、いくつかのデフォルト値を使用してcgroupを作成しました。つまり、各グループのデフォルトの重みは1024です。これを変更するには、cpu.shares
の値を変更するだけです。 ファイル:
# echo 2048 > user1/cpu.shares
# echo 768 > user2/cpu.shares
# echo 512 > user3/cpu.shares
すばらしいです。現在、より複雑な均等化計算がありますが、実際にはcgroupにプロセスを追加していません。したがって、cgroupは非アクティブです。プロセスをcgroupに追加するには、目的のPIDをtasks
に追加するだけです。 ファイル:
# echo 2023 > user1/tasks
top
に表示されているように、プロセスをcgroupに追加した結果は次のとおりです。 :
上のスクリーンショットでわかるように、新しいcgroupのプロセスはCPU時間の約半分を受け取ります。これは、以前の方程式によるものです:
先に進み、他の2つのプロセスをそれぞれのcgroupに追加して、結果を観察してみましょう。
# echo 2024 > user2/tasks
# echo 2025 > user3/tasks
これで、cgroup user1 を使用して、重み付けが有効になっていることがわかります。 CPU時間の約61%を占める:
残りの時間はuser2に分割されます およびuser3 。
もちろん、テストのセットアップにはいくつかの問題があります。
- これらはすべて手作業で作成されています。 cgroupに入れているプロセスがそのPIDを変更するとどうなりますか?
- 作成されたカスタムファイルとフォルダは再起動後も存続しません。
- これは多くの手作業です。ツールはどこにありますか?
恐れることはありません、私の友人、systemdはあなたをカバーしました。
[無料のオンラインコース:Red HatEnterpriseLinuxの技術概要。 ]
まとめ
cgroupの手動管理について理解が深まったので、cgroupとsystemdが連携することの価値をよりよく理解できるようになりました。このシリーズのパート4でそのアイデアを検討します。ちなみに、パート4は結論です。