Laf 公众号已接入了 AI 聊天机器人🤖，支持 GPT、Claude 以及 Laf 专有模型，可通过指令来随意切换模型。欢迎前来调戏👇
❝本文转自博客园，原文：https://www.cnblogs.com/charlieroro/p/17379469.html，版权归原作者所有。欢迎投稿，投稿请添加微信好友：cloud-native-yang
本文最终的解决方式很简单，就是将现有卷升级为支持更高 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 的延迟 (见附录)：
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(支持最小 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 时却没有什么变化。
操作系统通常会缓存写操作，当写操作结束之后，数据仍然存在缓存中，需要等待刷新到磁盘。
数据库则不同，它需要知道数据写入的时间和地点。假设一个执行 EFTPOS(电子钱包转帐) 交易的数据库被突然重启，仅仅知道数据被 " 最终 " 写入是不够的。
AWS 在其文档[1]中提到：
❝事务敏感的应用对 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 一方面和自身实现有关，另一方面受到存储本身的限制。
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[6]的 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
数据库通常都会使用 WAL，etcd 也不例外。etcd 会将针对 key-value 存储的特定操作 (在 apply 前) 写入 WAL 中，当一个成员崩溃并重启，就可以通过 WAL 恢复事务处理。
因此，在客户端添加或更新 key-value 存储前，etcd 都会将操作记录到 WAL，在进一步处理前，etcd 必须 100% 保证 WAL 表项被持久化。由于存在缓存，因此仅仅使用 write 系统调用是不够的。为了保证数据能够写入持久化存储，需要在 write 之后执行 fdatasync 系统调用 (这也是 etcd 实际的做法)。
为了获得有意义的结果，需要保证 fio 生成的写入负载和 etcd 写入 WAL 文件的方式类似。因此 fio 也必须采用顺序写入文件的方式，并在执行 write 系统调用之后再执行 fdatasync 系统调用。为了达到顺序写的目的，需要指定--rw=write，为了保证 fio 使用的是 write 系统调用，而不是其他系统调用 (如 pwrite[7])，需要使用--ioengine=sync，最后，为了保证每个 write 调用之后都执行 fdatasync，需要指定--fdatasync=1，另外两个参数--size 和--bs 需要根据实际情况进行调整。
[1]
文档: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html#ebs-io-volume-queue
[2]stat: https://linux.die.net/man/2/stat
[3]使用 Fio 来测试 Etcd 的存储性能: https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd
[4]建议: https://etcd.io/docs/v3.5/op-guide/performance/
[5]fio: https://github.com/axboe/fio
[6]fdatasync: https://linux.die.net/man/2/fdatasync
[7]pwrite: https://linux.die.net/man/2/pwrite
Laf 是一款为所有开发者打造的集函数、数据库、存储为一体的云开发平台，助你像写博客一样写代码，随时随地发布上线应用！3 分钟上线 ChatGPT 应用！
🌟GitHub：https://github.com/labring/laf
🏠官网（国内）：https://laf.run
🌎官网（海外）：https://laf.dev
💻开发者论坛：https://forum.laf.run
关注 Laf 公众号与我们一同成长👇👇👇
