Linux下有什麼工具可以分析出一個程序的運算時間分布嗎？

01-06

各位大大…我向一個內存資料庫添加了一個新的檢查點演算法後，使得原本單線程的資料庫變成了多線程，也因此使用了一些鎖機制來保證數據的安全。結果卻是新演算法對單機資料庫性能的影響並不大，並沒有達到理論上的性能。編程語言是C語言。程序中主要使用了自旋鎖和條件變數。
所以我想尋找一個工具或者方法來找出資料庫運行過程中時間都消耗在哪。請各位前輩大神不吝指教。

gperftools

Perf

perf + ftrace雙璧啊。

perf record -a 第一個程序，然後perf record -a 優化過的程序，然後perf diff看分布的區別，大概就可以定位位置。

同時要看idle的分布，如果是切換和等待導致的性能下降，通過ftrace找切換點，找到原因，基本上就可以定位問題了。

perf + flamegraph(http://www.brendangregg.com/flamegraphs.html)

國內極少人知道，業界最頂尖的水準，源於kernel。

簡單點可以使用 gprof，這個工具可以顯示各個函數使用的時間，編譯的時候加上 -pg，先運行一遍程序，gprof會自動加上分析函數，最後使用gprof運行程序，就可以看到各個程序的消耗時間

gcc -pg a.c -o a ./a gprof ./a

gprof 的一個文檔－&> GNU gprof

--------update--------

有童學提出關於多線程的問題,先複製回答如下:

回復 zhanglistar ：gprof 確實默認不支持多線程…在多線程下,只能採集主線程性能數據…但是有一些方法可以解決這個瓶頸…

原來做 openmp 項目的時候使用過gprof 判斷函數性能

沒人提oprofile么，從kernel到應用都有詳盡的數據分析結果。

為什麼要用自璇鎖呢，明明普通的互斥鎖在你請求鎖的時候已經會嘗試自璇了。

太高深了，我來學習學習

perf +1

perf 的開發目前很快, 很多新功能的文檔跟不上, 有人找不到說明書不會用也是可以理解的. 有心的話可以關注一下 lkml.

不過首先應該考慮的並不是工具. 在實際用工具觀察什麼之前, 應該先回答以下問題:

1. 你要測的性能指標是什麼? (既然是資料庫, 那估計是 TPS?)

2. 該性能指標是怎麼計算出來的? 它的基礎過程是什麼? (一個查詢?) 這些過程是並行的還是串列的?

3. 你做的優化在這個基礎過程中處於什麼位置? 如果將一個過程分解, 被優化的部分在整體部分中是什麼位置? 優化前佔整體過程的百分比?

4. 你預測應用了該優化後該過程的情景變成什麼樣了? 對1中提到的性能指標能產生什麼影響?

5. 為了觀察到你在4中提到的變化, 應該看哪些指標? 或者抓什麼 Trace?

在不了解題主的資料庫的情況下, 有以下建議:

1. 按 tracepoint, 抓 sched:sched_switch 和 raw_syscalls, 分析調度軌跡, 看看程序是否串列部分過多, 沒有達到題主期望的並行度.

這方面可以藉助圖形化工具 TraceCompass, 不過用起來確實比較複雜. 基本的順序是:

# perf record -a -e sched:sched_switch -e raw_syscalls:* --exclude-perf ...

# perf data convert --to-ctf ./out.ctf

將 out.ctf 導入 TraceCompass 工具

也可以在 convert 成 CTF 後藉助 libbabeltrace 用 python 腳本分析. 簡單的話也可以手工分析.

2. 如果使用的是 pthread 的 mutex, 也可以觀察一下 futex 系統調用的情況. 用 strace 看就可以, 不過用

# perf record -a -e syscalls:sys_enter_futex -e syscalls:sys_exit_futex ...

開銷也許會小一些.

3. 想得到某個用戶態函數的執行時間, 可以通過 uprobe 打點:

# perf probe /a/b/c.so func

# perf probe /a/b/c.so func%return

然後抓這兩個點, 用 perf script 觀察函數進入和退出的時間.

4. 如果用了用戶態自旋鎖(如果是題主自己實現的, 恐怕要檢查一下自旋鎖實現的正確性), 可以用 perf top 觀察一下該自旋鎖是否為熱點函數.

5. 如果有這種疑問: "可能有個指令執行的次數較多，但不一定耗時啊", 可以關注一下 cycles 和 instructions.

#　perf stat -e {cycles,instructions} ...

然後計算一下 IPC, 看看指令執行的快還是慢. 有 TopDown 模型能夠將這些計數器翻譯成更容易理解的數據. 不過只有 vTune 知道這些細節.

系統級的性能分析可以關注一下 Brendan Gregg 的 blog. 有時候會有一些新點子.

gperftools

systemtap

intel parallel studio

我用過gprof、valgrind、intel vtune，相比較而言，尋找性能瓶頸是vtune最好用。可惜有點貴。

利益相關：intel前員工

intel vtune

用perf top -p大概能看到哪cpu用得多

valgrind，不過不能分析鎖和系統調用的消耗。