| 導語
最近在配合某同事做一項性能壓測，發現相同數據量、相同數據庫參數、相同sysbench壓力、相同數據庫版本和sysbench版本、相同服務器硬件環境下，我和同事的壓測結果天差地別：一個小時壓測結束后，我的壓測結果中出現了高頻率周期性阻塞(tps,qps為0)，而同事的壓測結果中未出現阻塞(tps,qps從頭到尾都比較穩定)。正常情況下，在環境完全相同時，不可能會出現如此巨大的性能差異。但這次，不可能發生的事情它的確發生了。經過復測與排查，終于發現了其中的奧妙。
服務器硬件信息
數據庫主機
* CPU：72 process
* memory：128G
* 磁盤：某存儲 100G
* 網卡：intel 萬兆網卡
數據庫版本：MySQL 5.7.21
sysbench版本：1.0.9
sysbench主機
* CPU：20 process
* memory：128G
* 磁盤：本地SAS 50G
* 網卡：intel 萬兆網卡
| 復測結果數據
先來看看壓測結果數據，如下圖所示（注：此處只截取了前幾十秒的數據進行對比）：
我的壓測結果（下圖可見，明顯的周期性tps，qps為0的情況）
同事的壓測結果（下圖可見，tps,qps較為穩定且并未出現阻塞情況）
| 抓取等待事件
看到上文第1節中的結果，如果根據以往的經驗、常識來快速判斷...估計會懵圈??！當得知同事的測試結果很穩定時，我本能地想：要把等待事件信息拉出來瞧瞧??！下面是我與同事各自在復測時截取的等待事件信息（復測時間為3分鐘）（不想仔細看等待事件內容的親可直接跳至第3節）
operation操作時間統計（每秒查詢一次，查詢數十次截取時間最長的5次）
使用lua腳本隨機生成主鍵值時：假設當delete操作刪除id=1的數據行時，緊接著insert也會使用相同的id=1的主鍵值。所以高概率會出現innodb重復使用delete數據行所在的頁來存放insert數據，在sysbench高并發壓力下，大部分的insert數據存儲可能只需要在內存中已存在的頁內操作即可，無需太多IO操作
不使用lua腳本隨機生成的主鍵值，而是使用表的自增屬性生成主鍵值時：假設當delete操作刪除id=1的數據行時，緊接著insert由于是表自增屬性自己生成，也就是說幾乎不太可能id=1，所以高概率會出現innodb重新申請一個數據頁來寫入insert數據，在sysbench高并發壓力下，大部分的insert數據存儲可能需要從磁盤文件中重新申請空間，IO操作較為頻繁
至此，我和同事的壓測結果有巨大差異的原因大致確定，后續經過反復的驗證，也確認了是由于oltp.lua腳本的微小差異導致的。由于我們大多數時候都是使用的本地盤，而本地盤IO延遲低，通常情況下sysbench壓測時這點微小的差異容易被忽略。而在此案例中，由于我們測試的環境中使用了某存儲設備，相對于本地盤，IO延遲大大增加，進而造成了因為oltp.lua腳本的微小差異而導致最后壓測結果的巨大差異。
提示：如果不想改動lua腳本，又想避免主鍵沖突有辦法解決嗎？有的，從sysbench 0.5版本開始，新增了一個隱藏選項--mysql-ignore-errors，用于忽略指定的錯誤，如果要避免主鍵沖突，指定選項--mysql-ignore-errors=1062 即可。
| 作者簡介
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
