linux 性能自我學習 ———— cpu 高怎麼辦 [三]

前言

linux 性能分析自我學習。

正文

一般我們說cpu,一般是什麼高呢? 一般是指cpu 使用率高。

那麼什麼是cpu 使用率呢?

cpu 使用率 = 1- 空閒時間/總cpu 時間

平均cpu 使用率 = 1 -(new空閒時間 - old 空閒時間)/ (new總cpu時間 - old總cpu時間)

我們可以使用top 查看:

那麼來看下這些參數的意義:

  1. user (通常爲us), 用戶態的時間。(不包含nice的時間,但是包含guest的時間)

  2. nice (ni) 表示低優先級用戶態cpu 時間,也就是進程的nice 值被調整爲1-19 之間的cpu 時間。 nice 值可取-20-19,數值越大,優先級越低。

  3. system (sys), 表示內核態cpu 時間。

  4. idle, 代表空閒時間。 注意,它不包含等待 i/o 的時間。

  5. iowait (通常爲wa), 表示等待i/o的cpu 時間。

  6. irq(通常爲hi),表示處理硬中斷的cpu 時間

  7. softtirq(si), 表示處理軟中斷的cpu時間

  8. steal(st),表示該系統運行在虛擬機中的時候,被其他虛擬機佔用的cpu時間。

  9. guest(通常縮寫爲guest), 代表虛擬化運行其他操作系統的時間,也就是運行虛擬機的cpu時間

  10. guest_nice(通常縮寫爲gnice),表示低優先級運行虛擬機的時間。

然後下面是進程佔用cpu的時間,但是其中間並沒有分爲用戶態使用率和內核態使用率

那麼就需要使用pidstat:

那麼我們怎麼定位cpu 高到底是怎麼造成的呢?

一般使用perf 這個工具。

如果使用perf top 看下,那麼是怎麼樣的呢?

第一行包含3個數據, 分別是採樣數, 事件類型event, 事件總數量。

第二行:

overhead, 是該符號的性能事件在所有采樣中的比例,用百分號來表示

shared, 是該函數或指令所在的動態共享對象(dynamic shared object), 如內核,進程名,動態鏈接庫名, 內核模塊名等。

object, 是動態共享對象的類型,比如. 表示用戶空間的可執行程序或者鏈接庫,而k 表示內核空間

symbol, 是符號名,也是函數名。當函數未知時候,用十六進制地址表示。

還可以直接使用perf record 和 perf report。

perf record 將信息收集起來。

然後perf report 就打開記錄進行分析。

一般我們定位到具體的pid的時候,那麼會使用:

perf -g -p xxx

這個-g 表示了,調用關係。

然後一般我們的web 服務會進行壓測。

一般使用ab。

ab -c 10 -n 10000 http://10.254.0.5:10000

這樣去壓測,如果壓測吞吐很低,那麼就應該分析性能問題。

實驗

實驗:cpu 很高,但是找不到cpu高的應用。

運行nginx:

docker run --name nginx -p 10000:80 -itd feisky/nginx:sp

運行php代碼:

docker run --name phpfdm -itd --network container:nginx feisky/php-fpm:sp

curl 一下:

 curl http://192.168.62.136:10000

發現成功. 壓測一下:

ab -c 100 -n 1000 http://192.168.62.136:10000/

ab 安裝:

yum -y install httpd-tools

結果爲:

每秒60多,有點小低了。

ab -c 5 -t 600 http://192.168.62.136:10000/

通過top 看一下cpu情況:

發現top 很高,但是進程cpu不高,這怎麼說?

難道還有進程不佔用cpu?

通過pidstat 查看一下:

cpu 也不高啊。

通過task 這一行看下,發現就緒隊列有6個:

詭異的事情出現了,這一排居然沒有發現6個就緒進程。

那麼可能原因是什麼呢?

  1. 進程在不停的崩潰重啓,比如因爲段錯誤等。 這時候,進程在推出後又被監控系統自動重啓了。

  2. 這些進程是短時進程,也就是在其他應用內部通過exec 調用的外部命令。這些命令一般都只運行很短時間就會結束,你很難用top這種間隔比較長的工具發現。

用ps tree 查看一下:

yum -y install psmisc

這裏可以看到php-fpm 中啓動了stress,那麼是不是stress的問題呢?

這個時候可以看代碼,其實一般看錯誤日誌就知道了。

這種排查方式比較慢,直接用perf比較好。

的確看到了stree,但是cpu 使用高還是kernel,內核方法。

perf record -g

等一段時間看下情況:

perf report

那麼有沒有其他短時進程監控能馬上能查看到的呢? execsnoop.

centos 怎麼安裝呢?

下載:

https://github.com/brendangregg/perf-tools

一般我會下載zip,然後解壓。

然後運行:

./perf-tools/perf-tools-master/bin/execsnoop 

不可中斷進程和殭屍進程。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章