MySQL 效能：在MySQL5.7中使用InnoDB Memcached 外掛實現每秒100萬QPS

oschina發表於2013-12-02
MySql

　　在上週， Tomas 在 MySQL Percona Live Conference in London ，宣佈了MySQL 5.7的版本--在只讀的（Read-Only）測試環境，InnoDB 的 Memcached plugin的版本中，可以處理 每秒 1,000,000 次的查詢。這個文章就是證實這個說法的。

　　實際上，我至今也沒有準確說法，到底可擴充性有多麼的準確和有多少的效能限制在這裡面..我們可以在最新的MySQL 5.7 中可以得到最大的效能提升，並且，並且可以讓我們輕鬆的在“普通的”（normal）SQL 在只讀的環境中（Read-Only workload） 測試到 500K QPS 。接下來，更多的效能提升在InnoDB Memcached Plugin程式碼中變為可能，然而，一切都是那麼自然。尤其在Facebook團隊，他們突破並展現出巨大的效能點。當然，Facebook給我們提供了一個測試case，我們也用它來成功的提高了我們程式碼。最終，同樣的測試案例會在下面的測試評分結果中展示出來;-）

　　這個測試是在”獨立“（standalone）模式上測試的。（包括伺服器，客戶端都在上面執行）。所以，我們使用我們實驗室最大的HW box - 一個48核的機器。這個伺服器能夠迅速的給我們指出一個存在的，或者潛在的效能瓶頸（最有趣的是，大部分他們都是在memcached程式碼上面）。然而，QPS 依賴於記憶體和CPU。因此，這臺伺服器是隻有2Ghz的CPU 核，如果有存在其他更快的HW，你可能能得到更好的積分統計 ：-）

　　現在，比較 最好-最好 的QPS結果如下：

　　我曾經把MySQL5.6放上神壇，給它打上“有史以來最好的結果”這樣的標籤;-))——由於一部分的Memcached程式碼效能提高也會反過來提升MySQL5.6的效能，所以我們也期望在5.6的下一版本中也能執行的良好。實際上，只需要MySQL5.7，你就可以達到一個很高的水平……

　　在我在倫敦的Percona現場討論會上，我曾經展示過下面這些圖表——Memcached QPS是符合InnoDB的“dml_read/sec”的狀態:

　　這些圖表代表著在“上一版”MySQL上所做的4個Memcached負載測試：

  • #1執行在48核的機器上……——我們遇到了與MVCC相關的伺服器衝突（在最新版的MySQL5.7中已經修復了）
  • #2限制MySQL服務執行在16核的機器上，以降低這個衝突……——然後，我們遇到了事務衝突（這也在最新版的MySQL5.7中修復了）
  • #3調整Memcached plugin，在一個獨立的事務內部保持一些讀操作——神啊，救救我吧，我又遇到了一些其他的衝突……
  • #4限制MySQL服務執行在8核的機器上，看是否會降低衝突——事實表明，最大QPS有所提高（在32個使用者的情況下），但是整體效能卻更糟了……

　　相反的，在最新版的MySQL5.7中，情況確實完全不同：

MySQL 效能：在MySQL5.7中使用InnoDB Memcached 外掛實現每秒100萬QPS

　　這些圖所表示的是兩個測試：

  • #1-執行在48核的機器上（不做太多評論;-)）
  • #2-調整了一些引數，在一個獨立的內部事務中保持一些讀取的操作，結果只有在QPS的峰值上稍微好點，其他方面沒有什麼區別。

　　接下來為了更好的感受到QPS的差距，我們將這些測試結果放在一個圖表中：

MySQL 效能：在MySQL5.7中使用InnoDB Memcached 外掛實現每秒100萬QPS

　　你可以更形象的看到這兩者的不同。

  • 圖表的左半部分曲線代表的QPS水平都是在“舊版”的MySQL5.6/5.7上得到的。
  • 然後右半部分的曲線是在最新版的MySQL5.7上得到的。

　　這項工作仍在進展中，關於在這個最新的MySQL 5.7版本中我們實現的巨大進步，我會讓Sunny 和 Jimmy給你們提供其中所有深入的細節。

　　我不知道這裡的效能極限在於哪裡。可能只存在於HW（HardWare）層面。我也不知道是否有足夠龐大的HW來觀察它;-)——現在經由一個單獨的1Gbit網路連結，我們已經觀察到超過700K QPS的效能了，當這個來自於單獨網路鏈路的極限峰值到達時，主要的麻煩卻來自於客戶端處理程式，而不是伺服器——所以，看上去相比較“原始的”Memcached本身來說，Memcached @InnoDB具有更好的伸縮性;-)——那麼，當有幾個網路連結啟用（或者僅僅只是使用更快速的網路卡）的時候可能會有什麼樣的效能呢——還有許多東西需要去探索發掘的！而且RW（ReadWrite）工作負載效能也是另一項挑戰;-)

　　感謝Sunny和Jimmy！還要特殊感謝yoshinori（Facebook）！-我認為這是一個很典型的例子！

　　想要了解更多關於Memecached Plugin 的設計-你可以follow this link : https://blogs.oracle.com/MySQL/entry/nosql_memcached_api_for_mysql 。-然後，你把結果都印在心裡面，我現在讓你現在想象一下”如果是資料是直接通過“本地”（native）InnoDB API 訪問的，然後通過Memcached 層面傳輸的“，你所期待是哪種效能？

　　Rgds,
　　-Dimitri

　　原文地址：http://dimitrik.free.fr/blog/archives/11-01-2013_11-30-2013.html#2013-11-22

相關文章