如何快速入門數據庫？以我個人經驗來看，數據庫功能和性能測試是一條不錯的捷徑。當然從公司層面，數據庫測試還有更多實用的功能。這方面，美團點評使用的是知名工具sysbench，主要是用來解決以下幾個問題：

• 統一測試方法，以便測試結果的可重復和可對比。
• 結合美團點評的業務特點和硬件特性，得到最優的參數配置。
• 擴展sysbench的測試能力，比如增加對JSON測試的支持。

數據庫測試雖然入門簡單，但是卻能在測試中獲得對數據庫、操作系統等的感性認識，為日后深入的研究數據庫和性能調優打下很好的基礎。如果你不滿足于僅僅使用測試工具，還想開發自己的測試工具，那么在本文的最后，還會從源碼層面解讀sysbench的高性能秘密。

測試可重復性

如果只是把測試工具運行起來，獲得一個輸出結果，那么測試就變成一個沒有任何技術含量，也沒有實際意義的事情。一個經得起推敲的測試，首先要保證測試結果的可重復性。測試結果的可重復性可能與系統的硬件、操作系統的版本、I/O調度算法、CPU調度算法、數據庫版本、數據庫的配置、測試工具、測試時間等息息相關。美團點評集團DBA有兩位數以上，如果沒有一個統一的測試平臺，那么每個DBA的測試結果將難以比較，整個團隊也無法有效協作。為了解決這個問題，我們做了幾點的強制統一：測試工具及其參數的統一、MySQL配置的統一。

為何選用sysbench

當前可采用的測試工具有sysbench、TPCC-MySQL以及公司或者個人開發的壓測工具。從功能上來講，無論采用哪種方式都可以滿足要求。美團點評采用sysbench有如下幾點考慮：

sysbench作為業界流行的測試工具，絕大多數DBA都熟悉它。

MySQL幾大主流廠商Oracle、Percona等在發布性能數據時，都采用sysbench作為測試工具。使用相同的測試工具，更便于復現測試結果。

sysbench目前已支持MySQL 8.0的測試，因此從長遠來看，該工具將會持續活躍。美團點評可以充分利用開源社區資源，降低測試工具的維護成本。

sysbench內嵌了Lua腳本。在不需要修改核心的C語言代碼的情況下，通過增添或者修改Lua腳本，即可擴展新的測試場景，大大提高了DBA人員對sysbench的掌控能力。

測試參數統一

sysbench提供了豐富的測試選項，包括測試表數量、單表數據量、測試預熱時間等。我們根據美團點評的業務特征和使用sysbench的經驗，為了避免新同學走不必要的彎路和降低測試的時間，將部分測試參數統一。另外在測試中，對MySQL核心參數做了強制統一。比如sync_binlog=1，innodb_flush_log_at_trx_commit=2，innodb_io_capacity=2000等。這里不一一贅述。

這里簡要介紹sysbecnh測試過程中涉及到的幾個重要參數：

參數名參數值解釋

tables	16	測試中使用的表分別為sbtest1… sbtest16
table_size	25,000,000	每個表的數據量
threads	16	測試線程數
time	3600	測試時間，單位為秒
warmup_time	600	預熱時間，預防冷數據對測試結果影響
rate	0	如果該值不為0，則整個測試變成生產者和消費者模式。如果該值較大，超出MySQL的處理能力，則會造成請求積壓，響應時間延長，無法反應真實的OLTP業務特性
histogram	on	輸出測試過程中系統響應時間的分布
percentile	99	輸出99線的響應時間

sysbench助力參數優化

相對于業務更新速度，數據庫的變化較為緩慢，然而影響MySQL數據庫性能的因素卻不斷呈現出來。硬件方面，比如SATA、SSD、PCIe的出現，讓數據庫的IO能力相對于傳統的機械硬盤有幾百甚至上千倍的提升；CPU多核技術的發展，讓單臺服務器擁有上百個核；單GB內存的價格越來越低，服務器配置的內存也越來越大。軟件方面，MySQL 5.7的出現，增強了多核處理能力，提高了從庫的復制速度等。

如何將新硬件和新版本的性能發揮到極致，是每個DBA都會遇到的問題。美團點評DBA團隊在前期理論調研后，會設計符合公司業務特征的場景進行嚴格的性能測試，確定最終的參數配置方案。下面以確定MySQL 5.7中多線程復制的slave_parallel_workers參數為例，來了解如何使用sysbench來優化參數配置。

為了測試從庫的復制速度，我們使用sysbench的oltp_write_only.lua（包括增、刪、改）在主庫制造負載（TPS:33,336），觀察從庫的TPS，如下圖所示。

從上圖看出，工作線程在8時，從庫的TPS達到最大。到這里為止，對于數據庫新人來說，我們可以很自信的宣稱自己學會了通過測試進行數據庫調優。但是我們不能只滿足于此，應該做更深入的探究。比如，多線程復制的原理是怎樣的？如何進一步提升從庫的TPS？建議有興趣的讀者可以繼續調研binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count參數。

sysbench可擴展性

測試場景可擴展

sysbench不僅具有豐富的功能，還具有優良的設計與實現。為了把測試場景完全交給客戶定制，所有的測試用例，均使用Lua編寫；如果需要支持新的數據庫，只要實現sysbench提供的10來個接口即可；而其他通用功能，均由sysbench提供。架構圖如下。

使用過sysbench或者其他同類型測試工具的都知道，數據庫測試分為三個階段，包括prepare階段、warmup階段、運行階段。這三個過程的實現完全使用Lua來控制，因此很容易定制。sysbench提供的默認測試用例有只讀測試、只寫測試、讀寫混合等。這些測試用例也是用Lua實現的，通過修改這些測試用例，測試人員可以很快的掌握編寫自己測試用例的技巧。

比如，日前在評估MySQL 5.7 JSON替代MongoDB的可行性。與業務人員交流過程中發現，業務中并沒有使用MongoDB的一些復雜特性，比如內嵌JS代碼、map/reduce等特性，但是其TPS較高，較為關注MySQL 5.7+JSON與MongoDB的性能比較。因此需要一款可以測試MySQL JSON性能的測試工具。在前一節的分析中，我們只需更改sysbench中幾個Lua文件即可擁有這樣的測試工具。

性能可伸縮

sysbench的高性能有兩個方面，一方面是其采用多線程結構，同時模擬多個客戶端去并發操作，這方面無需贅言；另一方面是其高效的性能收集，比如多個線程同時執行多個任務，那么性能信息的更新可能會存在熱點等狀況，本節來解密其高性能的數據收集技術。

性能數據收集

數據庫的性能往往不能用簡單的TPS或者QPS來反映，還需要知道壓測過程中系統的運行是否平穩（響應時間和QPS等）。

如果僅給出系統的最大TPS，比如10000左右，可能掩蓋了系統中的重要信息。比如上圖中，系統的TPS隨著時間，周期性的嚴重抖動，值得數據庫和開發人員關注。通過打開sysbench的周期性報表，即可獲得這樣的統計信息。

引入熱點的性能信息收集

在上圖中，可以看到TPS和QPS的數值。在多線程編程環境中，想要獲得一段時間內執行的事務數量或者SQL數量，可以通過引入一個原子變量，當執行完一個事務和SQL后，就自增一次。

如此一來，全局的事務計數器與SQL計數器就會成為多個線程競爭的熱點，影響sysbench的擴展性甚至嚴重干擾測試結果，尤其是在目前的多核處理架構，如下圖所示。

據某著名數據庫專家的話，凡是有熱點的地方，解決之道只需一個字：拆。比如大家耳熟能詳的分庫分表，將大表拆成小表，大庫拆成小庫；像在大內存的系統中，MySQL會自動創建多個buffer pool instance，就是為了避免多個線程同時去競爭一個互斥量。sysbench在解決這個問題時，也不能例外。它為每個工作線程都分配一個局部的計數器，增加計數時，只需更新線程內部的計數器；當需要獲得全局計數時，把局部計數器的值匯總即可。這種辦法獲得的計數值精確度比上一種辦法要低，但是其可以線性擴展，而且在性能數據收集這個角度其精確度已經足夠了。具體代碼在sb_counter.c中，有興趣的可以下載代碼閱讀。

SQL響應時間分布

在評估數據庫的響應時間時，我們經常會提到90線、95線和99線（分別代表90%，95%和99%的響應時間在某個值之下）。因為最大值和最小值往往受偶然因素的影響很大，而平均值往往會淹沒更多的細節。一個SQL響應時間的分布可以讓DBA更好的了解數據庫的性能，因此優秀的測試工具必須支持這個功能。

在實際的編程中，我們往往會遇到一個矛盾的問題。數據庫的響應時間往往差距很大，比如快的可能在0.01ms以下，而遇到數據庫抖動或者復雜查詢時，可能到秒級別，甚至幾十秒都有可能。如果使用算術刻度，比如單位為0.01ms，那么就需要長度為千萬級別的整型數組去表示，耗費大量內存。而且在響應時間為秒級別時，如此精確的計數也沒有必要。我們需要的是隨著響應時間越小，精度越高，響應時間越長，精度可以適當放低，而“對數刻度”正好具有這種特性。

對數刻度

sysbench正是使用該方法做時間統計。當sysbench得到一個響應時間時，通過k=floor((log(response_time) +6.908) * 55.35 + 0.5) ，獲得刻度值k。當響應時間為response_time=0.001時，k為0；response_time=0.01時，k=128;當response_time=10時，k=509；當response_time=100時，k=1023。隨著響應時間的增加，k的變化越緩慢。其中橫軸為刻度k，縱軸為響應時間，單位為ms。

當測試完成時，需要將k轉化為響應時間。算法為respone_time = exp((k/55.535)-6.908)。這樣就可以使用較少的空間，完成較大時間跨度的記錄，而且精度是動態變化的，響應時間越小，精度越高。

響應時間收集之熱點

在官方給出的MySQL性能測試數據庫中，我們可以看到在高端機型上QPS已經達到百萬，即使在一般的企業級服務器，也能達到幾十萬的級別。在前面的介紹中知道，響應時間是記錄在一個數組上的，如果響應時間比較穩定，假設有50%的響應時間是落在一個刻度上，那么該刻度對應的變量就會被每秒更新幾十萬次，形成一個更新熱點。參考下圖。

在前面性能信息收集上也遇到類似的熱點問題，當然我們也可以給每個線程各配備一個response[1024]的數組來避免熱點。sysbench采用了類似的方法，但是做了些改變。它也是采用多個response[1024]的數組，但是其數量被固定為128個。

響應時間收集之避免熱點

結論

美團點評運用sysbench進行性能測試以調整MySQL配置參數，也擴展了sysbench的功能來做JSON測試。通過對其源碼研究，我們了解了其良好的功能擴展性以及其性能擴展性。未來美團點評會在sysbench上做進一步的定制，比如將測試做成服務化，讓開發和運維人員能夠方便使用sysbench做數據庫的容量測試，也可以讓數據庫愛好者更快上手數據庫測試。

作者簡介

廣友，美團點評到店綜合事業群資深MySQL DBA，2012年畢業于中國科學技術大學，2017年加入美團點評，長期致力于MySQL及周邊工具的研究。

金龍，2014年加入新美大，主要從事相關的數據庫運維、高可用和相關的運維平臺建設。對運維高可用與架構相關感興趣的同學可以關注個人微信公眾號“自己的設計師”，定期推送運維相關原創內容。

美團點評DBA團隊招聘各類DBA人才，base北京上海均可。我們致力于為公司提供穩定、可靠、高效的在線存儲服務，打造業界領先的數據庫團隊。這里有基于Redis Cluster構建的大規模分布式緩存系統Squirrel，也有基于Tair進行大刀闊斧改進的分布式KV存儲系統Cellar，還有數千各類架構的MySQL實例，每天提供萬億級的OLTP訪問請求。真正的海量、分布式、高并發環境。歡迎各位朋友推薦或自薦至jinlong.cai#dianping.com。

【思考題】

文中從最簡單的性能測試開始，然后進一步探討性能優化，到從腳本層面進行功能擴展，最后去分析其設計和實現的優秀之處。在整個過程中，我們需要廣泛的掌握Linux下性能監測與調優工具，也需要深入分析一種數據庫或者數據庫測試工具的源碼。大家在專精一門技術的同時，往往還有多種輔助技術。聊一聊你在工作過程中最得力的輔助技術，以及如何用它來解決技術問題。

總結

以上是生活随笔為你收集整理的sysbench在美团点评中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

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