詳解GaussDB for MySQL性能優化

Posted on by

背景

我們先來看看MySQL 8.0的事務提交的大致流程

以上流程，是MySQL8.0對WAL原則的一種實現，這個流程意味著，任何一個事務的提交，一定要完成write buffer和flush to disk流程。

然而那麼這個流程中，有一個問題：每個服務器的CPU是有限的，服務器能處理的Thread也是有上限的，那麼當我們的業務的並發數量，遠遠大於我們服務器能並行處理的數量時，那麼後來的事務，隻能等待前面的事務提交後才能被處理。在這之前，他們什麼也做不瞭。因此，在大並發場景下，如何進一步提升線程的使用率，是大並發事物寫入的一個關鍵。

靈感來源於生活

一個優化，並不是憑空想象出來的，有時候，往往來源於現實生活。下面，我們先來看看我們身邊，和事務提交流程非常類似的一個例子：快遞。

現在的快遞配送，一般一個快遞員會負責一片區域，快遞剛開始興起時，數量不多，那麼一個快遞員基本上可以在規定時間內完成配送。

但是，隨著快遞數量越來越多，一個快遞員要在一個小區配送很長的時間，才能到下一個小區，常常導致瞭快遞員無法準時的配送。在這個問題的催動下，隨後，一個新的行業開始出現 – 快遞驛站。

快遞的優化原理

接下來，讓我們來看下，快遞驛站究竟解決瞭什麼問題。

快遞的配送過程中，最耗時的，不是裝貨，不是卸貨，而是電話和等待。配送一個小區的時間，取決於這個最後一個來取快遞的人的時間，在最後一個人取完快遞錢，快遞員除瞭打電話，做不瞭其他任何事情（也沒有辦法通知下一個小區的人，因為最後一個人來取得時間是無法確定的）。那麼這個等待的時間，對於快遞員來說，就是一種浪費。

快遞驛站可以很大程度解決這個問題，快遞員到瞭以後，隻需要將快遞卸貨，即可前往下一個小區，剩下的事情，就可以由驛站的人員來完成，大大提升瞭快遞員的配送效率。

分析

回過頭來，我們看看數據庫，如果把Transaction線程看做快遞員，存儲上的文件看做取快遞的人，那麼我們會發現兩者有非常大的相似性。那麼我們可以像快遞配送優化那樣去優化事務的處理流程嗎？答案是可以的。

根據快遞驛站的優化原理，我們知道，快遞驛站幫快遞員免去瞭等待客戶取貨的時間，那麼事務處理過程中，有沒有等待的過程呢？答案是有的，存儲的IO就是一個較長的等待。數據庫使用經驗豐富的開發人員來都知道，等待redo日志寫入存儲的磁盤IO性能，很大程度上決定瞭數據庫的寫入性能。對於現代數據庫來說，尤其對於GaussDB(for MySQL)這樣計算於存儲分離的數據庫，存儲的IO耗時，在事務處理的總耗時中，占據瞭不小的比例，雖然有log buffer的合並寫入，提升並發情況下的整體吞吐，但是如果在等待IO的這段時間中，這些線程能夠去做別的事情（例如處理等待中的其他事務）。那麼將會有進一步的性能提升。

GaussDB(for MySQL)的優化

既然找到瞭等待的點，那麼我們就可以像快遞配送的優化方法，為數據庫，也創造一個“快遞驛站”，讓“快遞驛站”來做等待的事情，而事務線程就可以去處理其他等待中的事務，讓CPU不會“閑下來”。

如圖5所示，GaussDB(for MySQL)當redo日志的flush to disk動作完成後，即可進行事務提交，但是此時並不應答客戶端，而是直接處理下一個事務。同時使用少量”post comit worker線程”，來批量等待日志寫入完成（等待的過程其實並不占用CPU），並應答客戶端，這就可以讓“等待”和“下一個事務的處理”並行化，讓CPU“閑不下來”。

實際測試

根據實際測試，在標準的sysbench寫入模型下，沒有使用Post Commit時，極限性能是35萬QPS左右，而使用Post commit後，可以到大42萬以上的QPS，提升瞭20%的寫入性能。

以上就是詳解GaussDB for MySQL性能優化的詳細內容，更多關於GaussDB for MySQL性能優化的資料請關註WalkonNet其它相關文章！

推薦閱讀：