etcd：增加30%的写入性能
内容提要
本文介绍了对etcd集群性能分析的过程，发现写性能瓶颈导致线程等待IO。尝试升级卷为GP3类型提高IOPS，但未达预期。还介绍了fdatasync系统调用对性能的影响和etcd存储性能测试方法。
延伸解读
性能瓶颈的定位方法
文章通过etcdctl check perf模拟负载，结合iostat和fio工具，定位到写性能瓶颈在于WAL卷的IOPS不足。iostat显示nvme1n1卷的IO使用率达100%，导致线程等待IO。fio测试fdatasync延迟，99th百分位为2671微秒，虽低于etcd建议的10ms，但IOPS仅709，接近gp2卷的900 IOPS上限。这种方法适用于诊断存储性能问题。
卷升级的实际效果与限制
将gp2卷升级为GP3后，IOPS从709提升至1105，fdatasync延迟99th百分位降至1450微秒，但远低于GP3宣称的3000 IOPS。进一步尝试更高IOPS规格，实际IOPS仅增加30%至1129，表明瓶颈仍在EBS卷。这说明云盘性能受实例类型和卷类型双重限制，升级前需评估实际需求。
fdatasync对etcd性能的关键影响
etcd在每个事务后调用fdatasync，确保WAL条目持久化，防止数据丢失。但fdatasync会阻塞直到数据写入磁盘，且不刷新元数据（除非必要），这增加了I/O延迟。文章通过fio模拟etcd的写入模式（顺序写、sync引擎、fdatasync=1），测得延迟数据，帮助判断存储是否满足etcd要求（99%的fdatasync延迟小于10ms）。
测试注意事项与局限性
使用fio测试时，需确保版本不低于3.5，并正确设置--size和--bs参数以模拟实际负载。但fio测试为单一I/O，实际环境中可能存在其他写入操作，因此若fio的99th延迟略低于10ms，存储可能仍不够快。此外，etcd的IOPS既受自身实现影响，也受存储限制，需综合评估。
Q&A
etcd集群的写性能瓶颈是什么？
etcd集群的写性能瓶颈主要是由于线程等待IO造成的，尤其是在使用gp2卷时，最大支持900 IOPS。
如何测试etcd的存储性能？
可以使用fio工具进行测试，命令中需指定--rw=write和--fdatasync=1，以模拟etcd的写入方式。
将卷升级为GP3后，etcd的IOPS表现如何？
升级为GP3后，etcd的IOPS从900提升至1105，但仍低于预期的3000 IOPS。
fdatasync系统调用对etcd性能有什么影响？
fdatasync系统调用确保数据持久化，但会导致I/O延迟增加，从而影响etcd的整体性能。
etcd集群在负载为l时的写操作能力是多少？
在负载为l时，etcd集群的写操作能力为6.6K/s。
为什么在高IOPS下etcd的性能仍然受限？
尽管IOPS规格提高，但操作系统的写缓存和存储设备的限制仍会导致性能瓶颈。
