redis系列10--redis優化

目錄

1、fork耗時導緻高并發請求延時

2、AOF的阻塞問題

3、主從複制延遲問題

4、主從複制風暴問題

5、vm.overcommit_memory

6、swapiness

7、最大打開檔案句柄

8、tcp backlog

1、fork耗時導緻高并發請求延時

RDB和AOF的時候，其實會有生成RDB快照，AOF rewrite，耗費磁盤IO的過程，主程序fork子程序

fork的時候，子程序是需要拷貝父程序的空間記憶體頁表的，也是會耗費一定的時間的

一般來說，如果父程序記憶體有1個G的資料，那麼fork可能會耗費在20ms左右，如果是10G~30G，那麼就會耗費20 * 10，甚至20 * 30，也就是幾百毫秒的時間

info stats中的latest_fork_usec，可以看到最近一次form的時長

redis單機QPS一般在幾萬，fork可能一下子就會拖慢幾萬條操作的請求時長，從幾毫秒變成1秒

優化思路

fork耗時跟redis主程序的記憶體有關系，一般控制redis的記憶體在10GB以内，slave -> master，全量複制

2、AOF的阻塞問題

redis将資料寫入AOF緩沖區，單獨開一個線程做fsync操作，每秒一次

但是redis主線程會檢查兩次fsync的時間，如果距離上次fsync時間超過了2秒，那麼寫請求就會阻塞

everysec，最多丢失2秒的資料

一旦fsync超過2秒的延時，整個redis就被拖慢

優化思路

優化硬碟寫入速度，建議采用SSD，不要用普通的機械硬碟，SSD，大幅度提升磁盤讀寫的速度

3、主從複制延遲問題

主從複制可能會逾時嚴重，這個時候需要良好的監控和報警機制

在info replication中，可以看到master和slave複制的offset，做一個內插補點就可以看到對應的延遲量

如果延遲過多，那麼就進行報警

4、主從複制風暴問題

如果一下子讓多個slave從master去執行全量複制，一份大的rdb同時發送到多個slave，會導緻網絡帶寬被嚴重占用

如果一個master真的要挂載多個slave，那盡量用樹狀結構，不要用星型結構

5、vm.overcommit_memory

0: 檢查有沒有足夠記憶體，沒有的話申請記憶體失敗

1: 允許使用記憶體直到用完為止

2: 記憶體位址空間不能超過swap + 50%

如果是0的話，可能導緻類似fork等操作執行失敗，申請不到足夠的記憶體空間

cat /proc/sys/vm/overcommit_memory

echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

sysctl vm.overcommit_memory=1

6、swapiness

cat /proc/version，檢視linux核心版本

如果linux核心版本<3.5，那麼swapiness設定為0，這樣系統甯願swap也不會oom killer（殺掉程序）

如果linux核心版本>=3.5，那麼swapiness設定為1，這樣系統甯願swap也不會oom killer

保證redis不會被殺掉

echo 0 > /proc/sys/vm/swappiness

echo vm.swapiness=0 >> /etc/sysctl.conf

7、最大打開檔案句柄

ulimit -n 10032 10032

自己去上網搜一下，不同的作業系統，版本，設定的方式都不太一樣

8、tcp backlog

cat /proc/sys/net/core/somaxconn

echo 511 > /proc/sys/net/core/somaxconn