美文网首页
redis部分问题优化方法(缓冲区和响应策略)

redis部分问题优化方法(缓冲区和响应策略)

作者: 孤独而灿烂的郑金叹 | 来源:发表于2018-06-11 23:18 被阅读0次

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级别,并重定向到某个文件。这对排除问题很有帮助。


性能调优

Ø 内存分配限制

可能的错误信息:Cannot allocate memory
Redis在主从复制时,需要fork子进程来进行操作,如果你的应用堆积了很大数据在内存中,那么就需要针对这个子进程申请相应的内存空间,此时会受到操作系统的限制。通过更改系统配置文件/etc/sysctl.confvm.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的快速回收

相关文章

网友评论

      本文标题:redis部分问题优化方法(缓冲区和响应策略)

      本文链接:https://www.haomeiwen.com/subject/jdpkeftx.html