linuxパフォーマンス最適化
性能最適化の核心はシステムのボトルネック点を探し出すことであり、問題が見つかり、最適化の仕事も大半を完成した.ここで紹介する性能最適化は主に2つのレベルから紹介される:システムレベルとプログラムレベル;
システム応答が遅くなると、まず大体の問題がどこにあるのか、IOボトルネック、CPUボトルネック、メモリボトルネックなのか、プログラムによるシステム問題なのかを特定しなければならない.
トップツールを使用すると、注目している点をより包括的に表示できます.
インタラクティブモードに入ると、はMを入力し、プロセスリストはメモリ使用サイズの降順に並べ替えられ、最大メモリ使用者の使用に問題がある(メモリ漏れ問題を検出する)ことを観察するのに便利である. はPを入力し、プロセスリストはCPU使用サイズの降順に並べ替えられ、最もCPU資源を消費する使用者に問題があるかどうかを観察するのに便利である.
トップ3行目は、現在のシステムの2つの値が重要であることを示します.%id:アイドルCPU時間パーセント、この値が低すぎると、システムCPUにボトルネックがあることを示します. %wa:I/O待ちのCPU時間の割合.この値が高すぎると、IOにボトルネックがあることを示す.
メモリにボトルネックがあるかどうかを確認し、topコマンドを使用するのは面倒ですが、freeコマンドはより直感的です.
トップツールにはfreeツールの最初の行のすべての情報が表示されますが、実際に使用可能なメモリは、自分で計算する必要があります.システムが実際に使用できるメモリはfreeツールで2行目のfree+buffer+cachedを出力します.すなわち、3行目のfree値191580です.freeコマンドの各値の詳細については、この記事freeを参照して使用可能なメモリをクエリーしてください.
メモリが不足しているため、システムの応答が遅くなるのは明らかです.これは、システムが交換作業を続けているからです.
さらにメモリの使用状況を監視し、vmstatツールを使用して、オペレーティングシステムのメモリと仮想メモリの動的変化をリアルタイムで動的に監視できます.参考:vmstatはメモリの使用状況を監視します.
IOにパフォーマンスのボトルネックがある場合、topツールの%waが高くなります.
さらにiostatツールを使用する分析:%iowaitの値が高すぎると、ハードディスクにI/Oボトルネックがあることを示します. %utilが100%に近い場合は、発生したI/O要求が多すぎて、I/Oシステムがフル負荷になっていることを示し、ディスクにボトルネックがある可能性があります. svctmがawaitに近い場合は、I/Oに待ち時間がほとんどないことを示します. awaitがsvctmよりはるかに大きい場合、I/Oキューが長すぎ、io応答が遅すぎることを示す場合は、必要な最適化が必要です. avgqu-szが比較的大きい場合は、ioが大量に待っていることも示します.
詳細パラメータの説明はiostat監視I/Oサブシステムを参照してください.
topなどのツールを通じてシステムの性能の問題があるプロセスによって引き起こされたことを発見した後、次に私たちはこのプロセスを分析する必要があります.質問がどこにあるかをクエリーし続けます.
ここには2つの使いやすいツールがあります.pstackとpstraceです.
pstackはプロセススタックを追跡するために使用されます.このコマンドは、プロセスの問題を調べるときに非常に役立ちます.例えば、サービスがワーク状態(仮死状態、死循環のような)にあることを発見し、このコマンドを使用すると問題の所在を簡単に特定できます.しばらくの間、pstackを何回も実行することができ、コードスタックがいつも同じ位置に止まっていることを発見したら、その位置に重点を置く必要があり、問題が発生した場所である可能性が高い.
例:bashプログラムプロセススタックの表示:
straceはプロセス内のシステム呼び出しを追跡するために使用されます.このツールは、プロセス実行時のシステム呼び出しと受信した信号を動的に追跡することができる.非常に効果的な検出、アドバイザ、デバッグツールです.システム管理者は、このコマンドによってプログラムの問題を簡単に解決できます.
参照:straceトラッキングプロセスのシステム呼び出し;
自分で開発したプログラムを最適化し、以下のガイドラインを推奨します.二八法則:どのグループのものの中で、最も重要なのはその中のほんの一部だけを占めて、約20%で、残りの80%は多数であるにもかかわらず、副次的である.最適化の実践では、20%の最も時間がかかるコードの最適化に集中し、全体的な性能が著しく向上します.これはよく分かります.関数Aは符号量が大きいが、通常の実行フローでは1回のみ呼び出される.一方,もう1つの関数Bのコード量はAよりずっと小さいが,1000回呼び出された.明らかに、Bの最適化に注目すべきである. コードを作成し、最適化します.符号化時に常に最適な性能が必ずしも良いとは限らないことを考慮する.最適な性能の符号化方式を強調すると同時に、コードの可読性と開発効率を損なう可能性がある.
gcc、g++、xlCでプログラムをコンパイルする場合、-pgパラメータ、例えば、g++-pg-o testを用いる.exe test.cppコンパイラは、プログラム実行時に関数の呼び出し関係と呼び出し回数を収集して記録し、関数自体の実行時間と呼び出された関数の実行時間を記録するパフォーマンステスト用のコード断片を自動的にターゲットコードに挿入します. コンパイルされた実行可能プログラム(例:./test.exe.このステップでプログラムを実行する時間は、通常コンパイルされている実行可能プログラムの実行時間よりやや遅くなります.プログラムの実行が終了すると、プログラムが存在する経路の下にデフォルトのファイル名gmonが生成される.outのファイルです.このファイルは、プログラムの実行性能、呼び出し関係、呼び出し回数などの情報を記録するデータファイルです. gprofコマンドを使用して、プログラムの実行情報を記録するgmonを解析する.outファイル、例えば:gprof test.exe gmon.outは,関数呼び出しに関する統計,解析情報をディスプレイに表示できる.上記の情報はgprof testを用いるもよい.exe gmon.out> gprofresult.txtは、後続の分析を容易にするためにテキストファイルにリダイレクトされます.
gprofの使用例については[f 1]を参照してください.
メモリ漏洩をデバッグするツールvalgrind、興味のある友达はgoogleで理解することができます;
OProfile:Linuxプラットフォーム上の強力な性能分析ツールであり、参照[f 2]を使用する.
上記のツールのほかに、sar(Linuxシステムではデフォルトではインストールされていませんが、手動でインストールする必要があります)など、比較的包括的なパフォーマンス分析ツールもあります.sarの常駐監視ツールを開くと、比較的包括的な性能分析データを収集することができる.
sarの使用については、sarを参照してシステムのボトルネックの利器を見つける.
[f1]
C++の性能最適化実践http://www.cnblogs.com/me115/archive/2013/06/05/3117967.html
[f2]
OProfileで性能を徹底的に理解するhttp://www.ibm.com/developerworks/cn/linux/l-oprof/
[f3]
Linuxのfreeコマンドの詳細http://www.cnblogs.com/coldplayerest/archive/2010/02/20/1669949.html
システムボトルネックの分析
システム応答が遅くなると、まず大体の問題がどこにあるのか、IOボトルネック、CPUボトルネック、メモリボトルネックなのか、プログラムによるシステム問題なのかを特定しなければならない.
トップツールを使用すると、注目している点をより包括的に表示できます.
$top
top - 09:14:56 up 264 days, 20:56, 1 user, load average: 0.02, 0.04, 0.00
Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.2%st
Mem: 377672k total, 322332k used, 55340k free, 32592k buffers
Swap: 397308k total, 67192k used, 330116k free, 71900k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 2856 656 388 S 0.0 0.2 0:49.40 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 7:15.20 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/
インタラクティブモードに入ると、
トップ3行目は、現在のシステムの2つの値が重要であることを示します.
メモリボトルネックの解析
メモリにボトルネックがあるかどうかを確認し、topコマンドを使用するのは面倒ですが、freeコマンドはより直感的です.
[/home/weber#]free
total used free shared buffers cached
Mem: 501820 452028 49792 37064 5056 136732
-/+ buffers/cache: 310240 191580
Swap: 0 0 0
[/home/weber#]top
top - 17:52:17 up 42 days, 7:10, 1 user, load average: 0.02, 0.02, 0.05
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 501820 total, 452548 used, 49272 free, 5144 buffers
KiB Swap: 0 total, 0 used, 0 free. 136988 cached Mem
トップツールにはfreeツールの最初の行のすべての情報が表示されますが、実際に使用可能なメモリは、自分で計算する必要があります.システムが実際に使用できるメモリはfreeツールで2行目のfree+buffer+cachedを出力します.すなわち、3行目のfree値191580です.freeコマンドの各値の詳細については、この記事freeを参照して使用可能なメモリをクエリーしてください.
メモリが不足しているため、システムの応答が遅くなるのは明らかです.これは、システムが交換作業を続けているからです.
さらにメモリの使用状況を監視し、vmstatツールを使用して、オペレーティングシステムのメモリと仮想メモリの動的変化をリアルタイムで動的に監視できます.参考:vmstatはメモリの使用状況を監視します.
IOボトルネックの分析
IOにパフォーマンスのボトルネックがある場合、topツールの%waが高くなります.
さらにiostatツールを使用する分析:
/root$iostat -d -x -k 1 1
Linux 2.6.32-279.el6.x86_64 (colin) 07/16/2014 _x86_64_ (4 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.02 7.25 0.04 1.90 0.74 35.47 37.15 0.04 19.13 5.58 1.09
dm-0 0.00 0.00 0.04 3.05 0.28 12.18 8.07 0.65 209.01 1.11 0.34
dm-1 0.00 0.00 0.02 5.82 0.46 23.26 8.13 0.43 74.33 1.30 0.76
dm-2 0.00 0.00 0.00 0.01 0.00 0.02 8.00 0.00 5.41 3.28 0.00
詳細パラメータの説明はiostat監視I/Oサブシステムを参照してください.
分析プロセス呼び出し
topなどのツールを通じてシステムの性能の問題があるプロセスによって引き起こされたことを発見した後、次に私たちはこのプロセスを分析する必要があります.質問がどこにあるかをクエリーし続けます.
ここには2つの使いやすいツールがあります.pstackとpstraceです.
pstackはプロセススタックを追跡するために使用されます.このコマンドは、プロセスの問題を調べるときに非常に役立ちます.例えば、サービスがワーク状態(仮死状態、死循環のような)にあることを発見し、このコマンドを使用すると問題の所在を簡単に特定できます.しばらくの間、pstackを何回も実行することができ、コードスタックがいつも同じ位置に止まっていることを発見したら、その位置に重点を置く必要があり、問題が発生した場所である可能性が高い.
例:bashプログラムプロセススタックの表示:
/opt/app/tdev1$ps -fe| grep bash
tdev1 7013 7012 0 19:42 pts/1 00:00:00 -bash
tdev1 11402 11401 0 20:31 pts/2 00:00:00 -bash
tdev1 11474 11402 0 20:32 pts/2 00:00:00 grep bash
/opt/app/tdev1$pstack 7013
#0 0x00000039958c5620 in __read_nocancel () from /lib64/libc.so.6
#1 0x000000000047dafe in rl_getc ()
#2 0x000000000047def6 in rl_read_key ()
#3 0x000000000046d0f5 in readline_internal_char ()
#4 0x000000000046d4e5 in readline ()
#5 0x00000000004213cf in ?? ()
#6 0x000000000041d685 in ?? ()
#7 0x000000000041e89e in ?? ()
#8 0x00000000004218dc in yyparse ()
#9 0x000000000041b507 in parse_command ()
#10 0x000000000041b5c6 in read_command ()
#11 0x000000000041b74e in reader_loop ()
#12 0x000000000041b2aa in main ()
straceはプロセス内のシステム呼び出しを追跡するために使用されます.このツールは、プロセス実行時のシステム呼び出しと受信した信号を動的に追跡することができる.非常に効果的な検出、アドバイザ、デバッグツールです.システム管理者は、このコマンドによってプログラムの問題を簡単に解決できます.
参照:straceトラッキングプロセスのシステム呼び出し;
オプティマイザコード
自分で開発したプログラムを最適化し、以下のガイドラインを推奨します.
gprof使用手順
gprofの使用例については[f 1]を参照してください.
その他のツール
メモリ漏洩をデバッグするツールvalgrind、興味のある友达はgoogleで理解することができます;
OProfile:Linuxプラットフォーム上の強力な性能分析ツールであり、参照[f 2]を使用する.
上記のツールのほかに、sar(Linuxシステムではデフォルトではインストールされていませんが、手動でインストールする必要があります)など、比較的包括的なパフォーマンス分析ツールもあります.sarの常駐監視ツールを開くと、比較的包括的な性能分析データを収集することができる.
sarの使用については、sarを参照してシステムのボトルネックの利器を見つける.
[f1]
C++の性能最適化実践http://www.cnblogs.com/me115/archive/2013/06/05/3117967.html
[f2]
OProfileで性能を徹底的に理解するhttp://www.ibm.com/developerworks/cn/linux/l-oprof/
[f3]
Linuxのfreeコマンドの詳細http://www.cnblogs.com/coldplayerest/archive/2010/02/20/1669949.html