redis&twemproxy问题总结

1、redis oom问题
OOM问题引发的根本原因是系统内存不足,oom检测程序杀死score较高的程序(通常是占用内存较多的用户程序)。
redis出现oom的状况一般是在做rdb save/bgsave(slave全量复制)或者aof rewrite的时候。执行这些动作的时候需要占用大量的物理内存。
rdb bgsave fork子进程使用copy-on-write机制,在繁忙的系统中save几乎需要占用redis实例同等大小的物理内存。
如果系统的物理内存不足,那么很容易引发oom。

2、redis bgsave很慢问题
1)系统的物理内存不足,导致大量的swap操作,bgsave数据写出的速度很慢。
通过iostat工具可以发现,rdb文件每秒的写入速度甚至不到1M(两块sas盘做raid1)。
2)磁盘io压力比较大

3、redis内存碎片和内存回收问题
1)redis使用jemalloc作为内存分配器,优点是内存的分配效率高,而jemalloc的缺点就是内存碎片比较明显。
redis的mem_fragmentation_ratio = used_memory_rss / used_memory的比值较高,说明内存碎片率较高。
2)redis删除数据后,进程的并没有立即释放这部分内存,rss和virt的值仍然很大。
目前还没很好的的解决方法,只有bgsave保存数据,在重启redis。

4、redis物理机free -g显示的空闲内存很少,而实际redis占用的内存没有这么多,甚至不到used的一半。
仔细观察发现fee -g显示的结果中,cache部分的数值很大。
引起的原因:redis做bgsave,特备是复制的时候,需要大量的内存作为文件cache(read)。
因而不用担心机器内存不足,因为cache部分的内存可以有系统释放。

5、twemproxy oom现象
这个是在是用big pipeline时候出发的twemproxy引起的,pipeline数据太多,因而这个现象很难碰到。
详细见:

6、redis建立主从复制失败。
vm.overcommit_memory=0(默认值)导致fork子进程的时候内存分配请求失败。
同样,手动执行rdb bgsave也会失败。
redis admin manual推荐把这个值设置为1,我们系统基础运都是是用默认值。

7、redis cpu使用率高,而qps很低
这个现象毫无疑问是slwo query引起的,20%的慢查询可以导致其他的80%的query执行速度也很慢。
通过分析redis monitor的日志可以发现,一些简单的set、get命令也执行的很慢。
比如常见的慢查询操作有:
lrane long_list 0 -1
smembers large_set
hget large_hase

8、twemproxy日志打印一些奇怪的client error错误
redis本身支持telnet操作,而twemproxy不支持,是用telnet连接twemproxy端口会自动关闭连接。
lvs+twemprox模式下,twemproxy日志打印一些奇怪的client error错误,错误显示的ip来自lvs机器。
lvs会探测后端的redis的状态,而twemproxy不能解析这些数据包。

9、redis(2.8.8)的小bug(个人认为,未证实)
1)type命令查询kye的类型,会更显key的object idle time。
2)redis2.8复制2.6的数据,会丢失key。
3)slaveof可以是自己,出现循环复制,出现redis cpu使用率高,甚至卡死的现象。

此条目发表在redis分类目录,贴了, 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>