寒亭 阿里開發(fā)者 2023-06-21 09:02 發(fā)表于浙江

阿里妹導(dǎo)讀

【資料圖】

作者抽絲剝繭的記錄了一次訪問Redis延時高問題的排查和總結(jié)。

背景

20230308 在某地域進(jìn)行了線上壓測, 發(fā)現(xiàn)接口RT頻繁超時, 性能下降嚴(yán)重, P50 400ms+, P90 1200ms+, P99 2000ms+。

細(xì)致排查發(fā)現(xiàn)其中重要的原因是, 訪問緩存rt竟然飆到了左右 。

作為高性能愛好者, 榨干CPU的每一分價值是我們的宗旨, 是可忍孰不可忍, 怎么能光空轉(zhuǎn), 不干活呢? 那就仔細(xì)分析下問題。

為啥Redis訪問延時如此高?

我們簡化下Redis訪問流程如下:

可能性1: 服務(wù)端問題?

我們Redis使用的是 redis_amber_master_4xlarge_multithread 16C32G+480G SSD 規(guī)格, 最大QPS參考值24w, 最大連接數(shù)3w, 配置還是非常豪華的。 如下, QPS以及Load在峰值請求階段, 都仍然處于低位。

可能性2: 物理網(wǎng)絡(luò)問題?

如下, 請求遠(yuǎn)遠(yuǎn)沒有達(dá)到機(jī)器帶寬, 不是瓶頸. 另外單獨(dú)看了網(wǎng)卡重傳率等指標(biāo), 也都正常。

可能性3: 客戶端問題?

那么很大概率就是客戶端自身問題了. 我們把客戶端詳細(xì)放大如下:

根據(jù)當(dāng)時ARMS監(jiān)控結(jié)果如下, 雖然YGC次數(shù)與耗時有所上升, 但沒有發(fā)生FGC:

把內(nèi)存Dump出來, 分析JedisConnectionFactory幾個相關(guān)重要指標(biāo), 發(fā)現(xiàn)問題有如下2個:

maxBorrowWaitTimeMills過大 : 即最大等待時間過久。在等待從連接池中獲取連接, 最大等待了1200ms 。很大概率是因?yàn)閎lock在連接池獲取, 導(dǎo)致請求處理緩慢。 Redis連接創(chuàng)建銷毀次數(shù)過多: createdCount 11555次; destroyedCount: 11553次。 說明max-idle參數(shù)設(shè)置不合理(on return的時候檢查idle是否大于maxIdle, 如果大于則直接銷毀該連接)。每個對象的創(chuàng)建就是一次TCP連接的創(chuàng)建, 開銷較大。導(dǎo)致脈沖式請求過來時引發(fā)頻繁創(chuàng)建/銷毀, 也會影響整體性能。

順便說一句: maxBorrowWaitTimeMills, createdCount, destroyedCount 幾個metrics信息是JedisPool對象持久維護(hù)的全局變量信息, 只要JVM不重啟, 這個信息就會一直存在。 這也就是為啥不需要在壓測峰值時獲取內(nèi)存dump, 而是事后dump也可以。

此外, 如果細(xì)致探索JedisPool參數(shù)工作機(jī)制, 就需要了解apache的ObjectPool2的機(jī)制。剛好筆者在之前研究過ObjectPool, 后續(xù)會出單獨(dú)文章闡述&對比ObjectPool, ObjectPool2, JedisPool以及經(jīng)常踩坑的DruidPool的實(shí)現(xiàn)原理與差異。

本文就不再贅述, 敬請期待~

至此, 定位問題是JedisPool行為異常導(dǎo)致。

如何解決問題?

線上JedisPool實(shí)際參數(shù)

部分參數(shù)是由 繼承而來

======-=60000

參數(shù)行為解析

max-active: 連接池的最大數(shù)量為100, 包括 idle + active. 注意, 這里被映射為了ObjectPool的maxTotal參數(shù)上。 連接池的最大空閑數(shù)量為16, 即如果return時, idleObject>=16, 則該對象直接被銷毀。 啟動后臺線程, 每30s執(zhí)行一次, 定時心跳?；钆c檢測。 連接池最小空閑的連接數(shù)量為0. 即corePoolSize為0, 不會長期maintain一個固定的容量。

脈沖式請求引發(fā)的問題

我們把問題簡化為如下序列, 即可發(fā)現(xiàn)問題所在. 在T2~T3內(nèi), 84個對象創(chuàng)建, 84個對象銷毀. 造成了極大的損耗。

期望的行為模式

由于線上環(huán)境, Redis服務(wù)器配置較高, 為了能充分壓榨性能, 同時應(yīng)對容器場景下典型的突發(fā)峰值, 因此如下行為:

連接池的最大數(shù)量=連接池的最小數(shù)量=連接池的穩(wěn)定數(shù)量. 即不要臨時去創(chuàng)建連接, 防止等待過久。 需要定時心跳保活與檢測, 及時刪除掉超時/無效的連接。 不要因?yàn)閕dle時間過久而重建連接(只因?yàn)檫B接失效而重建)。防止無意義的大規(guī)模連接重建。

=500 // 線上穩(wěn)定保有4臺, 4*500=2000, 仍然遠(yuǎn)小于Redis規(guī)格支持的==30000 // 定時心跳?；钆c檢測=500 // 連接池的穩(wěn)定數(shù)量=true //定時心跳?；钆c檢測=-1 // 每次?；顧z測, 都需要把500個連接都檢測一遍. 如果設(shè)置為-2, 則每次檢測1/2比例的的連接.=-1 // 不要因?yàn)閕dleTime大于某個閾值從而把連接給刪除掉. 這樣可以防止無意義的大規(guī)模連接重建。

效果驗(yàn)證

終于在20230413重新迎來了一波壓測, 流量模型與上次相同。結(jié)果如下:

maxBorrowWaitTimeMills 下降比例接近 80% createdCount 也從之前的 11555次 下降到了 500次(即池子初始化的size) 業(yè)務(wù)側(cè)整體性能也大幅提升, P50與P90均下降了將近60%, P99更是夸張地下降了70%。簡直是amazing, 完結(jié)撒花!~