現在、システムをRHEL 5からRHEL 6に移動することを検討していますが、RHEL 6マシンでのCPU使用率が予想外に高いという問題に遭遇しました。これは、少なくとも部分的には、select
を使用して中断可能なスリープを実行したことが原因である可能性があります。動作を示す簡単な例を次に示します。
#include <sys/select.h>
int main()
{
timeval ts;
for (unsigned int ii=0; ii<10000; ++ii) {
ts.tv_sec = 0;
ts.tv_usec = 1000;
select(0, 0, 0, 0, &ts);
}
return 0;
}
RHEL 5マシンでは、CPU使用率は0%のままですが、RHEL 6がインストールされている同じハードウェアでは、CPUの約0.5%を使用するため、select
を使用して30〜50のプログラムを実行すると、スリープは、不必要に大量のCPUを消費します。
Bugzilla を開いてOProfileを実行しようとすると、アプリケーションのメインで100%、poll_idleで99%を表示するだけです(grubオプションにidle = pollが設定されています)したがって、すべてをキャプチャできます)。
CPU使用率が高くなる原因を特定するために私ができることについて、他に何か考えはありますか?
更新:perfツールを見つけて、次の出力を取得しました:
# Events: 23K cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................... ....................................
#
13.11% test_select_sma [kernel.kallsyms] [k] find_busiest_group
5.88% test_select_sma [kernel.kallsyms] [k] schedule
5.00% test_select_sma [kernel.kallsyms] [k] system_call
3.77% test_select_sma [kernel.kallsyms] [k] copy_to_user
3.39% test_select_sma [kernel.kallsyms] [k] update_curr
3.22% test_select_sma ld-2.12.so [.] _dl_sysinfo_int80
2.83% test_select_sma [kernel.kallsyms] [k] native_sched_clock
2.72% test_select_sma [kernel.kallsyms] [k] find_next_bit
2.69% test_select_sma [kernel.kallsyms] [k] cpumask_next_and
2.58% test_select_sma [kernel.kallsyms] [k] native_write_msr_safe
2.47% test_select_sma [kernel.kallsyms] [k] sched_clock_local
2.39% test_select_sma [kernel.kallsyms] [k] read_tsc
2.26% test_select_sma [kernel.kallsyms] [k] do_select
2.13% test_select_sma [kernel.kallsyms] [k] restore_nocheck
CPU使用率が高いのは、スケジューラーによるもののようです。また、次のbashスクリプトを使用して、これらの100を同時に開始しました。
#!/bin/bash
for i in {1..100}
do
./test_select_small &
done
RHEL 5ではCPU使用率は0%近くにとどまりますが、RHEL 6では、ユーザーとシステムの両方で重要な量のCPU使用率があります。これの本当の原因を追跡し、うまくいけばそれを修正する方法についてのアイデアはありますか?
また、現在のArchLinuxビルドとUbuntu11.10でこのテストを試したところ、同様の動作が見られたため、これはRHELの問題だけでなく、ある種のカーネルの問題のようです。
UPDATE2:これは非常に大きな議論であることを知っているので、これを取り上げるのは少し躊躇しますが、Ubuntu 11.10でBFSパッチを適用してカーネルを試してみましたが、同じ高いシステムCPU使用率が表示されませんでした(ユーザーのCPU使用率が同じ)。
この高いCPU使用率が、CPU使用率の計算の違いであり、人為的に高く見えるかどうかをテストするために、それぞれで実行できるテストはありますか?または、実際のCPUサイクルがCFSによって盗まれている場合はどうなりますか?
UPDATE3:この質問に関連して行われた分析は、それがスケジューラーに関連していることを示しているようですので、結果を議論するために 新しい質問 を作成しました。
UPDATE4: 他の質問 にいくつかの情報を追加しました。
UPDATE5:私は 他の質問 にいくつかの結果を追加しましたが、まだ問題を示している単純なテストからのものです。
あなたが尋ねる:
この高いCPU使用率が、CPU使用率の計算の違いであり、人為的に高く見えるかどうかをテストするために、それぞれで実行できるテストはありますか?または、実際のCPUサイクルがCFSによって盗まれている場合はどうなりますか?
test_select_small
プログラムの実行中にCPUベンチマークを実行し、そのパフォーマンスがホストOSのバージョンに応じて変化するかどうかを確認したらどうなるでしょうか。
選択肢はたくさんあります:古典的なアドバイスは、常に「あなたが持つであろう負荷の種類を表す何かを使うこと」です。しかし、かっこいい子供たちはいつもただ使っていました povray