2023年7月23日发(作者：)

为什么你的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_peeretcd_network_peer_round_trip_time_secondsetcd_network_peer_send_failures_totaletcd_network_client_grpc_send_bytes_totaletcd_network_client_grpc_received_bytes_total⽹络质量导致etcd性能:解释peer之间活跃的连接数peer之间rtt延时peer发送的失败消息数server发送给client的总字节数server接收到client的总字节数expensive request中的⼤包查询会使⽹卡出现瓶颈,产⽣丢表等错误,从⽽导致etcd吞吐量下降、⾼延时,这是因为业务没有遵循最佳实践,查询了⼤量key-value。在跨故障部署的时候,故障域可能是可⽤区、城市,各个节点的RTT越⾼,请求的延时跟⾼。磁盘I/Oetcd_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、持久化metapage 等操作耗费了⼤量时间。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 requestetcd 3.2和etcd 3.3版本写请求完成之前,需要更新MVCC的buffer,进⾏升级锁操作。然⽽此时若集群中出现⼀个long expensive readrequest,则会导致写请求延时抖动。在etcd 3.4中,logger默认为capnslog,trace特性只有在当logger为zap时才开启,因此你需要设置--logger=zap。trace特性不能记录所有类型的请求,⽬前只覆盖了MVCC模块中的range/put/txn等常⽤接⼝。