最近我們有時(shí)間回過頭來重新審視這個(gè)內(nèi)存使用問題。我們想探索為什么會出現(xiàn)regression，然后看看我們?nèi)绾尾拍芨玫貙?shí)現(xiàn)key expiration。我們的第一個(gè)想法是，在Redis中有很多的key，只采樣20是遠(yuǎn)遠(yuǎn)不夠的。我們想研究的另一件事是Redi 3.2中引入數(shù)據(jù)庫限制的影響。

縮放和處理shard的方式使得在Twitter上運(yùn)行Redis是獨(dú)一無二的。我們有包含數(shù)百萬個(gè)key的key空間。這對于Redis用戶來說并不常見。shard由key空間表示，因此Redis的每個(gè)實(shí)例都可以有多個(gè)shard。我們Redis的實(shí)例有很多key空間。Sharding與Twitter的規(guī)模相結(jié)合，創(chuàng)建了具有大量key和數(shù)據(jù)庫的密集后端。

每個(gè)循環(huán)上采樣的數(shù)字由變量

ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP

該測試有一個(gè)控件和三個(gè)測試實(shí)例，可以對更多key進(jìn)行采樣。500和200是任意的。值300是基于統(tǒng)計(jì)樣本大小的計(jì)算器的輸出，其中總key數(shù)是總體大小。在上面的圖表中，即使只看測試實(shí)例的初始數(shù)量，也可以清楚地看出它們的性能更好。這個(gè)與運(yùn)行掃描的百分比的差異表明，過期key的開銷約為25％。

雖然對更多key進(jìn)行采樣有助于我們找到更多過期key，但負(fù)延遲效應(yīng)超出了我們的承受能力。

上圖顯示了99.9％的延遲（以毫秒為單位）。這表明延遲與采樣的key的增加相關(guān)。橙色代表值500，綠色代表300，藍(lán)色代表200，控制為黃色。這些線條與上表中的顏色相匹配。

在看到延遲受到樣本大小影響后，我想知道是否可以根據(jù)有多少key過期來自動調(diào)整樣本大小。當(dāng)有更多的key過期時(shí)，延遲會受到影響，但是當(dāng)沒有更多的工作要做時(shí)，我們會掃描更少的key并更快地執(zhí)行。

這個(gè)想法基本上是可行的，我們可以看到內(nèi)存使用更低，延遲沒有受到影響，一個(gè)度量跟蹤樣本量顯示它隨著時(shí)間的推移在增加和減少。但是，我們沒有采用這種解決方案。這種解決方案引入了一些在我們的控件實(shí)例中沒有出現(xiàn)的延遲峰值。代碼也有點(diǎn)復(fù)雜，難以解釋，也不直觀。我們還必須針對每個(gè)不理想的群集進(jìn)行調(diào)整，因?yàn)槲覀兿Ｍ苊庠黾硬僮鲝?fù)雜性。

我們還想調(diào)查Redis版本之間的變化。Redis新版本引入了一個(gè)名為CRON_DBS_PER_CALL的變量。這個(gè)變量設(shè)置了每次運(yùn)行此cron時(shí)要檢查的最大數(shù)據(jù)庫數(shù)量。為了測試這種變量的影響，我們簡單地注釋掉了這些行。

//if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;

這會比較每次運(yùn)行時(shí)具有限制的，和沒有限制的檢查所有數(shù)據(jù)庫兩個(gè)方法之間的效果。我們的基準(zhǔn)測試結(jié)果十分令人興奮。但是，我們的測試實(shí)例只有一個(gè)數(shù)據(jù)庫，從邏輯上講，這行代碼在修改版本和未修改版本之間沒有什么區(qū)別。變量始終都會被設(shè)置。

99.9%的以微秒為單位。未修改的Redis在上面，修改的Redis在下面。

我們開始研究為什么注釋掉這一行會產(chǎn)生如此巨大的差異。由于這是一個(gè)if語句，我們首先懷疑的是分支預(yù)測。我們利用

gcc’s__builtin_expect

接下來，我們查看生成的程序集，以了解究竟發(fā)生了什么。

我們將if語句編譯成三個(gè)重要指令mov、cmp和jg。Mov將加載一些內(nèi)存到寄存器中，cmp將比較兩個(gè)寄存器并根據(jù)結(jié)果設(shè)置另一個(gè)寄存器，jg將根據(jù)另一個(gè)寄存器的值執(zhí)行條件跳轉(zhuǎn)。跳轉(zhuǎn)到的代碼將是if塊或else塊中的代碼。我取出if語句并將編譯后的程序集放入Redis中。然后我通過注釋不同的行來測試每條指令的效果。我測試了mov指令，看看是否存在加載內(nèi)存或cpu緩存方面的性能問題，但沒有發(fā)現(xiàn)區(qū)別。我測試了cmp指令也沒有發(fā)現(xiàn)區(qū)別。當(dāng)我使用包含的jg指令運(yùn)行測試時(shí)，延遲會回升到未修改的級別。在找到這個(gè)之后，我測試了它是否只是一個(gè)跳轉(zhuǎn)，或者是一個(gè)特定的jg指令。我添加了非條件跳轉(zhuǎn)指令jmp，跳轉(zhuǎn)然后跳回到代碼運(yùn)行，期間沒有出現(xiàn)性能損失。

我們花了一些時(shí)間查看不同的性能指標(biāo)，并嘗試了cpu手冊中列出的一些自定義指標(biāo)。關(guān)于為什么一條指令會導(dǎo)致這樣的性能問題，我們沒有任何結(jié)論。當(dāng)執(zhí)行跳轉(zhuǎn)時(shí)，我們有一些與指令緩存緩沖區(qū)和cpu行為相關(guān)的想法，但是時(shí)間不夠了，可能的話，我們會在將來再回到這一點(diǎn)。

既然我們已經(jīng)很好地理解了問題的原因，那么我們需要選擇一個(gè)解決這個(gè)問題的方法。我們的決定是進(jìn)行簡單的修改，以便能夠在啟動選項(xiàng)中配置穩(wěn)定的樣本量。這樣，我們就能夠在延遲和內(nèi)存使用之間找到一個(gè)很好的平衡點(diǎn)。即使刪除if語句引起了如此大幅度的改進(jìn)，如果我們不能解釋清楚其原因，我們也很難做出改變。