准備環境:
因為找不到可用的1000M網絡機器,使用一根直通線將兩台筆記本連起來組成1000M Ethernet網。沒錯,是直通線現在網卡都能自適應交叉線、直通線,速度不受影響,用了一段時間機器也沒出問題。
服務端:T420 i5-2520M(2.5G)/8G ubuntu 11.10
客戶端:Acer i5-2430M(2.4G)/4G mint 11
redis版本:2.6.9
測試腳本:./redis-benchmark -h xx -p xx -t set -q -r 1000 -l -d 20
長度 | 速度/sec | 帶寬(MByte/s) 發送+接收 | CPU | CPU Detail |
20Byte | 17w | 24M+12M | 98.00% | Cpu0 : 21.0%us, 40.7%sy, 0.0%ni, 4.3%id, 0.0%wa, 0.0%hi, 34.0%si, 0.0%st |
100Byte | 17w | 37M+12M | 97.00% | Cpu0 : 20.3%us, 37.9%sy, 0.0%ni, 7.0%id, 0.0%wa, 0.0%hi, 34.9%si, 0.0%st |
512Byte | 12w | 76M+9M | 87.00% | Cpu0 : 20.9%us, 33.2%sy, 0.0%ni, 25.6%id, 0.0%wa, 0.0%hi, 20.3%si, 0.0%st |
1K | 9w | 94M+8M | 81.00% | Cpu0 : 19.9%us, 30.2%sy, 0.0%ni, 34.2%id, 0.0%wa, 0.0%hi, 15.6%si, 0.0%st |
2K | 5w | 105M+6M | 77.00% | Cpu0 : 18.0%us, 32.0%sy, 0.0%ni, 34.7%id, 0.0%wa, 0.0%hi, 15.3%si, 0.0%st |
5K | 2.2w | 119M+3.2M | 77.00% | Cpu0 : 22.5%us, 32.8%sy, 0.0%ni, 32.8%id, 0.0%wa, 0.0%hi, 11.9%si, 0.0%st |
10K | 1.1w | 119M+1.7M | 70.00% | Cpu0 : 18.2%us, 29.8%sy, 0.0%ni, 42.7%id, 0.0%wa, 0.0%hi, 9.3%si, 0.0%st |
20K | 0.57w | 120M+1M | 58.00% | Cpu0 : 17.8%us, 26.4%sy, 0.0%ni, 46.2%id, 0.0%wa, 0.0%hi, 9.6%si, 0.0%st |
value 在1K以上時,1000M網卡輕松的被跑慢,而且redis-server cpu連一個核心都沒占用到,可見redis高效,redis的服務也不需要太高配置,瓶頸在網卡速度。
整理看redis的us都在20%左右,用戶層代碼資源占用比例都很小。
value 如果很小時可能看起來有些浪費,那多開幾個redis-server 看看,value :20byte:
2個redis實例時:
長度 | 速度/sec | 帶寬(MByte/s) 發送+接收 | CPU | CPU Detail |
20Byte | 10w+10w | 26M+14M | 98%+98% | Cpu0 : 18.9%us, 20.5%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.0%hi, 60.3%si, 0.0%st Cpu1 : 41.2%us, 56.5%sy, 0.0%ni, 2.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st |
3個redis實例時:
長度 | 速度/sec | 帶寬(MByte/s) 發送+接收 | CPU | CPU Detail |
20Byte | 7w*3 | 26M+14M | 67%*3 | Cpu0 : 20.6%us, 19.9%sy, 0.0%ni, 0.7%id, 0.0%wa, 0.0%hi, 58.8%si, 0.0%st Cpu1 : 37.9%us, 54.2%sy, 0.0%ni, 8.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 5.7%us, 4.7%sy, 0.0%ni, 88.0%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 5.6%us, 2.6%sy, 0.0%ni, 91.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st |
小包的時候網卡中斷處理是瓶頸,大包時網卡速度又是瓶頸,故redis單線程處理除了無線程安全考慮外,就是一個線程處理毫無壓力,多了沒用不着。
小的value可以使用pipleline方式,tcp開啟nagle算法,通過tcp合包的方式估計能夠提高處理能力。
看起來三個實例都在同一個核心是跑,CPU0 CPU1 是同一個物理核心超線程。軟中斷占用60%,軟中斷在固定CPU成為瓶頸,下次分散下軟中斷到其他cpu再測試看效果。
---------------
補充,上面是用筆記本測試結果,和生產機器還是有不小差距的,僅供參考; 我另外一篇文章有記錄生產環境服務器測試結果。