1.問題描述：

客戶新上的一個關鍵業務系統，在做上線前的壓力測試時，應用的并發無法達到上線前的并發指標和響應時間指標要求。壓測時TPS的曲線很不穩定，如下所示：

2.分析過程：

從上述知識點可以知道：

ORACLE中LGWR進程只有一個，由于所有進程在commit前都需要通知lgwr進程幫忙把之前在log buffer中生成的修改過程記錄(改變向量)寫到磁盤中。

當大量進程要同時請lgwr進程幫忙寫時，就出現排隊的情況。

在高并發的聯機交易OLTP系統中，單進程的lgwr進程有可能成為一個大瓶頸，特別是在無法在線日志IO寫性能出現問題的情況下。

因此，我們需要檢查lgwr進程的狀態。

通過gv$session觀察RAC兩個節點lgwr進程寫日志的情況，結果如下圖所示：

可以看到：

???RAC(數據庫集群)兩個節點中，只有1個節點出現log file parallel write的等待，該等待表示lgwr進程正在對磁盤的在線日志文件進行寫操作。

???在state是waiting的情況下，節點1 log file parallel等待的seq#都是35693，但是seconds_in_wait達到了21秒。簡單來說，就是lgwr進程寫一個IO需要21秒！

這意味著，壓測時所有并發進程必須要發生等待，等lgwr進程完成這個的IO，才可以繼續通知LGWR進程幫忙刷log buffer的改變向量，因此從壓測的TPS曲線來看，就是不穩定，出現了大幅衰減。

至此，我們可以肯定，IO子系統有問題

需要重點排查IO路徑下的光纖線、SAN交換機、存儲的報錯和性能情況。、

考慮到客戶那邊管存儲的團隊/部門可能不承認數據庫的IO慢的證據，同時為了讓對方增加排查力度，遠邦讓客戶發出以下命令，查看多路徑軟件的IO情況，結果如下圖所示：

節點1上出現明顯的IO ERROR，并且在持續增加！

繼續檢查節點2，發現節點2上沒有任何IO ERROR！

這個與gv$session僅有一個進程在等log file parallel write寫完是完全吻合的。

3.原因

在鐵的證據面前，客戶的存儲團隊沒有再掙扎，而是開始認認真真逐個在排查，最終在更換了光纖線后問題得到圓滿解決。以下是更換光纖線后再次壓測的等待事件！

4.問題得到解決

壓測的TPS曲線從原來的波浪形

變成了如下的良好曲線

總結

以上是生活随笔為你收集整理的mysql ssd tps 上不去_转【案例分享】压测TPS上不去的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。