K8s Etcd 性能慢，调整这个参数快多了！

本文最终的解决方式很简单，就是将现有卷升级为支持更高 IOPS 的卷，但解决问题的过程值得推荐。

我们的团队看管着大约 30 套自建的 Kubernetes 集群，最近需要针对 etcd 集群进行性能分析。

每个 etcd 集群有 5 个成员，实例型号为 m6i.xlarge，最大支持 6000 IOPS。每个成员有 3 个卷：

• root 卷
• write-ahead-log 的卷
• 数据库卷

每个卷的型号为 gp2，大小为 300gb，最大支持 900 IOPS：

 

 

测试写性能

首先 (在单独的实例上执行) 执行 etcdctl check perf 命令，模拟 etcd 集群的负载，并打印结果。可以通过--load 参数来模拟不同大小的集群负载，支持参数为：s(small), m(medium), l(large), xl(xLarge)。

当 load 为 s 时，测试是通过的。

 

但当 load 为 l 时，测试失败。可以看到，集群可执行 6.6K/s 的写操作，可以认为我们的集群介于中等集群和大型集群之间。

 

下面是使用 iostat 展示的磁盘状态，其中 nvme1n1 是 etcd 的 write-ahead-log 卷，其 IO 使用率已经达到 100%，导致 etcd 的线程等待 IO。

 下面使用 fio 来查看 fdatasync 的延迟 (见附录)：

 

可以看到 fdatasync 延迟的 99th 百分比为 2671 usec (或 2.7ms)，说明集群足够快 (etcd 官方建议最小 10ms)。从上面的输出还可以看到报告的 IOPS 为 709，相比 gp2 EBS 卷宣称的 900 IOPS 来说并不算低。

升级为 GP3

下面将卷升级为 GP3(支持最小 3000 IOPS)。

 

可以看到 IOPS 变为了 1105，但远低于预期，通过查看磁盘的使用率，发现瓶颈仍然是 EBS 卷。

鉴于实例类型支持的最大 IOPS 约为 6000，我决定冒险一试，看看结果如何：

 可以看到的确遇到了瓶颈，当 IOPS 规格从 900 变为 3000 时，实际 IOPS 增加了 30%，但 IOPS 规格从 3000 变为 6000 时却没有什么变化。

 

IOPS 到哪里去了？

操作系统通常会缓存写操作，当写操作结束之后，数据仍然存在缓存中，需要等待刷新到磁盘。

数据库则不同，它需要知道数据写入的时间和地点。假设一个执行 EFTPOS(电子钱包转帐) 交易的数据库被突然重启，仅仅知道数据被 " 最终 " 写入是不够的。

AWS 在其文档中提到：

事务敏感的应用对 I/O 延迟比较敏感，适合使用 SSD 卷。可以通过保持低队列长度和合适的 IOPS 数量来保持高 IOPS，同时降低延迟。持续增加卷的 IOPS 会导致 I/O 延迟的增加。

吞吐量敏感的应用则对 I/O 延迟增加不那么敏感，适合使用 HDD 卷。可以通过在执行大量顺序 I/O 时保持高队列长度来保证 HDD 卷的高吞吐量。

 

etcd 在每个事务之后都会使用一个 fdatasync 系统调用，这也是为什么在 fio 命令中指定—fdatasync=1 的原因。

fsync() 会将文件描述符 fd 引用的所有 (被修改的) 核心数据刷新到磁盘设备 (或其他永久存储设备)，这样就可以检索到这些信息 (即便系统崩溃或重启)。
该调用在设备返回前会被阻塞，此外，它还会刷新文件的元数据 (参见 stat[2](2))

fdatasync() 类似 fsync()，但不会刷新修改后的元数据 (除非需要该元数据才能正确处理后续的数据检索)。
例如，修改 st_atime 或 st_mtime 并不会刷新，因为它们不会影响后续数据的读取，但对文件大小 (st_size) 的修改，则需要刷新元数据。

 

 

可以看到这种处理方式对性能的影响比较大。

下表展示了各个卷类型的最大性能，与 etcd 相关的是 Max synchronous write：

可以看到 etcd 的 iops 一方面和自身实现有关，另一方面受到存储本身的限制。

附录

使用 Fio 来测试 Etcd 的存储性能^[3]

etcd 集群的性能严重依赖存储的性能，为了理解相关的存储性能，etcd 暴露了一些 Prometheus 指标，其中一个为 wal_fsync_duration_seconds，etcd建议^[4]当 99% 的指标值均小于 10ms 时说明存储足够快。可以使用fio^[5]来验证 etcd 的处理速度，在下面命令中，test-data 为测试的挂载点目录：

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

在命令输出中，只需关注fdatasync的 99th 百分比是否小于 10ms，在本场景中，为 2180 微秒，说明存储足够快：

fsync/fdatasync/sync_file_range:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]

注意：

• 可以根据特定的场景条件--size 和--bs
• 在本例中，fio 是唯一的 I/O，但在实际场景中，除了和 wal_fsync_duration_seconds 相关联的写入之外，很可能还会有其他写入存储的操作，因此，如果从 fio 观察到的 99th 百分比略低于 10ms 时，可能并不是因为存储不够快。
• fio 的版本不能低于 3.5，老版本不支持 fdatasync

Etcd WALs

数据库通常都会使用 WAL，etcd 也不例外。etcd 会将针对 key-value 存储的特定操作 (在 apply 前) 写入 WAL 中，当一个成员崩溃并重启，就可以通过 WAL 恢复事务处理。

因此，在客户端添加或更新 key-value 存储前，etcd 都会将操作记录到 WAL，在进一步处理前，etcd 必须 100% 保证 WAL 表项被持久化。由于存在缓存，因此仅仅使用 write 系统调用是不够的。为了保证数据能够写入持久化存储，需要在 write 之后执行 fdatasync 系统调用 (这也是 etcd 实际的做法)。

使用 fio 访问存储

为了获得有意义的结果，需要保证 fio 生成的写入负载和 etcd 写入 WAL 文件的方式类似。因此 fio 也必须采用顺序写入文件的方式，并在执行 write 系统调用之后再执行 fdatasync 系统调用。为了达到顺序写的目的，需要指定--rw=write，为了保证 fio 使用的是 write 系统调用，而不是其他系统调用 (如 pwrite^[7])，需要使用--ioengine=sync，最后，为了保证每个 write 调用之后都执行 fdatasync，需要指定--fdatasync=1，另外两个参数--size 和--bs 需要根据实际情况进行调整。

 

原文链接：https://www.cnblogs.com/charlieroro/p/17379469.html