一、CPU 使用率
爲了維護 CPU 時間，Linux 通過事先定義的節拍率（內核中表示爲 HZ），觸發時間中斷，並使用全局變量 Jiffies 記錄了開機以來的節拍數。每發生一次時間中斷，Jiffies 的值就加 1。節拍率 HZ 是內核的可配選項，可以設置爲 100、250、1000 等。不同的系統可能設置不同數值，你可以通過查詢 /boot/config 內核選項來查看它的配置值。比如在我的系統中，節拍率設置成了 250，也就是每秒鐘觸發 250 次時間中斷
二、CPU 使用率過高怎麼辦？
1、perf top
第一種常見用法是 perf top，類似於 top，它能夠實時顯示佔用 CPU 時鐘最多的函數或者指令，因此可以用來查找熱點函數，使用界面如下所示：
比如上圖CPU時鐘事件總數爲3203009455個，而perf工具採集了14K個時鐘事件。們可以看到，佔用 CPU 時鐘最多的是 perf 工具自身，不過它的比例也只有 4.15%，說明系統並沒有 CPU 性能問題。
2、perf record 和 perf report
perf top 雖然實時展示了系統的性能信息，但它的缺點是並不保存數據，也就無法用於離線或者後續的分析。而 perf record 則提供了保存數據的功能，保存後的數據，需要你用 perf report 解析展示。
三、案例分析
預先安裝 docker、sysstat、perf、ab 等工具，如 apt install docker.io sysstat linux-tools-common apache2-utils
首先，在第一個終端執行下面的命令來運行 Nginx 和 PHP 應用：
$ docker run --name nginx -p 10000:80 -itd feisky/nginx
$ docker run --name phpfpm -itd --network container:nginx
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd
.Requests per second: 11.63[#/sec] (mean)
Time per request: 859.942 [ms] (mean)...
從 ab 的輸出結果我們可以看到，Nginx 能承受的每秒平均請求數只有 11.63。你一定在吐槽，這也太差了吧。那到底是哪裏出了問題呢？我們用 top 和 pidstat 再來觀察下。這次，我們在第二個終端，將測試的請求總數增加到 10000。這樣當你在第一個終端使用性能分析工具時， Nginx 的壓力還是繼續。繼續在第二個終端，運行 ab 命令：
ab -c 10 -n 10000 http://10.240.0.5:10000/
接着，回到第一個終端運行 top 命令，並按下數字 1 ，切換到每個 CPU 的使用率：
top
這裏可以看到，系統中有幾個 php-fpm 進程的 CPU 使用率加起來接近 200%；而每個 CPU 的用戶使用率（us）也已經超過了 98%，接近飽和。這樣，我們就可以確認，正是用戶空間的 php-fpm 進程，導致 CPU 使用率驟升。那再往下走，怎麼知道是 php-fpm 的哪個函數導致了 CPU 使用率升高呢？我們來用 perf 分析一下。在第一個終端運行下面的 perf 命令：
# -g開啓調用關係分析，-p指定php-fpm的進程號21515
$ perf top -g -p 21515
方向鍵切換到 php-fpm，再按下回車鍵展開 php-fpm 的調用關係，你會發現，調用關係最終到了 sqrt 和 add_function。看來，我們需要從這兩個函數入手了。
# 停止原來的應用
$ docker rm -f nginx phpfpm
# 運行優化後的應用
$ docker run --name nginx -p 10000:80 -itd feisky/nginx:cpu-fix
$ docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:cpu-fix
接着，到第二個終端來驗證一下修復後的效果。首先 Ctrl+C 停止之前的 ab 命令後，再運行下面的命令：
ab -c 10 -n 10000 http://10.240.0.5:10000/
在每秒的平均請求數，已經從原來的 11 變成了 223