nosql----redis性能優化

1.fork耗時致使高併發請求延時

RDB和AOF的時候，AOF rewrite，耗費磁盤IO的過程，主進程fork子進程fork的時候，子進程是須要拷貝父進程的空間內存頁表的，也是會耗費必定的時間的。

通常來講，若是父進程內存有1個G的數據，那麼fork可能會消耗在20ms左右，若是是10G-30G，那就會消耗幾百毫秒的時間。info stats中的latest_fork_usec,能夠看到最近一次form的時長。

redis單機QPS通常在幾萬，fork可能一會兒就會拖慢幾萬條操做的請求時長，從幾毫秒變成1秒。

優化思路

fork耗時跟redis主進程的最大內存有關係，通常控制redis的內存在10GB之內。

 

2.AOF的阻塞問題

redis將數據寫入AOF緩衝器，單獨開一個線程作fsync操做，每秒一次。

可是redis主線程會檢查兩次fsync的時間，若是距離上次fsync時間超過了2秒，那麼寫請求就會阻塞everysec，最多丟失2秒的數據。

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

優化思路，優化硬盤寫入速度，建議採用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命令代替。