1、通過top命令查看其CPU占用
可以看到其load占用為“20.14, 16.42, 19.16”，三個數字分別表示cpu在1分鍾、5分鍾及15分鍾的load，cpu的使用率也偏高，達到了68.8％，占用cpu較高的進程ID為281020。
2、通過ps查看該應用
$ ps aux|grep 281020
root 212891 0.0 0.0 103328 848 pts/3 S+ 15:41 0:00 grep 281020
ipcc 281020 39.5 2.6 1025560 425540 ? Sl 01:18 341:29 /usr/bin/python ./ctiRealtimeCdrMain.py default.xml
3、查看進程中線程的CPU占用情況
在top中加入-H參數，查看該進程中線程的cpu戰勝情況：
$ top -H -p 281020
結果如下：
可以看到進程281020中線程號為281042的線程戰勝的CPU最多。
4、跟蹤進程的執行棧
通過watch和pstack命令查看線程中命令的執行情況：
watch pstack 281042
可以看到從mysql中讀取數據占用資源較多。
5、跟蹤函數的調用
進一步通過strace命令進行驗證：
strace -f -p 281042
結果如下：
其中大量的數據在執行數據庫的寫入（write）及讀取（read）操作，上面的pstack命令並沒有反映出write的問題，那問題應該出現在數據庫的read操作上，初步猜測是數據庫的select語句有問題，或者是沒有走索引
6、檢查MySql的慢日志
進一步檢查MySql的慢日志發現：
其中有大量的查詢慢日志，SQL中使用了全表掃描的count、max、min這樣的函數，終於確認問題造成的原因了，余下的就是讓對方對做優化了。