Linuxオペレーティングシステム時間相関関数性能低下原因分析

2582 ワード

linux パフォーマンス time resolution high 2.6.32 usleep

オペレーティングシステムのアップグレード後のアプリケーションのパフォーマンスの低下を調べる過程で、同じハードウェアプラットフォームの2.6.32カーネルバージョンusleep関数で発生したオーバーヘッドは2.6.18カーネルよりはるかに大きいことが分かった.
ソフト・ハードウェア環境は次のとおりです.
ホストA
ホストB
CPU Intel E 5-2630 24コア2.6 GHzメモリDDR 3 64 GB
RHEL-6.4 (Kernel:2.6.32-358.el6 gcc:4.4.7)
RHEL-5.7 (Kernel:2.6.18-274.el5 gcc:4.1.2)
テストコード:

<span style="font-size:18px;">#include<unistd.h>

int main()

{

         for(i = 0; i < 1000; i++)

         {

              usleep(10);

        }

}
 
</span>

次の表は、精度比較の結果です.
usleep間隔
usleep回数
ホストAの所要時間
ホストBの所要時間
せいど
usleep(1)
99999
5.56s
145s
タイミング精度差26倍
usleep(1000)
1000
1.057s
2.001s
タイミング精度差2倍
usleep(10000)
1000
10.061s
11.144s
タイミング精度差10.7%
usleep(50000)
1000
50.064s
51.054
タイミング精度差1.9%
なぜ2.6.32カーネルではusleep精度が高いのですか?
に従ってhttp://elinux.org/High_Resolution_Timersの紹介では、linuxは2.6.21カーネルにHigh Resolution Timersアルゴリズムを採用し、時間精度を大幅に向上させた.
では、High Resolution Timersのオーバーヘッドはどうでしょうか.
次の表はtimeコマンドを用いて統計したusleepオーバーヘッドで、ホストB(2.6.18カーネル)ではusleepがCPU時間をほとんど消費しないことがわかりますが、もちろん精度が悪いです.一方、ホストB(2.6.32コア)では、usleepにCPUオーバーヘッドが発生しており、usleep(1)ではtopコマンドで4～6%のCPUが表示される.
column
usleep
real(s)
user(s)
sys(s)
sum(s)
ホストA
1
0.058
0
0.004
0.004
10
0.061
0
0.004
0.004
100
0.119
0.002
0.004
0.006
1000
1.052
0.001
0.003
0.004
10000
10.056
0.002
0.003
0.005
100000
100.052
0.002
0.004
0.006
ホストB
1
1
0
0
0
10
1.001
0
0
0
100
1.001
0
0
0
1000
2.001
0
0
0
10000
11.001
0
0
0
100000
101.03
0
0
0

異なるusleep間隔に対して描画されるCPU消費曲線から,CPU占有はusleep間隔とは大きく関係しないことがわかる.

High Resolution Timersアルゴリズムはカーネルの下位層の時間機構であるため、select、epool_waitのような代替の時間アルゴリズムは影響を受けます.
推奨事項:
USleepなどの時間切替関数を用いてタスクアイドル切替機能を実現するアプリケーションでは、schedule、pause、pthread_などのCPUオーバーヘッドを低減するために、信号量の起動を待つ方法を採用することができる.cond_waitなど.
参考資料:
http://bbs.csdn.net/topics/380254421
http://elinux.org/High_Resolution_Timers
Littlefang-鎮関西拳打魯智深のCSDNブログから、転載は明記してください

rpm取付パッケージ(ポイント)

EventBus3.0パフォーマンス最適化インデックスの追加(Index)