MySQL集群優(yōu)化的0.4毫秒邏輯分析

作者：楊建榮 2021-04-27 06:20:25

最近做了一個(gè)集群服務(wù)的在線切換，將原來(lái)的主從環(huán)境做了切換，當(dāng)然后端的處理工作是比較復(fù)雜的，涉及到主從服務(wù)器的在線遷移和硬件變更。

總體來(lái)說(shuō)，切換后的讀延遲比原本降低了0.4毫秒左右，對(duì)于一個(gè)延遲季度敏感的業(yè)務(wù)來(lái)說(shuō)，0.4毫秒是一個(gè)很高的比例，按照既定的比例規(guī)則，差不多是優(yōu)化了25-30%的比例。

那么這省下來(lái)的0.4毫秒到底優(yōu)化在哪個(gè)環(huán)節(jié)了呢?我們做了一些討論和分析，不僅暗暗感嘆，幸虧是優(yōu)化了，如果延遲變大30%，要快速分析還是壓力很大的。

這個(gè)問(wèn)題分析的難點(diǎn)在于存在一系列的動(dòng)態(tài)變量，導(dǎo)致服務(wù)切換前后的對(duì)比缺少了一些基準(zhǔn)和衡量標(biāo)準(zhǔn)。

我們簡(jiǎn)單提煉了下，在服務(wù)切換前的優(yōu)化工作有：

1)新從庫(kù)采用了全新的硬件配置，CPU型號(hào)更高，性能提升可達(dá)30%

2)主從庫(kù)采用的SATA-SSD的存儲(chǔ)使用了不同品牌

3)主從切換前，在從庫(kù)中對(duì)數(shù)據(jù)表進(jìn)行了全面的碎片清理

4)原本服務(wù)器的系統(tǒng)盤(pán)是使用SAS的，在新從庫(kù)中統(tǒng)一按照SATA-SSD類配置

5)中間件服務(wù)器有近2年沒(méi)有重啟過(guò)，這次維護(hù)做了重啟維護(hù)

此外，還有一些不確定的因素，比如業(yè)務(wù)量的差異等，按照100%對(duì)等的標(biāo)準(zhǔn)是不大可能完全對(duì)等去分析的，所以我們?cè)囍ㄟ^(guò)如下的邏輯進(jìn)行分析。

初步來(lái)看，我們覺(jué)得對(duì)于數(shù)據(jù)表做了碎片清理，這個(gè)改進(jìn)的效果會(huì)比較高，因?yàn)樗槠试谇袚Q前統(tǒng)計(jì)是近20%，清理后空間釋放了近20%，本來(lái)認(rèn)為這樣的一套指標(biāo)體系是比較演進(jìn)的，但是在對(duì)比了近幾天的業(yè)務(wù)延遲情況之后，有一個(gè)業(yè)務(wù)的數(shù)據(jù)是說(shuō)不通的。

我們假設(shè)是業(yè)務(wù)2，業(yè)務(wù)2的數(shù)據(jù)表示日表，也就意味著這張表沒(méi)有所謂的碎片，因?yàn)槊刻於紩?huì)有一張新的數(shù)據(jù)表寫(xiě)入數(shù)據(jù)。所以業(yè)務(wù)2的延遲應(yīng)該沒(méi)有變化或者有細(xì)小的差異才說(shuō)得通，但是在這里可以很清楚的看到，延遲是有近30%的提升，這就說(shuō)不通了，所以單純的碎片清理帶來(lái)的收益確實(shí)沒(méi)有期望那么高。

我們分析下系統(tǒng)負(fù)載的情況，隨機(jī)選擇了一個(gè)分片節(jié)點(diǎn)，查看了切換前和切換后的負(fù)載數(shù)據(jù)。

切換前

切換后

總體來(lái)說(shuō)，負(fù)載的平均值是提高了0.03，這個(gè)比例是很低的一個(gè)比例，姑且認(rèn)為是可以忽略的。

再來(lái)看看CPU的使用率，因?yàn)樾碌姆?wù)器CPU性能提升近30%，所以對(duì)負(fù)載情況進(jìn)行了整體的比對(duì)，可以發(fā)現(xiàn)這個(gè)業(yè)務(wù)不是強(qiáng)計(jì)算相關(guān)的，所以CPU配置再好，在這里帶來(lái)的收益確實(shí)沒(méi)有期望那么明顯。

切換后