为什么你的etcd请求会超时
etcd请求出现高延迟
etcd的请求为何出现高延迟?
Leader在接收到的写请求,讲一个日志条目复制到集群多数节点并应用到存储状态的流程,会出现哪些情况导致请求超时？
- Leader向从节点发消息:Leader需要并行将消息通过网络发送给Follower节点,依赖网络性能;Leader需持久化日志条目到WAL,依赖磁盘IO顺序写入性能。
- 应用日志条目到存储状态机时,etcd后端key-value存储引擎是boltdb,boltdb是一个基于B+ Tree实现的存储引擎,当写入数据、提交事物时,它会将
dirty page持久化到磁盘中。- 在整个写流程过程中,etcd节点的cpu、内存、网络资源应充足,否则可能也会影响性能。
定位网络延时抖动
使用ping/traceroute/mtr、ethtool、ifconfig/ip、netstat、tcpdump等命令获取相关数据。
etcd应用层提供了节点之间网络统计的metrics指标:
| 指标 | 解释 |
|---|---|
| etcd_network_active_peer | peer之间活跃的连接数 |
| etcd_network_peer_round_trip_time_seconds | peer之间rtt延时 |
| etcd_network_peer_send_failures_total | peer发送的失败消息数 |
| etcd_network_client_grpc_send_bytes_total | server发送给client的总字节数 |
| etcd_network_client_grpc_received_bytes_total | server接收到client的总字节数 |
网络质量导致etcd性能:
- expensive request中的大包查询会使网卡出现瓶颈,产生丢表等错误,从而导致etcd吞吐量下降、高延时,这是因为业务没有遵循最佳实践,查询了大量key-value。
- 在跨故障部署的时候,故障域可能是可用区、城市,各个节点的RTT越高,请求的延时跟高。
磁盘I/O
etcd_disk_wal_fsync_duration_seconds(表示WAL日志持久化的fsync系统调用延时数据)
和etcd_disk_backend_commit_duration_seconds(后端boltdb事物提交的延时)观察应用层写入磁盘的性能。
如果etcd的WAL模块在fdatasync操作超过1秒时,将相应的日志输出。
etcd_disk_backend_commit_duration_seconds指标的异常时,说明事物提交过程中的B+ Tree树重平衡、分裂、持久化dirty page、持久化meta
page 等操作耗费了大量时间。
etcd_disk_backend_commit_duration_seconds较高、etcd_disk_wal_fsync_duration_seconds正常,说明B+ Tree的重平衡、分裂过程中的
较高时间复杂度逻辑操作导致。
disk_backend_commit_rebalance_duration和disk_backend_commit_spill_duration分别表明事物提交过程中B+ Tree的重平衡和分裂操作
耗时分布区间。
etcd_disk_wal_fsync_duration_seconds记录的是WAL文件顺序写入的持久化时间, etcd_disk_backend_commit_duration_seconds记录
的是整个事物提交的耗时。
Expensive request
etcd 3.2和etcd 3.3版本写请求完成之前,需要更新MVCC的buffer,进行升级锁操作。然而此时若集群中出现一个long expensive read request,
则会导致写请求延时抖动。
在etcd 3.4中,logger默认为capnslog,trace特性只有在当logger为zap时才开启,因此你需要设置--logger=zap。
trace特性不能记录所有类型的请求,目前只覆盖了MVCC模块中的range/put/txn等常用接口。
