1 首先進行OS層面的檢查確認
首先要確認當前到底是哪些進程引起的負載高，以及這些進程卡在什麽地方，瓶頸是什麽。
一般情況下，服務器上最容易成為瓶頸的是磁盤I/O子系統，因為它的讀寫速度通常是最慢的;也會有其他原因：

1.某些進程/服務消耗更多CPU資源（服務響應更多請求或存在某些應用瓶頸）；
2.發生比較嚴重的swap（可用物理內存不足）；
3.發生比較嚴重的中斷（因為SSD或網絡的原因發生中斷）；
4.磁盤I/O比較慢（會導致CPU一直等待磁盤I/O請求）；
一般先看整體負載如何
可以使用w 或sar -q 來查看服務器負載數據

sar -q 1

runq-sz： 運行隊列的長度（等待運行的進程數）
plist-sz： 進程列表中進程（processes）和線程（threads）的數量
ldavg-1： 最後1分鐘的系統平均負載（System load average）
ldavg-5： 過去5分鐘的系統平均負載
ldavg-15： 過去15分鐘的系統平均負載

查看CPU使用率

sar -u 2

07:20:28 PM CPU %user %nice %system %iowait %steal %idle
07:20:30 PM all 35.09 0.00 64.91 0.00 0.00 0.00
07:20:32 PM all 27.38 0.00 52.38 20.24 0.00 0.00
07:20:35 PM all 34.33 0.00 61.19 4.48 0.00 0.00
07:20:37 PM all 36.51 0.00 63.49 0.00 0.00 0.00
07:20:39 PM all 33.33 0.00 66.67 0.00 0.00 0.00
07:20:41 PM all 33.33 0.00 61.90 4.76 0.00 0.00
07:20:43 PM all 37.93 0.00 62.07 0.00 0.00 0.00

%user ： 用戶模式下消耗的CPU時間的比例；

%nice：通過nice改變了進程調度優先級的進程，在用戶模式下消耗的CPU時間的比例；

%system：系統模式下消耗的CPU時間的比例；

%iowait：CPU等待磁盤I/O而導致空閑狀態消耗時間的比例；

%steal：利用Xen等操作系統虛擬化技術時，等待其他虛擬CPU計算占用的時間比例；

%idle：CPU沒有等待磁盤I/O等的空閑狀態消耗的時間比例；

註：

如果 %iowait 的值過高，表示硬盤存在I/O瓶頸
如果 %idle 的值高但系統響應慢時，有可能是 CPU 等待分配內存，此時應加大內存容量
如果 %idle 的值持續低於 10，則系統的 CPU 處理能力相對較低，表明系統中最需要解決的資源是 CPU。

磁盤IO分析

iotop 確認到底哪些進程消耗的磁盤I/O資源最多

由於是壓力測試，所以測試進程IO都比較高。

數據庫層可以查看日誌，對日誌中的sql進行分析。

性能瓶頸定位分析