背景

redis-K,V數(shù)據(jù)庫，因其高性能的操作性和支持豐富的數(shù)據(jù)結(jié)構(gòu)，目前大量被用于銜接應用層和關(guān)系數(shù)據(jù)庫中間的緩存層。

隨著使用的場景越來越多，和數(shù)據(jù)量快速的遞增，在生產(chǎn)環(huán)境中經(jīng)常會遇到相關(guān)的性能瓶頸問題。

這時候就需要借助一些外部的手段來分析瓶頸根源在哪，對癥下藥提升性能。

常見性能問題及問題分析過程

1、生產(chǎn)系統(tǒng)剛開始運行階段，系統(tǒng)穩(wěn)定。但是運行一段時間后，發(fā)現(xiàn)部分時間段系統(tǒng)接口響應變慢。查看客戶端日志經(jīng)常會出現(xiàn)這樣的錯誤：

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out。

2、生產(chǎn)環(huán)境長時間的運行后，經(jīng)常會有接口返回數(shù)據(jù)失敗的情況，或者是從監(jiān)控上發(fā)現(xiàn)數(shù)據(jù)庫壓力某一時間暴增。查看客戶端日志發(fā)現(xiàn)這樣的錯誤：

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

3、突然間服務不能訪問，返回錯誤：

redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.

當然在實際生產(chǎn)情況中，還有各種各樣的異常情況，但是在客戶端普遍表現(xiàn)為上面幾種場景，下面我們來一步步分析上面的問題。

問題一

首先從客戶端反饋的日志，懷疑是服務器和客戶端間的網(wǎng)絡問題。為排除這個問題，我們編寫腳本，在客戶端定時ping服務端（redis服務），持續(xù)運行一段后，發(fā)現(xiàn)未有丟包的情況，排除網(wǎng)絡問題。

查看redis服務端日志，未發(fā)現(xiàn)有異常情況。查看redis服務器資源監(jiān)控，發(fā)現(xiàn)每幾分鐘左右，IO會有一波峰值，但是CPU和帶寬壓力都在正常范圍。

這里介紹下我們的redis部署模式：一主一從通過redis自帶的sentinal做HA，主從均有開啟持久化。初步懷疑間隔性IO操作占用資源導致redis讀寫變慢(在此，拋出一個問題：在服務器資源CPU和帶寬均未達到瓶頸的情況下，持續(xù)的IO高峰操作是否會影響物理內(nèi)存的讀寫）。接下來采取的措施是：關(guān)閉主庫的持久化，用從庫來做持久化，但是這種模式下存在一個問題，如果主發(fā)生故障，sentinal做主從切換后問題同樣存在，大家有更好的建議可以指點下。

運行一段時候，發(fā)現(xiàn)問題有所改善，但是依然還是會有time out的情況，只有繼續(xù)排查問題。由于redis操作采用單線程，考慮會不會有某些慢查詢導致time out。執(zhí)行slowlog查看慢查詢語句，發(fā)現(xiàn)有大量的keys命令操作，keys命令在大量并發(fā)情況下性能非常差，結(jié)合官方給出的warning

正式環(huán)境中，盡量避免使用keys，接下來找出使用keys的代碼做優(yōu)化，至此，time out問題解決。

問題二

從錯誤日志看，是提示無法獲取連接。有兩種情況：

1、客戶端的連接池滿了，無法創(chuàng)建新的連接

檢查客戶端連接最大限制maxActive是否足夠

2、redis服務端連接溢出，無法分配新的連接

檢查服務端tcp連接：netstat -nat|grep -i "6379"|wc -l

檢查服務端連接是否達到最大值：查看服務端支持的最大連接：CONFIG GET maxclients，查看當前服務端建立的   連接：connected_clients

通過上述檢查后，發(fā)現(xiàn)redis服務端connected_clients連接數(shù)持續(xù)過高，經(jīng)常在最大值徘徊。但是結(jié)合客戶端配置的最大連接配置maxActive，計算出所有客戶端連接占滿的情況下最大的連接數(shù)也達不到connected_clients的連接數(shù)。

執(zhí)行client list命令，發(fā)現(xiàn)大量的client的idle時間特別長：

正常的client連接，在持續(xù)使用的情況下，是不可能空閑這么長時間，連接長時間空閑，客戶端也會關(guān)閉連接。

查看redis服務端下面兩項配置：

• timeout：client連接空閑多久會被關(guān)閉（這個配置容易被誤導為：連接超時和操作執(zhí)行超時）
• tcp-keepalive：redis服務端主動向空閑的客戶端發(fā)起ack請求，以判斷連接是否有效

檢查上述配置發(fā)現(xiàn) timeout和tcp-keepalive均未啟用（均為0），這種情況下，redis服務端沒有有效的機制來確保服務端已經(jīng)建立的連接是否已經(jīng)失效。當服務器和客戶端網(wǎng)絡出現(xiàn)閃斷，導致tcp連接中斷，這種情況下的client將會一直被redis服務端所持有，就會出現(xiàn)上面我們看到的idle時間特長的client連接。

接下來設(shè)置timeout和tcp-keepalive來清理失效的連接。

上面問題中提到的數(shù)據(jù)庫某一時間壓力暴增，是由于在緩存模式下，redis請求失敗，請求的壓力瞬間集中到數(shù)據(jù)庫。

問題三

從錯誤提示，可以看出是向磁盤保存數(shù)據(jù)失敗。引起這個問題的原因一般是內(nèi)存不足，但是生產(chǎn)環(huán)境我們一般都會為系統(tǒng)分配足夠的內(nèi)存運行，而且查看內(nèi)存情況也顯示還有可用內(nèi)存。

查看redis日志，發(fā)現(xiàn)有這個錯誤：Can’t save in background: fork: Cannot allocate memory

redis在保存內(nèi)存的數(shù)據(jù)到磁盤時，為了防止主進程假死，會Fork一個子進程來完成這個保存操作。但是這個Fork的子進程會需要分配和主進程相同的內(nèi)存，這時候就相當于需要的內(nèi)存double了，如果這時候可用內(nèi)存不足以分配需要的內(nèi)存，將會導致Fock子進程失敗而無法保存數(shù)據(jù)到磁盤。

修改linux內(nèi)核參數(shù)：vm.overcommit_memory=1。至此，問題解決。

overcommit_memory有三種取值：0， 1， 2

• 0：:檢查是否有足夠的可用內(nèi)存供進程使用；有則允許申請，否則，內(nèi)存申請失敗，并把錯誤返回給應用進程；
• 1：表示內(nèi)核允許分配所有的物理內(nèi)存，而不管當前的內(nèi)存狀態(tài)如何；
• 2：表示內(nèi)核允許分配超過所有物理內(nèi)存和交換空間總和的內(nèi)存。

優(yōu)化措施總結(jié)

1、結(jié)合實際使用場景，考慮是否需要用到redis的持久化，如果單純用來做應用層的緩存（在緩存未命中的情況下訪問數(shù)據(jù)庫），可以關(guān)閉持久化。

2、緩存模式下，盡量為每塊緩存設(shè)置時效性，避免冷數(shù)據(jù)長時間占用資源。

3、生產(chǎn)環(huán)境中盡量避免使用keys操作，由于redis是單線程模式，大量的keys操作會阻塞其他的命令執(zhí)行。

4、設(shè)置合理的內(nèi)存回收策略，保證內(nèi)存可用性的同時能適當?shù)奶峁┚彺娴拿新省?/p>

5、提前計算出系統(tǒng)可能會用的內(nèi)存大小，合理的分配內(nèi)存。需要注意在開啟持久化模式下，需要預留更多的內(nèi)存提供給Fock的子進程做數(shù)據(jù)磁盤flush操作。

深入探討研究

如果redis服務端未設(shè)置timeout，客戶端會如何處理長時間未使用的連接？

這個問題可以從分析redis的sdk源碼查找答案，不過這個過程會比較枯燥。

接下來我們直接通過抓取客戶端和服務端的tcp數(shù)據(jù)包來獲取答案：

這里我用wireshark來抓取中間的tcp數(shù)據(jù)包，下面是抓取了一個完整的redis連接（從發(fā)起到結(jié)束）的tcp數(shù)據(jù)包

從上面可以看到，從tcp3次握手建立連接，到最后客戶端發(fā)送reset包給服務端終止了這個連接。

追蹤整個tcp的數(shù)據(jù)流：

*2$4AUTH$8password+OK*1$4PING+PONG*1$4PING+PONG*1$4QUIT+OK

從tcp數(shù)據(jù)流可以看出，整個tcp連接中間經(jīng)歷的操作：

1、客戶端發(fā)送密碼建立連接，服務端響應OK

2、客戶端發(fā)送PING命令校驗連接，服務端響應PONG表示成功

3、客戶端再次發(fā)送PING命令校驗連接，服務端響應PONG表示成功

4、客戶端發(fā)送QUIT命令退出連接，服務端響應OK表示退出成功

當服務端響應QUIT命令OK后，客戶端發(fā)送RESET的tcp包終止整個tcp連接。中間客戶端發(fā)起了兩次PING命令校驗連接和一次QUIT命令來退出連接，每次間隔30s，加起來整個連接存活了90s。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論