一、Linux 操作系統

【1】ulimit 與 TCP backlog：1)、修改 ulimit：通過 ulimit 修改 open files 參數，redis 建議把 open files 至少設置成 10032，因為 maxclients 是10000? [客戶端的數據是以文件的形式進行保存的] ，另外 redis 內部最多會使用 32 個文件描述符。

1 ulimit -n 10032 #但重啟后就無效了，也可以通過配置文件limits.conf 的形式持久修改

2 #修改了，重新登錄后就立刻生效.可以用CentOS ulimit -a 查看確認

3 [root@dev ~]#ulimit -a

4 #... 省略

5 open files (-n) 10032

2)、修改 TCP backlog：redis 默認的 tcp-backlog 為 511，可通過配置 tcp-backlog 進行調整，如果 Linux 的 tcp-backlog 小于 redis 的 tcp-backlog，日志里會出有 warning。此參數確定了 TCP 連接中已完成隊列(完成三次握手之后)的長度， 當然此值必須小于或等于 Linux 系統定義的 [/proc/sys/net/core/somaxconn] 值，而 Linux 的默認參數值是128。當系統并發量大并且客戶端速度緩慢的時候，可以將這二個參數一起參考設定

1 #建議修改為 2048 修改somaxconn

2 #該內核參數默認值一般是128，對于負載很大的服務程序來說大大的不夠。一般會將它修改為2048或者更大。

3 echo 2048 > /proc/sys/net/core/somaxconn #但是這樣系統重啟后保存不了

4

5 #持久化設置: 在 /etc/sysctl.conf 中添加如下:

6 #net.core.somaxconn = 2048

7

8 #然后在終端中執行:sysctl -p

【2】vm.overcommit_mermory：表示內核在分配內存時做檢查的方式。

1)、redis 建議將 vm.overcommit_memory 設置為1，防止極端情況下 fork 出錯。

2)、vm.overcommit_memory 取值說明：Linux 對大多數申請內存的回復均為 YES，以運行更多程序，因為申請后并不是立馬使用，該技術叫 vm.overcommit。

■? 0：內核將檢查是否有足夠的內存，如果足夠，申請通過，否則內存申請失敗把錯誤返回給應用進程。

■? 1：表示內核容許超量使用內存直到用完為止。

■? 2：內存絕不過量使用內存，既系統整個內存空間不能超過 swap+50% 的 RAM[(random access memory)即隨機存儲內存 ]值，50% 是 overcommit_ratio 的默認值，支持修改。

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

【3】swappiness 參數：1)：swappiness 參數決定操作系統使用 swap 的傾向程度，取值范圍是0~100，swappiness 的值越大，說明操作系統可能使用 swap 的概率越高，swappiness 值越低，表示操作系統更加傾向于使用物理內存。

如果系統內存不足，可能會將 Redis 對應的某些頁從內存 swap到磁盤文件上。可以通過/proc 文件夾中的 smaps文件查看是否有數據頁被 swap。如果發現大量頁被 swap，則可以用 vmstat 和 iostat 進一步追查原因

2)、建議 Linux3.5 以上設置為1，否則建議設置為0。

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

【4】Transparent Huge Pages：支持大內存分頁(2MB)分配，默認開啟，redis 建議關閉此功能。

sudo chkconfig --add disable-transparent-hugepages

【5】OOM killer：會在可用內存不足時選擇性殺掉用戶進程，OOM killer 會為每個用戶進程設置一個權重，權重越大被 kill 的可能性越大。每個進程的權重放在 [/proc/{progress_id}/oom_adj]。對于 Redis 服務器來說，可以將所有 Redis 的 oom_adj 設置為最低值或者稍小的值，降低被 OOM killer 殺掉的概率。應該設置與進程有關，無法一次性設置。

二、Redis 關鍵參數

【1】客戶端最大連接數(maxclients)：1)、現象：如果連接數不夠，或者請求返回比較慢導致連接數不足，可能會報[ max number of clients reached ]。

2)、優化：調整 maxclients，或者優化 redis 命令處理性能。要注意該參數受到操作系統最大文件句柄的限制(ulimit -n )

【2】repl-ping-slave-period/repl-timeout：1)、說明：slave 會每隔 repl-ping-slave-period(默認10秒)ping 一次 master，如果查過repl-timeout(默認 60秒)都沒有收到響應，就會認為 Master 掛掉。

2)、優化：如果 Master 明明沒掛掉但被阻塞住了也會報這個錯。可以適當調大 repl-timeout

【3】client-output-buffer-limit：1)說明：客戶端輸出緩沖區大小。

2)、當使用主從復制時，性能壓測下，數據量會急劇增長，導致從節點需要復制的數據很大，消耗時長增加。slave 沒掛但被阻塞住了，比如正在 loading Master 發過來的 RDB，Master 的指令不能立刻發送給 slave，就會放在 output-buffer 中，在配置文件中有如下配置：

client-output-buffer-limit slave 256mb 64mb 60

上述配置說明：負責發送給 slave的 client，如果 buffer 超過 256m 或者連續 60秒超過 64m，就會被立刻強行關閉。所以此時應該相應調大數值，否則就會出現很悲劇的循環：Master 傳輸一個很大的 RDB 給 slave，slave 努力地裝載，但是還沒裝載完，Master 對 client 的緩存存滿了，關閉后再來一次。

三、Redis 性能測試

Redis 官網自動 Redis 性能測試工具 Redis-benchmark，可以有效的測試 Redis 服務的性能。

?

【1】案例一：命令如下，100個并發連接，100000個請求，檢測host為127.0.0.1 端口為 6379 的 redis 服務器性能

1 ./redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000

2

3 #對集合寫入測試 結果如下

4 100000 requests completed in 2.38 seconds #100000個請求在2.38秒內完成

5 20 parallel clients #每次請求有20個并發客戶端

6 3 bytes payload #每次寫入3個字節的數據

7 keep alive: 1 #保持一個連接，一臺服務器來處理這些請求

8

9 93.06% <= 15milliseconds10 99.96% <= 31milliseconds11 99.98% <= 46milliseconds12 99.99% <= 62milliseconds13 100.00% <= 62milliseconds14 #所有請求在62毫秒內完成

15 42105.26requests per second16 #每秒處理42105.26次請求

【2】案例二：命令如下，測試指定操作命令的性能。

1 ./redis-benchmark -t set,lpush -n 100000 -q

四、查找慢查詢語句

Redis 提供了記錄耗時操作語句的功能，當語句執行(不包括命令排隊時間)超過了閾值，則被認為是慢查詢。

【1】參數設置：[ slowlog-log-slower-than ]：記錄運行耗時語句的閾值，單位是微妙(1秒=1000毫秒=1000 000微妙，默認值：10000)。當值為0時，記錄所有請求。當值<0時，不記錄任何請求。

[ slowlog-max-len ]：該參數用于設置慢查詢保存的條數。

【2】功能使用：[ slowlog get ]：用于查詢慢查詢信息。[slowlog len ]：顯示當前 redis 有多少條慢查詢

總結

以上是生活随笔為你收集整理的redis java 性能_Redis 性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。