$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/

進(jìn)入交互模式后:

輸入M，進(jìn)程列表按內(nèi)存使用大小降序排序，便于我們觀察最大內(nèi)存使用者使用有問題（檢測內(nèi)存泄漏問題）;
輸入P，進(jìn)程列表按CPU使用大小降序排序，便于我們觀察最耗CPU資源的使用者是否有問題；

top第三行顯示當(dāng)前系統(tǒng)的，其中有兩個值很關(guān)鍵:

%id：空閑CPU時間百分比，如果這個值過低，表明系統(tǒng)CPU存在瓶頸；
%wa：等待I/O的CPU時間百分比，如果這個值過高，表明IO存在瓶頸；

分析內(nèi)存瓶頸

查看內(nèi)存是否存在瓶頸，使用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

top工具顯示了free工具的第一行所有信息，但真實可用的內(nèi)存，還需要自己計算才知道; 系統(tǒng)實際可用的內(nèi)存為free工具輸出第二行的free+buffer+cached；也就是第三行的free值191580；關(guān)于free命令各個值的詳情解讀，請參考這篇文章 :ref:free ;

如果是因為缺少內(nèi)存，系統(tǒng)響應(yīng)變慢很明顯，因為這使得系統(tǒng)不停的做換入換出的工作;

進(jìn)一步的監(jiān)視內(nèi)存使用情況，可使用vmstat工具，實時動態(tài)監(jiān)視操作系統(tǒng)的內(nèi)存和虛擬內(nèi)存的動態(tài)變化。參考： :ref:vmstat ;

分析IO瓶頸

如果IO存在性能瓶頸，top工具中的%wa會偏高；

進(jìn)一步分析使用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

如果%iowait的值過高，表示硬盤存在I/O瓶頸。
如果 %util 接近 100%，說明產(chǎn)生的I/O請求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷，該磁盤可能存在瓶頸。
如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；
如果 await 遠(yuǎn)大于 svctm，說明I/O 隊列太長，io響應(yīng)太慢，則需要進(jìn)行必要優(yōu)化。
如果avgqu-sz比較大，也表示有大量io在等待。

更多參數(shù)說明請參考 :ref:iostat ;

分析進(jìn)程調(diào)用

通過top等工具發(fā)現(xiàn)系統(tǒng)性能問題是由某個進(jìn)程導(dǎo)致的之后，接下來我們就需要分析這個進(jìn)程；繼續(xù) 查詢問題在哪；

這里我們有兩個好用的工具： pstack和pstrace

pstack用來跟蹤進(jìn)程棧，這個命令在排查進(jìn)程問題時非常有用，比如我們發(fā)現(xiàn)一個服務(wù)一直處于work狀態(tài)（如假死狀態(tài)，好似死循環(huán)），使用這個命令就能輕松定位問題所在；可以在一段時間內(nèi)，多執(zhí)行幾次pstack，若發(fā)現(xiàn)代碼?？偸峭Ｔ谕粋€位置，那個位置就需要重點關(guān)注，很可能就是出問題的地方；

示例：查看bash程序進(jìn)程棧::

/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用來跟蹤進(jìn)程中的系統(tǒng)調(diào)用；這個工具能夠動態(tài)的跟蹤進(jìn)程執(zhí)行時的系統(tǒng)調(diào)用和所接收的信號。是一個非常有效的檢測、指導(dǎo)和調(diào)試工具。系統(tǒng)管理員可以通過該命令容易地解決程序問題。

參考： ref:strace

優(yōu)化程序代碼

優(yōu)化自己開發(fā)的程序，建議采用以下準(zhǔn)則::

二八法則：在任何一組東西中，最重要的只占其中一小部分，約20%，其余80%的盡管是多數(shù)，卻是次要的；在優(yōu)化實踐中，我們將精力集中在優(yōu)化那20%最耗時的代碼上，整體性能將有顯著的提升；這個很好理解。函數(shù)A雖然代碼量大，但在一次正常執(zhí)行流程中，只調(diào)用了一次。而另一個函數(shù)B代碼量比A小很多，但被調(diào)用了1000次。顯然，我們更應(yīng)關(guān)注B的優(yōu)化。
編完代碼，再優(yōu)化；編碼的時候總是考慮最佳性能未必總是好的；在強(qiáng)調(diào)最佳性能的編碼方式的同時，可能就損失了代碼的可讀性和開發(fā)效率；

gprof使用步驟

用gcc、g++、xlC編譯程序時，使用-pg參數(shù)，如：g++ -pg -o test.exe test.cpp編譯器會自動在目標(biāo)代碼中插入用于性能測試的代碼片斷，這些代碼在程序運行時采集并記錄函數(shù)的調(diào)用關(guān)系和調(diào)用次數(shù)，并記錄函數(shù)自身執(zhí)行時間和被調(diào)用函數(shù)的執(zhí)行時間。
執(zhí)行編譯后的可執(zhí)行程序，如：./test.exe。該步驟運行程序的時間會稍慢于正常編譯的可執(zhí)行程序的運行時間。程序運行結(jié)束后，會在程序所在路徑下生成一個缺省文件名為gmon.out的文件，這個文件就是記錄程序運行的性能、調(diào)用關(guān)系、調(diào)用次數(shù)等信息的數(shù)據(jù)文件。
使用gprof命令來分析記錄程序運行信息的gmon.out文件，如：gprof test.exe gmon.out則可以在顯示器上看到函數(shù)調(diào)用相關(guān)的統(tǒng)計、分析信息。上述信息也可以采用gprof test.exe gmon.out> gprofresult.txt重定向到文本文件以便于后續(xù)分析。

關(guān)于gprof的使用案例，請參考 f1;

其它工具

調(diào)試內(nèi)存泄漏的工具valgrind，感興趣的朋友可以google了解；

OProfile: Linux 平臺上的一個功能強(qiáng)大的性能分析工具,使用參考 f2;

除了上面介紹的工具，還有一些比較全面的性能分析工具，比如sar（Linux系統(tǒng)上默認(rèn)不安裝，需要手動安裝下）；將sar的常駐監(jiān)控工具打開后，能夠收集比較全面的性能分析數(shù)據(jù)；

關(guān)于sar的使用，參考 :ref:sar ;

上一篇：文本處理下一篇：nm 目標(biāo)文件格式分析