redis性能调优总结

本文经过真实项目验证。属原创分享，不对安装、配置细节作过多描述，谷歌即可得到。主要针对一些关键的参数，比如应用错误原因，性能瓶颈等，作相关说明。

1. 什么是redis

Redis是一个nosql的高性能Key-Value内存数据库，支持网络，亦可本地持久化。3.0.0Beta版已支持集群。

详细资料可见http://www.redis.cn/

2. Redis关键参数

Ø 客户端最大连接数（maxclients）

可能的错误信息：max number of clients reached。

 

默认为0，即不限制，一般不需要更改，所以客户端连接限制，取决于操作系统参数ulimit -n（max open files），可通过修改/etc/security/limits.conf文件以永久生效。

 

以下场景在性能压测时出现，涉及三个参数：

可能的错误信息：scheduled to be closed ASAP for overcoming of output buffer limits。

有时候明明master/slave都活得好好的，突然间就说要重新进行全同步了：

1.Slave显示：# MASTER time out: no data nor PING received…

2.Master显示：# Client addr=10.175.162.123:44670 flags=S oll=104654 omem=2147487792 events=rw cmd=sync scheduled to be closed ASAP for overcoming of output buffer limits.

 

Ø 主从响应策略（repl-ping-slave-period/repl-timeout）

slave会每隔repl-ping-slave-period(默认10秒)ping一次master，如果超过repl-timeout(默认 60秒)都没有收到响应，就会认为Master挂了。如果Master明明没挂但被阻塞住了也会报这个错。可以适当调大repl-timeout。

 

Ø 客户端输出缓冲区（client-output-buffer-limit）

该参数有三种场景策略，主要是第二种slave场景。当使用主从复制时，性能压测下，数据量会急剧增长，导致从节点需要复制的数据很大，消耗时长增加。slave没挂但被阻塞住了，比如正在loading Master发过来的RDB， Master的指令不能立刻发送给slave，就会放在output buffer中(见oll是命令数量，omem是大小)，在配置文件中有如下配置：client-output-buffer-limit slave 256mb 64mb 60， 这是说负责发数据给slave的client，如果buffer超过256m或者连续60秒超过64m，就会被立刻强行关闭。所以此时应该相应调大数值，否则就会出现很悲剧的循环：Master传输一个很大的RDB给Slave，Slave努力地装载，但还没装载完，Master对client的缓存满了，再来一次。

平时可以在master执行 redis-cli client list 找那个cmd=sync，flag=S的client，注意OMem的变化。

 

Ø 日志级别和输出（loglevel、logfile）

 

生产可调整为warning级别，并重定向到某个文件。这对排除问题很有帮助。

 

3. 性能调优

Ø 内存分配限制

可能的错误信息：Cannot allocate memory

 

Redis在主从复制时，需要fork子进程来进行操作，如果你的应用堆积了很大数据在内存中，那么就需要针对这个子进程申请相应的内存空间，此时会受到操作系统的限制。通过更改系统配置文件/etc/sysctl.conf的vm.overcommit_memory=1以永久生效。该参数有0、1、2三个值。1表示允许分配所有的物理内存，而不管当前的内存状态如何。

 

Ø 客户端频繁获取连接限制

可能的错误信息：Cannot assign requested address

 

频繁地连服务器，但每次连接都在短时间内结束，导致很多的TIME_WAIT，以至于用光端口号，所以新连接没办法绑定端口。修改如下2个内核参数：

sysctl -w net.ipv4.tcp_timestamps=1，开启对于TCP时间戳的支持,若该项设置为0，则下面一项设置不起作用；

sysctl -w net.ipv4.tcp_tw_recycle=1，表示开启TCP连接中TIME-WAIT sockets的快速回收。