Linux效能優化-CPU效能優化思路
目錄
CPU效能指標
CPU使用率
1.CPU使用率描述了非空閒時間佔總CPU時間的百分比，根據CPU上執行任務的不同，又被分為
使用者CPU，系統CPU，等待I/O CPU，軟中斷和硬中斷等
2.系統CPU使用率，表示CPU在核心態執行時間的百分比(不包括中斷)，系統CPU使用率搞說明核心比較繁忙
3.等待/IO的CPU使用率，iowait，表示等待I/O的時間百分比，iowait高說明系統與硬體裝置的I/O互動時間比較長
4.軟中斷和硬中斷的CPU使用率，分別表示核心呼叫軟中斷處理程式，硬中斷處理程式的時間百分比，他們的使用率高，通常說明系統發生了大量的中斷
5.虛擬化中的竊取CPU使用率(steal)，表示被其他虛擬機器佔用的CPU時間百分比
6.客戶CPU使用率(guest)，執行客戶虛擬機器的CPU時間百分比
平均負載(load average)
也就是系統平均活躍程序數，它反映了系統的整體負載情況，主要包括三個數值，分別指過去1分鐘，過去5分鐘，過去15分鐘的平均負載
上下文切換
1.無法獲取資源而導致的自願上下文切換
2.被系統強制排程導致的非自願上下文切換
上下文切換，本身是保證linux正常執行的一項核心功能，但過多的上下文切換，會將原本執行程序的CPU時間，消耗在暫存器，核心棧以及虛擬記憶體等資料的儲存和恢復上，縮短程序真正執行的時間，成為效能瓶頸
CPU快取的命中率
由於CPU發展的速度遠快於記憶體的發展，CPU的處理速度也就比記憶體的訪問速度快很多，這樣CPU在訪問記憶體的時候，免不了等待記憶體的響應，為了協調者兩者的效能差距，CPU快取(通常是多級快取)就出現了
關於CPU效能分析的 指標篩選清單
效能工具
把效能指標和效能工具聯絡起來
1.從CPU的效能指標出發，當需要檢視某個效能指標時，要清朝哪些工具可以做到
要根據不同的效能指標，對提供指標的效能工具進行分類和理解，在實際派出效能問題時，就可以清楚知道，什麼工具可以提供你想要的指標，而不是毫無根據的挨個嘗試，
比如top發現了軟中斷CPU使用率高後，下一步就需要知道具體的軟中斷型別，/proc/softirqs
比如找到軟中斷型別是網路接收，那就繼續往網路接收方向思考，系統網路接收情況是什麼樣，什麼工具可以檢視網路接收情況
根據指標查詢工具
2.從工具出發，當安裝了某個工具後，要知道這個攻擊能提供哪些指標
在生產環境中，可能沒有許可權安裝新的工具包，只能最大化利用好系統中已經安裝好的工具，這就需要你對他們又足夠的瞭解
具體到每個攻擊的使用方法，一般都支援豐富的配置選項
如何迅速的分析CPU效能瓶頸
實際生產環境中，我們都希望儘可能快的定位系統瓶頸，然後儘可能快的優化效能
雖然CPU效能指標很多，但他們並不是完全孤立的，很多指標間都有一定的關聯，要弄清效能指標的關聯性，就要知道每種效能指標的工作原理
可以通過 top，vmstat，pidstat 這三個工具來排查問題，因為這三個工具支援很多指標
top，vmstat，pidstat 分別提供了重要的CPU指標，並通過虛線表示關聯關係
1.從top的輸出可以得到各種CPU使用率以及殭屍程序和平均負載等資訊
2.從vmstat的輸出可以得到上下文切換次數，中斷次數，執行狀態和不可中斷狀態的程序數
3.從pidstat的輸出可以得到程序使用者CPU使用率，系統CPU使用率，自願上下文切換和非自願上下文切換情況
比如
1.top發現使用者CPU使用率有問題，可以用pidstat接著分析是哪個程序導致的
2.top的平均負載比較高，可以跟vmstat的執行狀態和不可中斷狀態程序數做對比，觀察是哪種程序導致的負載升高
3.當top輸出的軟中斷CPU使用率升高，可以檢視/proc/softirqs中的各種型別軟中斷變化情況，確定是哪種軟中斷出的問題，比如發現網路接收中斷導致的問題，可以繼續用sar和tcpdump分析
效能優化方法論
1.要做效能優化，怎麼判斷它是不是有效？特別是優化之後，能提升多少效能？
2.效能問題通常不是獨立的，如果有多個性能問題同時發生，應該先優化哪一個？
3.提升效能的方法並不是唯一的，當有多種方法可以選擇時，選用哪一種？是不是總選能最大程度提升效能的方案？
比如前面例子中的一個程序使用直接I/O導致iowait很高，如果將直接I/O改成快取I/O呢？對於上面的三問就是
1.直接I/O換成快取I/O，可以把iowait從90%降低到接近0，效能提升很明顯
2.沒有發現其他效能問題，直接I/O是唯一的效能瓶頸，所以不用挑選優化物件
3.快取I/O是目前用到的最簡單的優化方法，而且這樣優化並不會影響應用的功能
但實際情況中，效能評估可能有多重指標，效能問題可能會多個同時發生，而且優化某一個指標的效能，可能又會導致其他指標效能的下降
評估效能優化的效果
需要對系統的效能指標進行量化，並且要分別測試出優化前，優化後的效能指標，用前後指標的變化來對比呈現效果
1.確定性能的量化指標
2.測試優化前的效能指標
3.測試優化後的效能指標
對於第一點，效能的量化指標有很多，比如CPU使用率， 應用程式的吞吐量，客戶端請求延遲等都可以評估效能指標，所以不要侷限在單一圍堵指標上，至少要從應用程式和系統資源兩個維度，分別選擇不同的指標，以Web應用為例子
應用程式維度，可以用 吞吐量和請求延遲 來評估應用程式的效能
系統資源維度，可以用 CPU使用率 來評估系統的CPU使用情況
應用程式和系統資源這兩者之間是相輔相成的
好的應用程式是效能優化的最終目的和結果，系統歐化總是為應用程式服務的，所以必須要使用程式的指標，來評估效能優化的整體效果
系統資源的使用情況是影響應用程式效能的根源，需要用系統資源的指標，來觀察和分析瓶頸的來源
效能測試的時候需要注意
1.避免效能測試工具干擾應用程式的效能
2.避免外部環境的變化影響效能指標的評估，這要求優化前，優化後的應用程式，都允許在相同配置的機器上，並且他們的外部依賴也要完全一致
多個性能問同時存在時的選擇
根據二八原則，找出20%的位置，就可以優化80%的效能，所以並不是所有效能問題都值得優化
在優化之前應該把所有效能問題分析一遍，找出最重要的，可以最大程度提升效能的問題，從它開始優化。怎麼判斷哪個效能問題最重要，有一個簡化的判斷過程
1.如果發現系統資源達到了瓶頸，比如CPU使用率是100%，那麼首先優化的一定是系統資源使用問題，
完成系統資源瓶頸的優化後，我們才要考慮其他問題
2.針對不同型別的指標，首先去優化那些由瓶頸導致的，效能指標變化幅度最大的問題，比如生產瓶頸
後用戶CPU使用率升高了10%，而系統CPU使用率卻升高了50%，這個時候就應該首先優化系統CPU使用
多種優化方法時的選擇
理論上就應該選擇提升效能最大的方法，但效能優化並非沒有成本，效能優化會帶來複雜度的提升，降低程式的可維護性，還可能在優化一個指標時，引發其他指標的異常
比如DPDK(Data Plane Development Kit)，DPDK是一種優化網路處理速度的方法，它繞開核心網路協議棧的方法，提升網路的處理能力，但他要求獨佔一個CPU一級一定數量的記憶體大頁，並且總是以100%的CPU使用率執行，所以如果CPU核數很少就不行了
選擇效能優化方法時，就要綜合考慮，不能一步登天，試圖解決所有問題
CPU優化
應用程式優化
從應用程式角度來說，降低CPU使用率的最好方法是派出所有不必要的工作，只保留最核心的邏輯，減少迴圈次數，減少遞迴，減少動態記憶體分配等，常見的優化如下
1.編譯器優化，比如gcc -O2 選項，開啟後會自動會應用程式的程式碼進行優化
2.演算法優化，使用複雜度耕地的演算法，可以加快處理速度，如O(nlongn)的排序演算法
3.非同步處理，避免程式因為等待某個資源而一直阻塞，從而提升程式的併發處理能力，比如把輪詢改為
事件通知，就可以避免輪詢消耗CPU的問題
4.多執行緒替代多程序，相對於程序的上下文切換，執行緒的上下文切換並不切換程序的地址空間，可以
降低上下文切換的成文
5.善用快取，經常訪問的資料或計算過程中的步驟，可以放到記憶體中快取起來
系統優化
從系統的角度來說優化CPU的執行，一定要充分利用CPU快取的本地性，加速快取訪問，另一方面要控制程序的CPU使用情況，減少程序間的相互影響
具體來說，有如下方法
1.CPU繫結，把程序繫結到一個或多個CPU上，可以提高CPU快取的命中率，減少跨CPU排程帶來的上下
文切換問題
2.CPU獨佔，跟CPU繫結類似，進一步將CPU分組，並通過CPU親核性機制為其分配程序，這些CPU就由
指定的程序獨佔，不允許其他程序再來使用這些CPU
3.優先順序調整，使用nice調整，正值調低優先順序，負值調高優先順序
4.位程序設定資源限制，使用cgroups來設定程序的CPU使用上線
5.NUMA(Non-Uniform Memory Access)優化，支援NUMA的處理器會被劃分為多個node，每個node都有與
自己的本地記憶體空間，NUMA優化就是讓CPU儘可能只訪問本地記憶體
6.中斷負載均衡，無論是軟中斷還是硬中斷，他們的中斷處理程式都可能會耗費大量的CPU，開啟
irqbalance服務或者配置 smp_sffinity，就可以把中斷處理過程自動負載均衡到多個CPU上
避免過早優化
高德納的名言，過早優化是萬惡之源
優化會帶來複雜性的提升，降低可維護度，另外需求不是一成不變的，針對當前情況進行的優化，很可能並不適應快速變化的新需求，在新需求出現時，這些複雜的優化，反而可能阻礙新功能的開發
所以，效能優化最好是逐步完善，動態進行，不追求一步到位，而要首先能保證蠻族當前的效能要求，當發現效能不滿足要求或者出現效能瓶頸時，再根據效能評估的結果，選擇最中意的效能問題進行優化
參考