etcd:增加30%的写入性能
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在其文档中提到:
事务敏感的应用对I/O延迟比较敏感,适合使用SSD卷。可以通过保持低队列长度和合适的IOPS数量来保持高IOPS,同时降低延迟。持续增加卷的IOPS会导致I/O延迟的增加。
吞吐量敏感的应用则对I/O延迟增加不那么敏感,适合使用HDD卷。可以通过在执行大量顺序I/O时保持高队列长度来保证HDD卷的高吞吐量。
etcd在每个事务之后都会使用一个fdatasync系统调用,这也是为什么在fio命令中指定—fdatasync=1
的原因。
fsync()会将文件描述符fd引用的所有(被修改的)核心数据刷新到磁盘设备(或其他永久存储设备),这样就可以检索到这些信息(即便系统崩溃或重启)。该调用在设备返回前会被阻塞,此外,它还会刷新文件的元数据(参见stat(2))
fdatasync() 类似 fsync(),但不会刷新修改后的元数据(除非需要该元数据才能正确处理后续的数据检索)。例如,修改st_atime或st_mtime并不会刷新,因为它们不会影响后续数据的读取,但对文件大小(st_size)的修改,则需要刷新元数据。
可以看到这种处理方式对性能的性能比较大。
下表展示了各个卷类型的最大性能:
附录
使用Fio来测试Etcd的存储性能
etcd集群的性能严重依赖存储的性能,为了理解相关的存储性能,etcd暴露了一些Prometheus指标,其中一个为
wal_fsync_duration_seconds
,etcd建议当99%的指标值均小于10ms时说明存储足够快。可以使用fio来验证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),需要使用--ioengine=sync
,最后,为了保证每个write调用之后都执行fdatasync
,需要指定--fdatasync=1
,另外两个参数--size
和--bs
需要根据实际情况进行调整。
etcd:增加30%的写入性能的更多相关文章
- HBase写入性能改造(续)--MemStore、flush、compact参数调优及压缩卡的使用【转】
首先续上篇测试: 经过上一篇文章中对代码及参数的修改,Hbase的写入性能在不开Hlog的情况下从3~4万提高到了11万左右. 本篇主要介绍参数调整的方法,在HDFS上加上压缩卡,最后能达到的写入 ...
- CQRS之旅——旅程7(增加弹性和优化性能)
旅程7:增加弹性和优化性能 到达旅程的终点:最后的任务. "你不能飞的像一只长着鹪鹩翅膀的老鹰那样."亨利·哈德逊 我们旅程的最后阶段的三个主要目标是使系统对故障更具弹性,提高UI ...
- MySQL存储写入性能严重抖动分析
案例描述: 通过iostat发现存储的写性能长期维持在10MB左右,而且因为写性能差已经导致数据库性能变差: 两个小时以后,iostat发现系统的写性能已经能够到100MB以上,数据库性能也恢复正常. ...
- python测试mysql写入性能完整实例
这篇文章主要介绍了python测试mysql写入性能完整实例,具有一定借鉴价值,需要的朋友可以参考下 本文主要研究的是python测试mysql写入性能,分享了一则完整代码,具体介绍如下. 测试环境: ...
- 《MySQL必知必会》学习笔记——第30章 改善性能
本章将付息与MySQL性能有关的某些要点. 30.1 改善性能 数据库管理员把他们生命中的相当一部分时间花在了调整.试验以改善DBMS性能之上.在诊断英勇的滞缓现象和性能问题时,性能不良的数据库(以及 ...
- tantivy&lucene功能,写入性能对比
硬件概述:cpu:24,内存:20g,磁盘:10*2.7T. 写入性能:(不对ip进行添加geo信息). 写入性能对比 速度 Commit耗时(秒) 500*1000条 Bulk耗时(秒) 1000条 ...
- samba性能调优,调优后,性能增加30%
global中增加下面内容. [global] use sendfile = yes write raw = yes read raw = yes max xmit = 655 ...
- HBase写入性能及改造——multi-thread flush and compaction(续:详细测试数据)[转]
转载:http://blog.csdn.net/kalaamong/article/details/7290192 接上文啊: 测试机性能 CPU 16* Intel(R) Xeon(R) CPU ...
- 修改Flume-NG的hdfs sink解析时间戳源码大幅提高写入性能
Flume-NG中的hdfs sink的路径名(对应参数"hdfs.path",不允许为空)以及文件前缀(对应参数"hdfs.filePrefix")支持正则解 ...
- 性能优化 | 30个Java性能优化技巧,你会吗?
在Java程序中,性能问题的大部分原因并不在于Java语言,而是程序本身.养成良好的编码习惯非常重要,能够显著地提升程序性能. 1.尽量在合适的场合使用单例 使用单例可以减轻加载的负担,缩短加载的时间 ...
随机推荐
- 单向链表&有关类和对象
// Test515.cpp: 定义控制台应用程序的入口点.// #include "stdafx.h"#include <iostream>using namespa ...
- 字符串练习2 最长抑或路径(01trie树)
题目链接在这里:P4551 最长异或路径 - 洛谷 | 计算机科学教育新生态 (luogu.com.cn) 是一道比较经典的问题,对于异或问题经常会使用01trie树来解决. 当然01trie树只是用 ...
- 简单总结一下html中能见到的各种相对路径
试列举如下(在本文中,星号表示资源名): href="/*" href="//*" href="*" href="./*" ...
- 我在迁移我的IDEA的项目、模块等东西的过程中发生过的一部分问题的我的一部分的记录以及我的解决方案如下
使用idea2019阶段报的一些错: 1.'xxxServlet' is not assignable to 'javax.servlet.Servlet' 解决方案:把tomcat加入classpt ...
- flask接口动态注册--依赖于蓝图
# 实现代码 blueprint_d = dict() dirs = os.listdir(base_dir) # 获取apps路径下所有文件夹列表 for d in dirs: ## 1.遍历模块文 ...
- lua脚本概述
1.lua脚本非常简单,轻量级,易于c/c++调用 2. 协程 是什么,与线程有啥区别 ??
- 关于不同平台、环境下64位int型的输入输出方式(转)
C语言 64位int 定义方式: Linux: long long Windows:__int64 C语言 64位int 输出方式: Linux: "%lld" ...
- 音频的价值、AI Codec 的意义与算法能力的边界丨一期一会 • 音频工程师专场
前言 音频技术发展到今天,经历了从模拟音频到数字音频到历程.国际音频工程师协会创建于 1948 年,中国数字音频技术起步相对较晚,长期被国外组织和公司垄断.随着中国的不断发展.科技日益进步,经过近三十 ...
- uni-app云开发入门
云函数 首先创建一个uniapp项目,创建项目时选择启用uniCloud云开发. 创建项目成功后,按照下面的步骤进行开发. 创建云函数 1.关联云服务器 2.创建云函数 一个云函数可以看成是一个后 ...
- 移动端pdf预览---vue-pdf
<template> <div class="mainBody"> <!-- <div v-if="isLoading" c ...