twemproxy oom分析

twemproxy集群目前上线有好几个月了,十几个集群运行都比较稳定,唯一的一次故障是不合理的pipeline触发了系统的oom。
twemproxy理论上占用的内存比较少,因为twemproxy本身不存储任何数据,只有mbuf,不至于引发OOM(out of memory)。
我管理的一个twemproxy集群10个proxy instance先后在2天时间内全部死掉(监控不到位,系统swap不足没报警)。
分析的过程如下:
1)10台机器的系统日志都显示的twemproxy(nutcracker)发生了oom。
/var/log/messages.1:Sep 13 06:11:09 65-db-twemproxy kernel: nutcracker invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
/var/log/messages.1:Sep 13 06:11:10 65-db-twemproxy kernel: Out of memory: Killed process 8570, UID 500, (nutcracker).

2)sar日志显示在swap一段时间之后,内存得到了释放。这个时间点在出现了oom和twemproxy进程被杀死的时间一致。
twemproxy oom

3)通过zabbix发现,twemproxy有大量的qps,约8.7w。这对于非业务高峰期,不是正常的行为。
oom原因:程序中的大量查询requests导致twemproxy内存不足,引起oom。

最后找到开发,排查一下程序代码中的逻辑。在程序逻辑中,竟然单个的pipeline发送了200w的redis commands,导致触发了oom。
Github里面也有人反馈这种OOM现象,twemproxy开发人员也建议不要滥用pipeline。

https://github.com/twitter/twemproxy/issues/203

比如我们pipeline是200w请求,一个请求占用一个mbuf,那么
消耗的内存约为 2000000 * 16k/1024/1024 = 30G
twemproxy机器内存均为32G,很容易引发oom。

没有更好的办法解决这个bug,只好让开发这边把程序中的pipeline的命令个数改为了500。

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

twemproxy oom分析》有 1 条评论

  1. Pingback引用通告: redis&twemproxy问题总结 | DBA的罗浮宫

发表评论

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

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