背景

有一個(gè)業(yè)務(wù)需要分 1000 個(gè)庫(kù)，每一個(gè)庫(kù)中都有 80 個(gè)表，總共就是 80000 * 2 個(gè)文件。文件使用率還挺高，大概是 60000 * 2。

這個(gè)業(yè)務(wù)采用的高可用架構(gòu)是 MMM，由于集群機(jī)器在硬件檢查時(shí)發(fā)現(xiàn)有問(wèn)題，必須要換掉。于是想了一個(gè)比較簡(jiǎn)單、影響面較小的方法去解決，就是找了另外兩臺(tái)機(jī)器遷移過(guò)去。同時(shí)，要求這四臺(tái)機(jī)器屬于同一個(gè)網(wǎng)段，VIP(虛擬 IP 地址)在機(jī)器之間可以漂移，這樣業(yè)務(wù)就不需要修改 IP 地址即可遷移，相當(dāng)于兩次主從切換過(guò)程。

切換方案如圖 16.1 所示。

從圖 16.1 中可以看到，切換過(guò)程很簡(jiǎn)單，如下三步。

1. 先將原來(lái)的寫(xiě)節(jié)點(diǎn)(db1)與一個(gè)新的節(jié)點(diǎn)(db3)切換成一套集群，也就是把在 db2 上面的 VIP(讀流量)切換到 db3 上面，此時(shí) db1 與 db3 組成一套新集群。
2. 接著將 db1 和 db3 的角色互換，讓 db3 成為寫(xiě)節(jié)點(diǎn)，db1 成為讀節(jié)點(diǎn)。
3. 最后，再將 db1 讀節(jié)點(diǎn)上面的 VIP(讀流量)切換到 db4 上面，此時(shí)新的集群就是 db3 和 db4，db3 為寫(xiě)節(jié)點(diǎn)，已經(jīng)切換完成。這樣的變更是晚上做的。做好之后，觀察了一段時(shí)間，發(fā)現(xiàn)沒(méi)有什么問(wèn)題(因?yàn)閴毫π?，所以覺(jué)得事情完成了，睡吧。 第二天上班之后，業(yè)務(wù)反映說(shuō)遷移之后，數(shù)據(jù)庫(kù)比原來(lái)慢了 10 倍(10 倍啊!感覺(jué)不可思議)。詢(xún)問(wèn)了一番，說(shuō)沒(méi)有任何變更，只是做了遷移之后就成這樣了。同時(shí)經(jīng)過(guò)觀察，只有寫(xiě)庫(kù)的讀操作變慢了，而讀庫(kù)的讀是不慢的。最后，業(yè)務(wù)已經(jīng)受不了了，要求切換回去。還好，db1 還正在從 db3 復(fù)制，做了一個(gè)回退操作，把寫(xiě)掛在 db1 上面，把讀掛在 db3 上面。神奇的是，問(wèn)題解決了!好吧，那就先這樣，走出去的路不能回頭，總是要遷出去的，所以先在新舊兩臺(tái)機(jī)器上面掛著，查明原因后再切換回去(這樣少做一步)。

以上是背景。

問(wèn)題分析

環(huán)境對(duì)比

• db1 寫(xiě)入時(shí)，db1 寫(xiě)不慢，讀不慢，db3 也不慢。
• db3 是新的硬件，db1 是老的、有問(wèn)題的硬件。
• db3 切換成寫(xiě)之后，在慢查詢(xún)文件中明顯看到很多慢查詢(xún)(使用相同的語(yǔ)句查詢(xún)，原來(lái)是 50ms，現(xiàn)在是 500ms)，和監(jiān)控是一致的。
• db1 和 db3 配置文件有差別，如圖 16.2 所示(左邊是 db3 的，右邊是 db1 的)。

其他方面，環(huán)境完全相同，業(yè)務(wù)方面沒(méi)有任何更改，重現(xiàn)慢的現(xiàn)象，只是需要切換而已。

圖 16.3 是切換過(guò)程中的監(jiān)控圖，高起來(lái)的就是把流量切換到 db3 的情況，處于低谷的就是切換到 db1 的情況，效果非常明顯，慢得立竿見(jiàn)影，好神奇!

 

原因分析

• 從對(duì)比中可以得知，db1 是正常的(以前長(zhǎng)時(shí)間在這個(gè)機(jī)器上跑，沒(méi)有問(wèn)題)，而 db3 是不正常的。這個(gè)業(yè)務(wù)目前是讀多寫(xiě)少，現(xiàn)在的現(xiàn)象是讀慢。因?yàn)閷?xiě)少，沒(méi)有發(fā)現(xiàn)慢，就不考慮了。
• 接著就是硬件的區(qū)別，二者都是 PCI-e 卡，老的、壞的概率比較大，從經(jīng)驗(yàn)上來(lái)看新的會(huì)比較好，這是一個(gè)值得懷疑的點(diǎn)。但實(shí)際上，針對(duì)這個(gè)問(wèn)題，找到了新卡的技術(shù)人員進(jìn)行分析，將寫(xiě)切換到 db3 上之后觀察，發(fā)現(xiàn) IO 非常小，能看到的監(jiān)控指數(shù)都非常正常。(他們也很納悶。)
• 除此之外，唯一的區(qū)別就是二者的配置了，但從圖 16.3 中可以看到，沒(méi)有一個(gè)參數(shù)可以影響到讓數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間是原來(lái)的 10 倍。

但上面這些都只是分析，硬件測(cè)試之后，沒(méi)有發(fā)現(xiàn)問(wèn)題(也不能說(shuō)就不是硬件的問(wèn)題，一直吊在那里)。那只剩下配置了，所以接下來(lái)從這里入手吧，希望能成功!

那么，再找一個(gè)夜深人靜的夜晚……

案例解決

首先要做的事情是，把 db3 的讀流量切換到 db1，然后把配置完全換成 db1 的配置，將數(shù)據(jù)庫(kù)重啟，然后上線。此時(shí)，db1 是寫(xiě)節(jié)點(diǎn)，db3 是讀節(jié)點(diǎn)，最神奇的時(shí)刻即將到來(lái)。

切換之后，經(jīng)過(guò)觀察，竟然沒(méi)有問(wèn)題了。問(wèn)題已經(jīng)解決，那么說(shuō)明還是上面列出來(lái)的配置差別引起的問(wèn)題。

那么解決之后，下面的工作就是重復(fù)一開(kāi)始的工作，把 db1 下線，讓 db4 上線。此刻，之前的遷移工作已經(jīng)完成，線上服務(wù)沒(méi)有問(wèn)題。

但……開(kāi)發(fā)同學(xué)，能給我半個(gè)小時(shí)，讓我看看是哪個(gè)參數(shù)引起的么? 得到的回答是：“迅速點(diǎn)，就這一次，給你 20 分鐘。”

把最有可能的參數(shù)找出來(lái)，比如字符集(實(shí)際上，上面列出的每一個(gè)，我們認(rèn)為都不會(huì)有多大影響)，考慮到字符集是不可動(dòng)態(tài)修改的參數(shù)，所以先把這個(gè)改了。重啟，然后一個(gè)一個(gè)地動(dòng)態(tài)修改、業(yè)務(wù)重啟重連等，都沒(méi)有發(fā)現(xiàn)。修改的這些參數(shù)包括：sql_mode、join_buffer_size、max_heap_size、sort_buffer_size，這些都沒(méi)有影響。

結(jié)果已經(jīng)說(shuō)好的只有這一次，那就這樣吧，任務(wù)成功完成，問(wèn)題解決失敗。

然而，這個(gè)問(wèn)題“才下手頭，卻上心頭”，總有一件事放心不下，約吧。 和開(kāi)發(fā)商量了一下，我們想解決這個(gè)問(wèn)題，知道其所以然，防止在其他業(yè)務(wù)上出現(xiàn)同樣的問(wèn)題。好吧，再給你們一次機(jī)會(huì)(來(lái)之不易啊)。

那么，再找一個(gè)夜深人靜的夜晚……這次的月亮好像比上次更圓一些，是好日子的征兆么?

操作之前，還簡(jiǎn)單規(guī)劃了一下，下面是當(dāng)時(shí)的一個(gè)計(jì)劃步驟。

^* 黑體的表示已經(jīng)專(zhuān)門(mén)測(cè)試過(guò)，沒(méi)有影響

步驟如下。

考慮到先重現(xiàn)問(wèn)題，首先應(yīng)該全部使用新配置測(cè)試一次，確定問(wèn)題是否還存在。

因?yàn)橹攸c(diǎn)考慮問(wèn)題是因?yàn)?sql_mode 引起的，所以第二次只將這個(gè)參數(shù)改為老配置，這樣就可以測(cè)試出其他配置組合時(shí)有問(wèn)題，或者是沒(méi)有問(wèn)題，從而得出結(jié)論是 sqlmode 的問(wèn)題。

如果上面還沒(méi)有找到問(wèn)題原因，那么就是除了 sql_mode 之外的其他參數(shù)組合出了問(wèn)題(如果沒(méi)有，則見(jiàn)鬼了)。此時(shí)，通過(guò)二分法測(cè)試，先測(cè)試 innodb_flush_log_at_trx_commit、innodb_open_files、sort_buffer_size 三個(gè)參數(shù)。

如果發(fā)現(xiàn)上一步有問(wèn)題，則再進(jìn)行二分;如果沒(méi)有發(fā)現(xiàn)問(wèn)題，則對(duì) sync_binlog、join_buffer_size、tmp_table_size 進(jìn)行二分。

如果能走到這里，那也是醉了。

再說(shuō)吧。

按照步驟，一步步地開(kāi)始做。

首先使用有問(wèn)題的配置，測(cè)試一遍，發(fā)現(xiàn)是老樣子，還是有問(wèn)題的(真是幸運(yùn)，問(wèn)題還存在)。

把除了 sql_mode 之外的所有參數(shù)改成新的，其他都用老配置，測(cè)試發(fā)現(xiàn)沒(méi)有問(wèn)題。

做完了，也是沒(méi)有問(wèn)題。

做完了，還是沒(méi)有問(wèn)題。

我醉了。

此時(shí)當(dāng)事人已經(jīng)搞不清楚了，難道是某兩個(gè)的組合會(huì)導(dǎo)致出現(xiàn)這樣的問(wèn)題?如果是這樣的話，那情況就太多了，天已經(jīng)亮了，很累，放棄吧!

就在想放棄的時(shí)候，突然有一種新的思路。在有問(wèn)題的基礎(chǔ)上，把所有經(jīng)過(guò)測(cè)試沒(méi)有影響的可以動(dòng)態(tài)修改的參數(shù)改成與 db1 相同的參數(shù)，這樣應(yīng)該是最少量的可以影響到性能的參數(shù)組合了。此時(shí)，在 db1 與 db3 實(shí)例上分別執(zhí)行 show variables，全量導(dǎo)出變量，進(jìn)行對(duì)比，發(fā)現(xiàn)有幾個(gè)參數(shù)的區(qū)別(左邊是老的 db1，右邊是新的 db3)，如圖 16.4 所示。

 

此時(shí)，我們做了最后的掙扎，已經(jīng)只剩下這 6 個(gè)了，看上去還是不會(huì)有什么影響，有些已經(jīng)試過(guò)了，再隨便試一次吧。二分查找，從下面開(kāi)始找了三個(gè)參數(shù)，下線、重啟、上線……發(fā)現(xiàn)問(wèn)題竟然奇跡般地存在。而此時(shí)只剩下了三個(gè)參數(shù)，其中一個(gè)參數(shù)是 sync_binlog，有問(wèn)題的是 0，肯定不會(huì)影響啊。只能定位到剩下的兩個(gè)了，可以看到倒數(shù)第二個(gè)是一個(gè) performance_schema 的參數(shù)，配置文件中沒(méi)有設(shè)置，是默認(rèn)的，可以忽略。于是，把問(wèn)題定位到 open_files_limit 了。

此時(shí)，再做最后一次，只剩下 open_files_limit 的區(qū)別了。結(jié)果還是有問(wèn)題，說(shuō)明就是這個(gè)參數(shù)了。

回過(guò)頭來(lái)想了一下，其實(shí)當(dāng)初看區(qū)別的時(shí)候，這兩個(gè)參數(shù)就在配置文件中，只是看著 13 萬(wàn)和 15 萬(wàn)相差不大，就忽略了。好吧，問(wèn)題已經(jīng)解決，找到了原因，天亮了，回家吧。

已經(jīng)查到了是 open_files_limit 的原因。那么，究竟為什么在一個(gè)參數(shù)相差這么小的情況下會(huì)影響 10 倍的性能呢?查查源碼!

通過(guò) sysbench，創(chuàng)建 60000 個(gè)表，每個(gè)表 10000 行，在只讀模式下，發(fā)現(xiàn)設(shè)置為 130000 時(shí)，QPS 可以達(dá)到 20000，而設(shè)置為 150000 的時(shí)候，QPS 只有 4000 左右。問(wèn)題重現(xiàn)了，就簡(jiǎn)單多了。

此外，還有一個(gè)額外的發(fā)現(xiàn)。如果設(shè)置為 150000 之后，重啟數(shù)據(jù)庫(kù)，非常慢，大概需要 1 分鐘，而設(shè)置為 130000 之后，只需要 10 秒左右。查看了一下在很慢的過(guò)程中 mysqld 的線程情況。其中，在啟動(dòng)的過(guò)程中，有一個(gè)線程長(zhǎng)時(shí)間都基本處于同一個(gè)堆棧，使用 pstack mysqldpid 查看，如圖 16.5 所示。

 

還有一個(gè)發(fā)現(xiàn)就是，當(dāng)設(shè)置 open_files_limit 為相同的時(shí)候，performance_schema_max_file_instances 參數(shù)也相同了，并且這個(gè)參數(shù)沒(méi)有設(shè)置過(guò)。那么，通過(guò)源碼發(fā)現(xiàn)，這個(gè)參數(shù)竟然是通過(guò) open_files_limit 值來(lái)設(shè)置的。如果 open_files_limit 值設(shè)置得比較大(這樣就可以忽略掉其他影響條件，比如 max_connection 等)，performance_schema_max_file_instances 的值直接就是從 open_files_limit/0.65 得來(lái)的(源碼對(duì)應(yīng)函數(shù) apply_load_factor)。這樣就知道了，130000/0.65 正好是 200000，150000/0.65 正好是 230770，與圖 16.4 所示相符合。

另外，通過(guò)測(cè)試發(fā)現(xiàn)，如果單獨(dú)設(shè)置 performance_schema_max_file_instances 為不相同的值，而將 open_files_limit 設(shè)置為相同，性能還是不一樣。從而可以確定與 open_files_limit 參數(shù)實(shí)際上沒(méi)有什么關(guān)系，只是 performance_schema_max_file_instances 使用了默認(rèn)值，它的值就來(lái)源于 open_files_limit/0.65 了，這樣間接影響了 performance_schema_max_file_instances 值，突然有種“隔山打牛”的感覺(jué)。

還有一個(gè)發(fā)現(xiàn)，如果將 performance_schema_max_file_instances 設(shè)置為 200000、210000、220000、230000、240000、300000 等，性能都是差不多的，唯獨(dú)設(shè)置為 230770 是有問(wèn)題的。仔細(xì)研究之后發(fā)現(xiàn)，performance_schema_max_file_instances 最終影響的是 performance_schema 數(shù)據(jù)庫(kù)中的 file_instances 表，這個(gè)表中的數(shù)據(jù)是通過(guò)一個(gè) HASH 表來(lái)緩存的，而這個(gè)參數(shù)決定的是該 HASH 表的大小。

后面又做了一個(gè)非常無(wú)聊的測(cè)試，是 performance_schema_max_file_instances 值與 QPS 的對(duì)比，如圖 16.6 所示。

 

至此，一切都豁然開(kāi)朗了。結(jié)合上面非常慢的堆棧，以及將 performance_schema_max_file_instances 設(shè)置為不同值的現(xiàn)象，可以確定，這個(gè)問(wèn)題最終是 HASH 算法的問(wèn)題。當(dāng) HASH 桶大小為一個(gè)比較好看的數(shù)值時(shí)，這個(gè)算法就非常快，而如果是一個(gè)比較零碎的值時(shí)，算法就非常慢了，會(huì)導(dǎo)致響應(yīng)時(shí)間是原來(lái)的 10 倍。

總結(jié)

這個(gè)問(wèn)題，確實(shí)很詭異，萬(wàn)萬(wàn)沒(méi)有想到是相差那么小的一個(gè)變量的問(wèn)題(以至于一開(kāi)始就被忽略了)。

這個(gè)問(wèn)題，比較少見(jiàn)，只有表比較多的時(shí)候才會(huì)比較明顯(因?yàn)楸肀容^少的時(shí)候，算法相對(duì)比較穩(wěn)定)。

這個(gè)問(wèn)題，查明了，其實(shí)就是一個(gè)算法方面的 BUG。

這個(gè)問(wèn)題，簡(jiǎn)單的規(guī)避方法是單獨(dú)設(shè)置 performance_schema_max_file_instances 值為 0，或者設(shè)置 performance_schema_max_file_instances 為一個(gè)比較好看的數(shù)值，又或者設(shè)置 open_files_limit 為 0.65 的整數(shù)倍，這樣都不會(huì)有問(wèn)題。

這個(gè)問(wèn)題，雖然影響比較小，但我們對(duì)問(wèn)題的探索精神不能沒(méi)有，要了然于胸。

這個(gè)問(wèn)題，到此為止。