转载:https://www.cnblogs.com/krainbow/p/4261906.html
昨日,公司php调用redis报错:read error on connection 2015-01-29 23:59:050.13330000,redis存放的是用户session。
在网上查询,大家说法都比较一致,说是php.ini文件中的一个配置项导致:
default_socket_timeout = 60
由于redis扩展也是基于php 的socket方式实现,因此该参数值同样会起作用。
解决方法是:
1、直接修改php.ini,将其设置为我们想要的值(这个不推荐)
2、在我们的脚本中通过以下方式设置,这样就比较灵活,不对其他脚本产生影响
ini_set(‘default_socket_timeout’, -1); //不超时
但是,一看,修改的两个参数,一个是php的全局参数,一个是redis的超时操作,都应该按照实际情况来修改,而且,设置超长超时时间或者不超时都是不合理的;
继续检查redis发现,/usr/local/redis_16379/src/redis-cli -p 16379 info(服务器配置的redis端口为16379,分配内存为8000M)
used_memory_human:7.49G,占用内存已经7.49G
db10:keys=53090286,键值5000多万
竟然是键值占满了内存,检查php的调用代码,发现php竟然没有设置redis的键值过期时间,修改php代码,对键值设置过期时间
设置完之后,发现之前的键值因为没有设置过期时间,程序不会自动删除,于是用脚本删除主redis上对应的session,
/usr/local/redis_16379/src/redis-cli -p 16379 -n 10 keys “PHPSESSION_wc*” | xargs /usr/local/redis_16379/src/redis-cli -p 16379 -n 10 del
将大部分过期数据删除掉,删除一定数量的数据之后,报错消失,redis连接正常。
但是,发现redis主从,在这样删除之后,从数据竟然没有同步,主的数据和从数据差距有400多万不一致,也没有再发现bgsave操作,查看从日志Trying a partial resynchronization,发现因为过滤keys占用太多资源,造成服务器负载飙升,slave断开与主机的连接,需要从积压空间中找回断开期间的数据更新记录。但是因为删除数据太多,断开的时间足够长,master 拒绝 slave 的部分同步请求,从而 slave 只能进行全同步。
至此,在slave上对数据进行全量同步,数据恢复正常,业务正常。
需要注意几点:
1.redis数据,正常情况下,设置过期时间,否则可能出现,存储键值过多,占用完了预设内存,导致新的键值无法存储,调用redis失败的;
2.超时时间必须根据实际业务来设置;
3.如果slave一直连接不上master,可能需要进行全量同步。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/112949.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...