排查 etcd 响应慢的问题

有一台 etcd,突然出现了响应缓慢的情况。排查中发现,系统 CPU,带宽,IO,内存,rlimit 都还有很大余量。但是 ss 发现,端口的backlog 堆积了大量连接。

$ ss -lnt
State      Recv-Q Send-Q            Local Address:Port              Peer Address:Port
...
LISTEN     745    65535               10.20.30.40:2379                         *:*
...

但是看并没有 SYN_RECV 状态的连接存在。所以不像由于并发连接太多造成的来不及 accept,而是 etcd 本身处理 accept
的过程慢。统计 ESTABLISHED 连接数,发现数量总是大致在 10000 个左右。这个连接数看起来很整,怀疑是不是有什么特殊的限制。

于是去看 etcd 的代码,发现 etcdmain/etcd.go 中,启动 etcd 的代码里有

l = transport.LimitListener(l, int(fdLimit-reservedInternalFDNum))

这个 LimitListener 限制了最多同时服务的客户端连接数,超过时就会等待已有连接退出。传入的 fdLimit 是获取的 open files rlimit 限制。reservedInternalFDNum 是保留的 fd 数,是个等于 150 的常量。看起来意图是在 fd 不够用的时候,保证自身的 IO 和集群通信不受影响。

后来了解到,ulimit 原本是 10240,后来调整到了 102400,当时为了不重启进程,动态修改了运行中的 etcd 的 rlimit。没想到 etcd 在启动的时候还使用这个值做了自己的限制。虽然 rlimit 改了,但是由于进程没重启,etcd 还是使用的原来的值做的限制。最后重启 etcd 就恢复了正常。

Leave a Reply

Your email address will not be published. Required fields are marked *