服務器性能優(yōu)化提升指南

什么是性能？

性能最通俗的衡量指標就是“時間”，CPU的使用率指的是CPU用于計算的時間占比，磁盤使用率指的是磁盤操作的時間占比，當CPU使用率100%時，意味著有部分請求來不及計算，響應時間增加或者超時；當磁盤使用率100%時，意味著有部分請求需要等待IO操作，響應時間也會增加或者超時。換言之，所有的操作都在理想的時間內，就不存在“性能優(yōu)化“的問題。我們在分析性能的時候，總是會首先要找到是什么引起響應時間變慢了，對應單機性能的分析，一般我們會將目光鎖定在CPU和IO上，因為對于應用程序一般分為CPU bound型和IO bound型，即計算密集型或者讀寫密集型；至于內存，其性能因素往往也會反映到CPU或者IO上，因為內存的設計初衷就是提高內核指令和應用程序的讀寫性能，當內存不足，系統(tǒng)可能進行大量的交換操作，這時候磁盤可能成為瓶頸；

而缺頁、內存分配、釋放、復制、內存地址空間映射等等問題又可能引起CPU的瓶頸；更嚴重的情況是直接影響功能，這個就不僅僅是性能的問題了。性能優(yōu)化并不是一個孤立的課題，除了響應時間的考慮，我們往往還需要綜合功能完整性、安全性等等方面的問題。

性能分析的基礎性能優(yōu)化需要厚實的基礎知識：操作系統(tǒng)——操作系統(tǒng)管理著應用程序所需要的所有資源，例如CPU和IO，當任何一個組件出現(xiàn)問題，我們的分析也是基于操作系統(tǒng)的，例如文件系統(tǒng)類型，磁盤類型，磁盤raid類型都需要操作系統(tǒng)管理和支持。系統(tǒng)編程技術——系統(tǒng)編程技術涉及到我們如何使用系統(tǒng)資源，例如對IO的操作我們可以使用buffering I/O，也可以使用Direct IO，可以采用同步的方式，也可以采用異步的方式，可以使用多進程，也可以使用多線程的方式。懂得不同編程技術的原理，有利于問題的分析。應用程序——例如數(shù)據(jù)庫組件的數(shù)據(jù)類型、引擎、索引、復制、配置參數(shù)、備份、高可用等等都可能是性能問題的元兇。

性能分析的方法論

問題分析方面，各類方法論如金字塔思維、5W2H、麥肯錫七步法等等。套用5W2H方法，可以提出性能分析的幾個問題

What-現(xiàn)象的表現(xiàn)是什么樣的

When-什么時候發(fā)生

Why-為什么會發(fā)生

Where-哪個地方發(fā)生的問題

How much-耗費了多少資源，問題解決后能減少多少資源耗用

How to do-怎么解決問題

但是這些只能給出方向，性能分析需要找到原因需要更具體的方法，怎么解決一個問題也需要更加具體的方式。Brendan Gregg在《性能之巔：洞悉系統(tǒng)、企業(yè)與云計算》第二章中講到大量的方法，比較突出的如Use方法、負載特征歸納、性能監(jiān)控、靜態(tài)性能調優(yōu)、延時分析、工具法等等。其中工具法最具體，但是工具法也有自己的限制，如磁盤的飽和度，在磁盤使用率100%的時候，磁盤的負載可能還可以繼續(xù)增加。在實際分析問題中，負載特征歸納更有指導意義，靜態(tài)跟蹤和動態(tài)跟蹤讓我們更容易更直觀發(fā)現(xiàn)問題。CPU認識

CPU：CPU本身的架構和內核調度器的架構這里不做詳細講述，具體可以參考操作系統(tǒng)類書籍。但是仍然需要清楚一些概念：

.處理器

.核

.硬件線程

.CPU內存緩存

.時鐘頻率

.每指令周期數(shù)CPI和每周期指令數(shù)IPC

.CPU指令

.使用率

.用戶時間／內核時間

.調度器

.運行隊列

.搶占

.多進程

.多線程

.字長

針對應用程序，我們通常關注的是內核CPU調度器功能和性能

線程的狀態(tài)分析主要是分析線程的時間用在什么地方，而線程狀態(tài)的分類一般分為：on-CPU：執(zhí)行中，執(zhí)行中的時間通常又分為用戶態(tài)時間user和系統(tǒng)態(tài)時間sysoff-CPU：等待下一輪上CPU，或者等待I/O、鎖、換頁等等，其狀態(tài)可以細分為可執(zhí)行、匿名換頁、睡眠、鎖、空閑等狀態(tài)如果大量時間花在CPU上，對CPU的剖析能夠迅速解釋原因；如果系統(tǒng)時間大量處于off-cpu狀態(tài)，定位問題就會費時很多。

分析方法與工具在觀察CPU性能的時候，按照負載特征歸納的方法，可以檢查如下清單：

整個系統(tǒng)范圍內的CPU負載如何，CPU使用率如何，單個CPU的使用率呢？

CPU負載的并發(fā)程度如何？是單線程嗎？有多少線程？

哪個應用程序在使用CPU，使用了多少？

哪個內核線程在使用CPU，使用了多少？

中斷的CPU用量有多少？

用戶空間和內核空間使用CPU的調用路徑是什么樣的？

遇到了什么類型的停滯周期？

要回答上面的問題，使用系統(tǒng)性能分析工具最經(jīng)濟和直接，這里列舉的工具足夠回答上面的問題：

上述問題中，調用路徑和停滯周期的分析可以使用perf工具，也可以使用DTrace等更靈活的工具。其中perf支持對各類內核時間的跟蹤計數(shù)統(tǒng)計，可以使用perf list查看。例如停滯周期分析可能十分復雜，需要對CPU和調度器架構有較系統(tǒng)的認識和了解，停滯的周期可能發(fā)生在一級、二級或者三級緩存，如緩存未命中，也可能是內存IO和資源IO上的停滯周期，perf中有諸如L1-dcahce-loads，L1-icache-loads等事件的計數(shù)統(tǒng)計。

實際案例火焰圖幫助分析CPU的調用路徑我們在壓測mysql在某機型上的非原地更新性能時，分析mysql服務器延時情況時，分析了CPU上主要的函數(shù)調用。使用perf top能夠看到調用次數(shù)的排名，但是調用關系不能展示出來?；鹧鎴D很清晰地提供了調用關系的視圖（如下兩圖中的比例不同是因為perf top加了-p參數(shù)，火焰圖分析是針對整個系統(tǒng)）。

內存：

認識內存如前所述，內存是為提高效率而生，實際分析問題的時候，內存出現(xiàn)問題可能不只是影響性能，而是影響服務或者引起其他問題。同樣對于內存有些概念需要清楚：

主存

虛擬內存

常駐內存

地址空間

OOM

頁緩存

缺頁

換頁

交換空間

交換

用戶分配器libc、glibc、libmalloc和mtmalloc

LINUX內核級SLUB分配器

分析方法與工具Brendan在書中給出了一些問題，比如內存總線的平衡性，NUMA系統(tǒng)中，內存是否被分配到合適的節(jié)點中去等等，這些問題在實際分析問題的時候，并不能作為切入點，需要持續(xù)的分析。因此筆者簡化為如下清單：

系統(tǒng)范圍內的物理內存和虛擬內存使用率

換頁、交換、oom的情況

內核和文件系統(tǒng)緩存的使用情況

進程的內存用于何處

進程為何分配內存

內核為何分配內存

哪些進程在持續(xù)地交換

進程或者內存是否存在內存泄漏？

內存的分析工具如下

除了DTrace，所有的工具只能回答信息統(tǒng)計，進程的內存使用情況等等，至于是否發(fā)生內存泄漏等，只能通過分配跟蹤。但是DTrace需要對內核函數(shù)有很深入的了解，通過D語言編寫腳本完成跟蹤。Perf也有一些諸如cache-miss、page-faults的事件用于跟蹤，但是并不直觀。

實際案例關于內存泄漏，從監(jiān)控和頂層觀察很難發(fā)現(xiàn)問題，一般都是從底層程序代碼來分析，案例中使用各種觀察工具和跟蹤工具都不能很確定原因所在，只能通過分析代碼來排查問題。最終發(fā)現(xiàn)是lua腳本語言分配內存速度快，包驅動的周期性服務的用法中，lua自動回收不能迅速釋放內存，而是集中回收，如果頻繁回收又可能帶來CPU的壓力。開發(fā)項目組最后采用的解決方式為分步回收，每次回收一部分內存，然后周期性全量回收。

IO

邏輯IO vs 物理IO通常在討論問題時，總是會分析IO的負載，IO的負載通常指的是磁盤IO，也就是物理IO，例如我們使用iostat獲取的avgqu-sz、svctm和until等指標。因為我們的讀寫最終都是來自或者去往磁盤的，關注磁盤的IO情況非常正確。但是我們在進行讀寫操作的時候，面向的對象大多數(shù)時候并不會直接面向磁盤，而是面向文件系統(tǒng)的，除非使用raw io的方式。

如下圖為通用的IO結構圖，如果你想了解更詳細，可以查看第二張圖片。我們知道LINUX通過文件系統(tǒng)將所有的硬件設備甚至網(wǎng)絡都抽象為文件來管理，例如read()調用時，實際就是就是調用了vfs_read函數(shù)，文件系統(tǒng)會確認請求的數(shù)據(jù)是否在頁緩存中，如果不在內存中，于是將請求發(fā)送到塊設備；此時內核會先獲取到數(shù)據(jù)在物理設備上的實際位置，然后將讀請求發(fā)送給塊設備的請求隊列中，IO調度器會通過一定的調度算法，將請求發(fā)送給磁盤設備驅動層，執(zhí)行真正的讀操作。在這一過程中可能發(fā)生哪些情況呢？如果應用程序執(zhí)行的是大量的順序讀會怎樣？隨機讀又會怎樣？如果是順序讀，正確的做法就是進行預讀，讓請求的數(shù)據(jù)落到內存中，提升讀效率。所以在應用程序發(fā)起一次讀，從文件系統(tǒng)到磁盤的過程中，存在讀放大的問題。

在寫操作時同樣存在類似的情況，應用程序發(fā)起對文件系統(tǒng)的IO操作，物理IO與應用程序之間，有時候會顯得無關、間接、放大或者縮小。

無關：其他的應用程序：磁盤IO來自其他的應用程序，如監(jiān)控，agent等其他用戶：如同虛擬機母機下的其他用戶其他內核任務：如重建raid，校驗等

間接：文件系統(tǒng)預讀：增加額外的IO，但是可能預讀的數(shù)據(jù)無用文件系統(tǒng)緩沖：寫緩存推遲或者合并回寫磁盤，造成磁盤瞬時IO壓力

放大：文件系統(tǒng)元數(shù)據(jù)：增大額外的IO文件系統(tǒng)記錄尺寸：向上對齊等增加了IO大小

縮?。何募到y(tǒng)緩存：直接讀取緩存，而不需要操作磁盤合并：一次性回寫磁盤文件系統(tǒng)抵消：同一地址更新多次，回寫磁盤時只保留最后一次修改壓縮：減少數(shù)據(jù)量

文件系統(tǒng)

分析與工具與文件系統(tǒng)相關的術語如下：

文件系統(tǒng)

VFS

文件系統(tǒng)緩存

頁緩存page cache

緩沖區(qū)高速緩存buffer cache

目錄緩存

inode

inode緩存

如下圖為文件系統(tǒng)緩存的結構圖，頁緩存緩存了虛擬內存的頁面，包括文件系統(tǒng)的頁面，提升了文件和目錄的性能。

Linux將緩沖區(qū)高速緩存放入到了頁緩存中，即page cache包含buffer cache。文件系統(tǒng)使用的內存臟頁由內核線程寫回磁盤，如圖中的頁面掃描器kswapd為后臺的頁面換出進程，當內存不足，超過一定時間（30s）或者有過多的臟頁時都會觸發(fā)磁盤回寫。

文件系統(tǒng)延時指的是一個文件系統(tǒng)邏輯請求從開始到結束的時間，包括在文件系統(tǒng)、內核磁盤IO子系統(tǒng)以及等待磁盤設備響應的時間。同步訪問時，應用程序會在請求時阻塞，等待文件系統(tǒng)請求結束，異步方式下，文件系統(tǒng)對其并無直接影響，但是異步訪問也分select、poll、epoll等方式，也就是所謂的異步阻塞、異步非阻塞。在異步方式下，一般是打印出用戶層發(fā)起文件系統(tǒng)邏輯IO的調用棧，得到調用了哪個函數(shù)產(chǎn)生了IO。Linux未提供查看文件系統(tǒng)延時的工具和接口，但是磁盤的指標信息卻比較豐富，但是很多情況下，文件系統(tǒng)IO和磁盤IO之間并沒有直接關系，例如應用程序寫文件系統(tǒng)，但是根本不關心數(shù)據(jù)什么時候寫到磁盤了，而后臺刷數(shù)據(jù)到磁盤時，可能造成磁盤IO負載增加，從磁盤角度，應用程序的寫入可能受到影響了，而實際上應用程序并沒有等待。

文件系統(tǒng)的分析可以試著回答下面的問題：哪個應用程序在使用文件系統(tǒng)？在對哪些文件進行操作？在進行什么樣的操作，讀寫比是多少，同步還是異步？文件系統(tǒng)的緩存有多大，目前的使用情況？有遇到什么錯誤嗎？是請求不合法，還是文件系統(tǒng)自身的問題？其實上面的問題，除了能夠看到系統(tǒng)的內存情況，頁緩存和buffer cache大小，能夠看到哪些進程在進行讀寫操作，在讀哪些文件，其他的比如應用程序對文件系統(tǒng)的讀寫比，同步還是異步，這些問題沒有工具能給出明確的信息。當然我們可以通過跟蹤應用程序的內核調用棧來發(fā)現(xiàn)問題，也可以在應用程序中輸出日志來幫助分析。

磁盤分析

與工具在理解磁盤IO之前，同樣我們需要理解一些概念，例如：

虛擬磁盤

扇區(qū)

I/O請求

磁盤命令

帶寬

吞吐

I/O延時

服務時間

等待時間

隨機IO/連續(xù)IO

同步/異步

磁盤接口

raid

對于磁盤IO，我們可以列出如下等問題來幫助我們分析性能問題：

每塊磁盤的使用率是多少？

每塊磁盤上有多長等待隊列？

平均服務時間和等待時間時多少？

是哪個應用程序或者用戶正在使用磁盤？

應用程序讀寫的方式是怎樣的？

為什么會發(fā)起磁盤IO，內核調用路徑是什么樣的？

磁盤上的讀寫比是多少？

隨機IO還是順序IO？

Linux對磁盤的性能分析工具主要如下：

磁盤上是隨機IO還是順序IO，很多時候我們并沒有很好的方式去判斷，因為塊設備回寫磁盤的時候，隨機IO可能已經(jīng)被整理為順序IO了。對于磁盤的分析同樣可以使用perf跟蹤事件或者DTrace設置探針。在分析mysql在某機型上做非全cache非原地更新時，為什么單實例無法將機器性能壓滿的時候，我們在分析的過程中跟蹤了塊設備的內核事件。我們對比了多實例非原地更新和單實例非原地更新的時候，磁盤的操作情況。如下為非原地更新時跟蹤的結果。對結果分析后看到，單實例非原地更新時，將近30%是blk_finish_plug，有70%是blk_queue_bio，而多實例時正好相反，大量的blk_finish_plug和少量的blk_queue_bio（當然，這不是為什么性能壓不滿的原因）。

海外服務器免費測試：http://running-capacitor.com/