作者簡介

藍寅，開源分布式中間件DBLE項目負(fù)責(zé)人；持續(xù)專注于數(shù)據(jù)庫方面的技術(shù), 始終在一線從事開發(fā)；對數(shù)據(jù)復(fù)制，讀寫分離，分庫分表的有深入的理解與實踐。

問題起因：

用benchmarksql_for_mysql對原生MyCat-1.6.1和DBLE-2.17.07版做性能測試對比，發(fā)現(xiàn)DBLE性能只到原生版MyCat的70%左右。

問題分析過程：

分析過程主要有以下內(nèi)容：包括現(xiàn)象，收集數(shù)據(jù)，分析猜測原因，驗證猜測的方式來進行。

開源分布式中間件DBLE：  
社區(qū)官網(wǎng)，獲取DBLE快速入門指南及最新資訊： 
https://opensource.actionsky.com  
GitHub主頁，查看官方文檔： 
https://github.com/actiontech...  
社區(qū)技術(shù)交流群，迅速獲取官方支持：  
QQ群：669663113

**1.分析瓶頸

1.1 先對兩者進行一個CPU占用的堆棧分析**

通過對CPU火焰圖的比較，發(fā)現(xiàn)DBLE用在純排序上的CPU占用在15%以上，而MyCat在排序上沒有看到明顯的CPU占用。（ 復(fù)盤時的思考：這里有明顯的可疑之處，應(yīng)當(dāng)及早觀察兩者是否公平）

1.2 首先猜測可能的原因

a.由于MyCat對以下這條用例實現(xiàn)有bug：具體方式是直接原句下發(fā)SQL到節(jié)點，收到各個節(jié)點的結(jié)果后直接做加法；而DBLE則是改寫為select distinct s_i_id 收集全部結(jié)果集，然后在中間件做去重和統(tǒng)計的工作。所以兩者在這個case上的對比是不公平的。

b.排序本身算法選擇的問題

1.3 對猜測原因的驗證

a.去除有bug的case，并未看到性能有提升，而且考慮這條用例在所有用例出現(xiàn)的概率只有4%，涉及到的數(shù)據(jù)也不多，所以應(yīng)該不是性能問題的主因。

b.去除有排序的case，看到兩者性能接近，確定是排序的問題。

2.猜測原因

2.1 猜測一：源碼實現(xiàn)原因

2.1.1 猜測描述

梳理DBLE源碼排序邏輯的實現(xiàn)細(xì)節(jié)，是多路歸并的排序，理論上是最優(yōu)選擇。

實際上具體的實現(xiàn)上有可優(yōu)化的空間，如下圖， N個數(shù)的K路排序的初始化值理論最優(yōu)復(fù)雜度是O(N),而這里變成了O（NlogK2) 。

2.1.2 驗證猜測

為了快速將排序的因素排除，將cmp函數(shù)直接返回1再次做測試。結(jié)果提升了10%的性能，所以雖然cmp是有性能問題，但導(dǎo)致性能如此大還有其他原因。（復(fù)盤：新版本已優(yōu)化此處10%的性能差異）

2.2 猜測二：回到排序SQL

查看B-SQL源碼，有3個排序SQL，其中有2個排序SQL的排序列不在select 項中，這本來應(yīng)該引發(fā)MyCat的bug的，但我們在返回集和抓包中都沒有發(fā)現(xiàn)。再仔細(xì)閱讀源碼，原來B-SQL通過hard code的方式使得壓力永遠跑不到這兩個代碼路徑上，這樣我們又排除了2個干擾因素，問題集中到剩下的那個排序上了。

將排序除去，64數(shù)據(jù)量，64并發(fā)，DBLE的性能是MyCat的96%。

證明確實和排序有關(guān)。

3.分析多并發(fā)壓力排序性能的原因

3.1 猜測排序算法在特殊場景下的適用性

3.1.1 猜測描述

由于MyCat排序采用的是timsort， 時間復(fù)雜度的可能最優(yōu)是O(n)。
而DBLE的多路歸并排序在B-SQL這個場景下時間復(fù)雜度最差情況是O（n*(k-1)).
猜測timSort排序在B-SQL多并發(fā)場景下可能會優(yōu)于多路歸并。

3.1.2 驗證猜測

用B-SQL壓測并統(tǒng)計函數(shù)調(diào)用次數(shù)。

結(jié)論：

在B-SQL場景下:

兩者平均每個排序調(diào)用的cmp函數(shù)的次數(shù)并沒有發(fā)生明顯的異化

每個排序cmp次數(shù)雖然沒有大的差異，但總的調(diào)用次數(shù)卻相差很大,DBLE大約是MyCat的5倍

4. 分析DBLE排序時cmp函數(shù)次數(shù)調(diào)用多的原因

問題集中在了為什么DBLE會有更多次的比較函數(shù)調(diào)用。

4.1 驗證壓力下發(fā)的SQL是否與cmp函數(shù)調(diào)用相符是否下發(fā)的SQL就不公平

4.1.1收集數(shù)據(jù)

用抓包的方式分別抓取B-SQL發(fā)給MyCat和DBLE的包，結(jié)果發(fā)現(xiàn) DBLE的所有SQL中排序這條SQL的發(fā)生次數(shù)是MyCat的10倍左右。

再次用yourkit查看調(diào)用次數(shù)和CPU分布驗證，發(fā)現(xiàn)調(diào)用次數(shù)確實符合抓包的結(jié)論，CPU分布也是DBLE分了大量的時間用于排序，而MyCat對排序的分配幾乎可以忽略。這也與最一開始的火焰圖結(jié)論一樣。

用wireshark分析DBLE抓包結(jié)果，發(fā)現(xiàn)某些連接執(zhí)行一段時間之后大量的重復(fù)出現(xiàn)排序+delete的query請求直到壓力結(jié)束，舉例如下圖。

4.1.2 分析原因

分析B-SQL源碼這里發(fā)現(xiàn)只有delete的數(shù)據(jù)為0才會引發(fā)死循環(huán)。

4.1.3 驗證測試

在引發(fā)死循環(huán)的原因找到之前，先修改代碼驗證測試。無論result是否是0都設(shè)置newOrderRemoved=true使得B-SQL跳出死循環(huán)。

驗證測試，DBLE性能終于符合預(yù)期，變?yōu)镸yCat的105%。

至此，B-SQL有排序引發(fā)DBLE性能下降的原因找到了，某種場景下B-SQL對DBLE執(zhí)行delete，影響行數(shù)為0，導(dǎo)致此時會有死循環(huán)，發(fā)送了大量排序請求，嚴(yán)重降低了DBLE性能，并且并發(fā)壓力越大越容易出現(xiàn)，但也有一定幾率不會觸發(fā)。

5.分析哪種場景下delete行數(shù)為0

5.1隔離級別測試

因為對隔離級別并不熟悉，花了很長時間才想到原因，在MySQL上做了一個實驗：

也就是說，在并發(fā)情況下確實有可能有死循環(huán)出現(xiàn)。

5.2 分析為什么只有在DBLE上有這個問題而在MyCat上沒有這個問題

原因是DBLE和MyCat的默認(rèn)隔離級別都是REPEATED_READ，但MyCat的實現(xiàn)有bug，除非客戶端顯式使用set語句，MyCat后端連接使用的隔離級別都是下屬結(jié)點上的默認(rèn)隔離級別；而DBLE會在獲取后端連接后同步上下文，使得session級別的隔離級別和DBLE配置相同。而后端的四個結(jié)點中除了1臺是REPEATED_READ，其他三個結(jié)點都是READ_COMMITTED。這樣同樣的并發(fā)條件，DBLE100%會觸發(fā)，而MyCat只有25%的概率觸發(fā)。

5.3 驗證測試

將DBLE上的配置添加2（默認(rèn)是3）與默認(rèn)做對比:

性能比是1:0.75.符合期望，性能原因全部找到。

6. 吐槽

最后吐槽一下B-SQL，找了官方的B-SQL4.1版和5.0版，4.1版并未對此情況做任何改進，仍有可能陷入死循環(huán)影響測試。

而5.0的對應(yīng)代碼處有這么一段注釋，不知道PGSQL是否這里真的會觸發(fā)異常，但MySQL并不會觸發(fā)異常，仍有可能陷入死循環(huán)。

7.性能原因回顧

1.cmp函數(shù)時候初始化值的問題，影響部分性能，非主要性能瓶頸，新版本已改進。
2.同時觸發(fā)了MyCat和B-SQL的兩個bug，導(dǎo)致測試的性能數(shù)據(jù)負(fù)負(fù)得正；

Mycat bug：配置的隔離級別不生效問題

B-SQL bug：RR隔離級別下，delete死循環(huán)問題

需要將MySQL結(jié)點都改為READ_COMMITED,再將配置改為2，避開上述的bug。

8.收獲

1.測試環(huán)境的搭建無論是配置參數(shù)還是各個節(jié)點的狀態(tài)都要同步，保證公平。
2.性能分析工具的使用。
3.性能測試可能一次的結(jié)果具有偶然性，需要多次驗證。
4.當(dāng)有矛盾的結(jié)論時候，可能就快接近問題的真相了，需要持續(xù)關(guān)注。

開源分布式中間件DBLE

社區(qū)官網(wǎng)： https://opensource.actionsky....

GitHub主頁： https://github.com/actiontech...

技術(shù)交流群：669663113

開源數(shù)據(jù)傳輸中間件DTLE

社區(qū)官網(wǎng)： https://opensource.actionsky....

GitHub主頁： https://github.com/actiontech...

技術(shù)交流群：852990221