比較的新しいカーネルを含むLinux cgroupを使用して、2つのデュアルコアLinuxシステムをインストールしました。 1つはDebian Squeezeを実行し、もう1つはUbuntu 11.04 Natty Narwhalを実行しました。 Debianシステムに古いカーネルがあっても、cgroupを介してCPUロードバランシングを実装しましたが、Debianシステムでうまく機能します。しかし、すべての場合に当てはまるわけではなく、ここで私が尋ねる特定の奇妙な動作は両方のシステムで発生します。
読んだらLinuxのリソース管理および制御グループ問題を再現する方法を示す例を示します。これはUbuntuバージョンです(rootとして実行)。
cd /sys/fs/cgroup/cpu
[On Debian Squeeze start at /mnt/cgroups/cpu instead]
mkdir low high
echo 512 > low/cpu.shares
echo 2048 > high/cpu.shares
yes low > /dev/null &
echo $! > low/tasks
yes high > /dev/null &
echo $! > high/tasks
ps -C yes -opid,%cpu,psr,args
[repeat that a few times]
killall -9 yes
私は「低い」プロセスよりも「高い」プロセスがより多くの時間を割り当てると予想しました。このテストケースで実際に起こったことは常に次のようになりました。
root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
PID %CPU PSR COMMAND
3105 88.3 1 yes low
3106 94.5 0 yes high
時間がほぼ同じところ。私の質問は次のとおりです。なぜこれが起こるのですか?
デモでは、各プロセスを同じCPUに固定すると、この問題は消えます。テストする追加の行:
taskset -c 1 yes high > /dev/null &
echo $! > high/tasks
taskset -c 1 yes low > /dev/null &
echo $! > low/tasks
ps -C yes -opid,%cpu,psr,args
[later, rinse, repeat]
killall -9 yes
結果は私が常に期待していたものです。 「高い」プロセスはより高いCPU比を達成します。
root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
PID %CPU PSR COMMAND
3128 83.3 1 yes high
3129 20.7 1 yes low
これが機能する理由を説明することは、以前の方法も機能しない理由を見つけるのに役立つ便利な手順です。
答え1
この例の論文を書いたStefan Seyfriedから、このテストケースの最初の説明を聞きました。ここでの問題は、cgroupのCPUスケジューラ部分が常に使用可能なCPUを使用し続けるように設計されており、すべてが同時に満たされる場合は厳しい制限を適用しないことです。
2つ以上のプロセス(ここではハイとロー)が2つ以上のコアで実行されている場合、1つのコアではハイに維持され、別のコアではローに保たれます。これにより、両方とも常に100%に近い使用量で実行されます。なぜなら、スケジューラは十分なCPU時間を提供しなくてもそうすることができるからです。 cpu.shareスケジューリングは不足している場合にのみ発生します。
2番目のケースでは、両方のプロセスが同じCPUに固定されます。次に、CPU共有ロジックは、相対的なcpu.shares数値を使用してバランスを取るために便利な作業を実行する必要があり、必要に応じて実行されます。
CPU 使用量に対する厳しい制限は、次回以降にのみ発生します。CFS帯域幅制御パッチ殴る。その時点で、私が望んでいたものに似たものを得ることもできます。