1.問題描述：

客戶新上的一個(gè)關(guān)鍵業(yè)務(wù)系統(tǒng)，在做上線前的壓力測(cè)試時(shí)，應(yīng)用的并發(fā)無法達(dá)到上線前的并發(fā)指標(biāo)和響應(yīng)時(shí)間指標(biāo)要求。壓測(cè)時(shí)TPS的曲線很不穩(wěn)定，如下所示：

2.分析過程：

從上述知識(shí)點(diǎn)可以知道：

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

當(dāng)大量進(jìn)程要同時(shí)請(qǐng)lgwr進(jìn)程幫忙寫時(shí)，就出現(xiàn)排隊(duì)的情況。

在高并發(fā)的聯(lián)機(jī)交易OLTP系統(tǒng)中，單進(jìn)程的lgwr進(jìn)程有可能成為一個(gè)大瓶頸，特別是在無法在線日志IO寫性能出現(xiàn)問題的情況下。

因此，我們需要檢查lgwr進(jìn)程的狀態(tài)。

通過gv$session觀察RAC兩個(gè)節(jié)點(diǎn)lgwr進(jìn)程寫日志的情況，結(jié)果如下圖所示：

可以看到：

???RAC(數(shù)據(jù)庫(kù)集群)兩個(gè)節(jié)點(diǎn)中，只有1個(gè)節(jié)點(diǎn)出現(xiàn)log file parallel write的等待，該等待表示lgwr進(jìn)程正在對(duì)磁盤的在線日志文件進(jìn)行寫操作。

???在state是waiting的情況下，節(jié)點(diǎn)1 log file parallel等待的seq#都是35693，但是seconds_in_wait達(dá)到了21秒。簡(jiǎn)單來說，就是lgwr進(jìn)程寫一個(gè)IO需要21秒！

這意味著，壓測(cè)時(shí)所有并發(fā)進(jìn)程必須要發(fā)生等待，等lgwr進(jìn)程完成這個(gè)的IO，才可以繼續(xù)通知LGWR進(jìn)程幫忙刷log buffer的改變向量，因此從壓測(cè)的TPS曲線來看，就是不穩(wěn)定，出現(xiàn)了大幅衰減。

至此，我們可以肯定，IO子系統(tǒng)有問題

需要重點(diǎn)排查IO路徑下的光纖線、SAN交換機(jī)、存儲(chǔ)的報(bào)錯(cuò)和性能情況。、

考慮到客戶那邊管存儲(chǔ)的團(tuán)隊(duì)/部門可能不承認(rèn)數(shù)據(jù)庫(kù)的IO慢的證據(jù)，同時(shí)為了讓對(duì)方增加排查力度，遠(yuǎn)邦讓客戶發(fā)出以下命令，查看多路徑軟件的IO情況，結(jié)果如下圖所示：

節(jié)點(diǎn)1上出現(xiàn)明顯的IO ERROR，并且在持續(xù)增加！

繼續(xù)檢查節(jié)點(diǎn)2，發(fā)現(xiàn)節(jié)點(diǎn)2上沒有任何IO ERROR！

這個(gè)與gv$session僅有一個(gè)進(jìn)程在等log file parallel write寫完是完全吻合的。

3.原因

在鐵的證據(jù)面前，客戶的存儲(chǔ)團(tuán)隊(duì)沒有再掙扎，而是開始認(rèn)認(rèn)真真逐個(gè)在排查，最終在更換了光纖線后問題得到圓滿解決。以下是更換光纖線后再次壓測(cè)的等待事件！

4.問題得到解決

壓測(cè)的TPS曲線從原來的波浪形

變成了如下的良好曲線

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。