web-dev-qa-db-ja.com

Linux cgroupを使用してCPUパフォーマンスのバランスをとる

Linux cgroupを使用して、比較的最近のカーネルで2つのデュアルコアLinuxシステムをインストールしています。 1つはDebian Squeezeを実行し、もう1つはUbuntu 11.04 Natty Narwhalを実行しています。古いカーネルにもかかわらず、Debianシステムでcgroupが少しうまく機能するようにCPU負荷分散を実現しました。しかし、それはすべてに当てはまるわけではなく、ここで私が質問している特定の奇妙さは両方のシステムで発生します。

コントロールグループを使用した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

なぜこれが機能するのかを説明することは、以前の方法が機能しない理由を解明するための有用なステップになるでしょう。

linuxperformancecgroups
13
Greg Smith

このテストケースについての最初の説明は、この例の元となった論文を書いたStefan Seyfriedから受け取りました。ここでの問題は、cgroupのCPUスケジューラの部分は常に、使用可能なCPUをビジー状態に保つことを目的としていることです。すべてが一度に収まれば、ハードリミットは強制されません。

2つのプロセス（ここでは高低）が2以上のコアで実行されている場合、一方のコアで高を維持し、もう一方のコアで低を維持します。両方とも、100％近くの使用率で常時実行されます。これは、スケジューラがCPUに十分な時間を与えない状況にぶつかることなく実行できるためです。 cpu.shareスケジューリングは、不足がある場合にのみ発生します。

2番目のケースでは、両方のプロセスが同じCPUに固定されています。次に、CPU共有ロジックは、cpu.sharesの相対的な数値を使用して、それらのバランスをとるのに役立つ何かを行わなければなりません。

CPU使用率のハード制限は、 CFS帯域幅制御パッチ ヒットまで表示されません。その時点で、私が望んでいたもののようなものを手に入れることが可能かもしれません。

10
Greg Smith