你好,我是唐聪。
在使用 etcd 的过程中,你是否被日志中的"apply request took too long"和“etcdserver: request timed out"等高延时现象困扰过?它们是由什么原因导致的呢?我们应该如何来分析这些问题?
这就是我今天要和你分享的主题:etcd 延时。希望通过这节课,帮助你掌握 etcd 延时抖动、超时背后的常见原因和分析方法,当你遇到类似问题时,能独立定位、解决。同时,帮助你在实际业务场景中,合理配置集群,遵循最佳实践,尽量减少 expensive request,避免 etcd 请求出现超时。
分析思路及工具
首先,当我们面对一个高延时的请求案例后,如何梳理问题定位思路呢?
知彼知己,方能百战不殆,定位问题也是类似。首先我们得弄清楚产生问题的原理、流程,在02、03、04中我已为你介绍过读写请求的核心链路。其次是熟练掌握相关工具,借助它们,可以帮助我们快速攻破疑难杂症。 这里我们再回顾下 03 中介绍的,Leader 收到一个写请求,将一个日志条目复制到集群多数节点并应用到存储状态机的流程(如下图所示),通过此图我们看看写流程上哪些地方可能会导致请求超时呢?
首先是流程四,一方面,Leader 需要并行将消息通过网络发送给各 Follower 节点,依赖网络性能。另一方面,Leader 需持久化日志条目到 WAL,依赖磁盘 I/O 顺序写入性能。