1.fork耗時致使高併發請求延時linux
RDB和AOF的時候,AOF rewrite,耗費磁盤IO的過程,主進程fork子進程fork的時候,子進程是須要拷貝父進程的空間內存頁表的,也是會耗費必定的時間的。redis
通常來講,若是父進程內存有1個G的數據,那麼fork可能會消耗在20ms左右,若是是10G-30G,那就會消耗幾百毫秒的時間。info stats中的latest_fork_usec,能夠看到最近一次form的時長。api
redis單機QPS通常在幾萬,fork可能一會兒就會拖慢幾萬條操做的請求時長,從幾毫秒變成1秒。網絡
優化思路併發
fork耗時跟redis主進程的最大內存有關係,通常控制redis的內存在10GB之內。tcp
2.AOF的阻塞問題高併發
redis將數據寫入AOF緩衝器,單獨開一個線程作fsync操做,每秒一次。優化
可是redis主線程會檢查兩次fsync的時間,若是距離上次fsync時間超過了2秒,那麼寫請求就會阻塞everysec,最多丟失2秒的數據。線程
一旦fsync超過2秒的延時,整個redis就被拖慢。orm
優化思路,優化硬盤寫入速度,建議採用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 1 > /proc/sys/vm/swapiness
echo vm.swapiness=1 >> /etc/sysctl.conf
7.最大打開文件句柄
ulimit -Sn 10032
8.tcp baklog
cat /proc/sys/net/core/somaxconn
echo 511 > /proc/sys/net/core/somaxconn
9.redis是單線程的,當數據量大的時候,不能用keys命令,不然會形成宕機,可用scan命令代替。