etcd：增加30%的写入性能

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

译自：etcd: getting 30% more write/s

我们的团队看管着大约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的延迟(见附录)：

fio --rw=write --ioengine=sync --fdatasync=1 --directory=benchmark --size=22m --bs=2300 --name=sandbox
... 
Jobs: 1 (f=1): [W(1)][100.0%][w=1594KiB/s][w=709 IOPS][eta 00m:00s]
...
  fsync/fdatasync/sync_file_range:
    sync (usec): min=476, max=10320, avg=1422.54, stdev=727.83
    sync percentiles (usec):
     |  1.00th=[  523],  5.00th=[  545], 10.00th=[  570], 20.00th=[  603],
     | 30.00th=[  660], 40.00th=[  775], 50.00th=[ 1811], 60.00th=[ 1909],
     | 70.00th=[ 1975], 80.00th=[ 2057], 90.00th=[ 2180], 95.00th=[ 2278],
     | 99.00th=[ 2671], 99.50th=[ 2933], 99.90th=[ 4621], 99.95th=[ 5538],
     | 99.99th=[ 7767]
...
Disk stats (read/write):
  nvme1n1: ios=0/21315, merge=0/11364, ticks=0/13865, in_queue=13865, util=99.40%

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

升级为GP3

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

Jobs: 1 (f=1): [W(1)][100.0%][w=2482KiB/s][w=1105 IOPS][eta 00m:00s]
...
   iops        : min=  912, max= 1140, avg=1040.11, stdev=57.90, samples=19
...
  fsync/fdatasync/sync_file_range:
    sync (usec): min=327, max=5087, avg=700.24, stdev=240.46
    sync percentiles (usec):
     |  1.00th=[  392],  5.00th=[  429], 10.00th=[  457], 20.00th=[  506],
     | 30.00th=[  553], 40.00th=[  603], 50.00th=[  652], 60.00th=[  709],
     | 70.00th=[  734], 80.00th=[  857], 90.00th=[ 1045], 95.00th=[ 1172],
     | 99.00th=[ 1450], 99.50th=[ 1549], 99.90th=[ 1844], 99.95th=[ 1975],
     | 99.99th=[ 3556]
...
Disk stats (read/write):
  nvme2n1: ios=5628/10328, merge=0/29, ticks=2535/7153, in_queue=9688, util=99.09%

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

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

Jobs: 1 (f=1): [W(1)][100.0%][w=2535KiB/s][w=1129 IOPS][eta 00m:00s]
...
  fsync/fdatasync/sync_file_range:
    sync (usec): min=370, max=3924, avg=611.54, stdev=126.78
    sync percentiles (usec):
     |  1.00th=[  420],  5.00th=[  453], 10.00th=[  474], 20.00th=[  506],
     | 30.00th=[  537], 40.00th=[  562], 50.00th=[  594], 60.00th=[  635],
     | 70.00th=[  676], 80.00th=[  717], 90.00th=[  734], 95.00th=[  807],
     | 99.00th=[  963], 99.50th=[ 1057], 99.90th=[ 1254], 99.95th=[ 1336],
     | 99.99th=[ 2900]
...

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

IOPS到哪里去了？

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

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

AWS在其文档中提到：

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

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

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

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

charlieroro