diff --git a/README.md b/README.md index 9c716610fe..3e7573be19 100644 --- a/README.md +++ b/README.md @@ -199,6 +199,8 @@ Fio Curve engine is added, you can clone https://github.com/opencurve/fio and co $ ./fio --thread --rw=randwrite --bs=4k --ioengine=nebd --nebd=cbd:pool//pfstest_test_ --iodepth=10 --runtime=120 --numjobs=10 --time_based --group_reporting --name=curve-fio-test ``` +If you have any questions during performance testing, please check the [Curve block storage performance tuning guide](docs/cn/Curve%E5%9D%97%E5%AD%98%E5%82%A8%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98%E6%8C%87%E5%8D%97.md). + ## CurveFS quick start Please use [CurveAdm](https://github.com/opencurve/curveadm/wiki) tool to deploy CurveFS,see [CurveFS Deployment Process](https://github.com/opencurve/curveadm/wiki/curvefs-cluster-deployment), and the [CurveFS Command Instructions](curvefs/src/tools#readme). diff --git a/README_cn.md b/README_cn.md index 0b5510b458..ab2eb794b8 100644 --- a/README_cn.md +++ b/README_cn.md @@ -196,6 +196,8 @@ fio的Curve块存储引擎代码已经上传到 https://github.com/opencurve/fio $ ./fio --thread --rw=randwrite --bs=4k --ioengine=nebd --nebd=cbd:pool//pfstest_test_ --iodepth=10 --runtime=120 --numjobs=10 --time_based --group_reporting --name=curve-fio-test ``` +在性能测试过程中有任何问题,请查看[Curve块存储性能调优指南](docs/cn/Curve%E5%9D%97%E5%AD%98%E5%82%A8%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98%E6%8C%87%E5%8D%97.md) + ## CurveFS 快速体验 请使用 [CurveAdm](https://github.com/opencurve/curveadm/wiki) 工具进行 CurveFS 的部署,具体流程见:[CurveFS部署流程](https://github.com/opencurve/curveadm/wiki/curvefs-cluster-deployment), 以及[CurveFS命令行工具说明](curvefs/src/tools#readme)。 diff --git "a/docs/cn/Curve\345\235\227\345\255\230\345\202\250\346\200\247\350\203\275\350\260\203\344\274\230\346\214\207\345\215\227.md" "b/docs/cn/Curve\345\235\227\345\255\230\345\202\250\346\200\247\350\203\275\350\260\203\344\274\230\346\214\207\345\215\227.md" new file mode 100644 index 0000000000..be84c60507 --- /dev/null +++ "b/docs/cn/Curve\345\235\227\345\255\230\345\202\250\346\200\247\350\203\275\350\260\203\344\274\230\346\214\207\345\215\227.md" @@ -0,0 +1,210 @@ +# Curve块存储性能调优指南 + +## 背景 + +本文档主要描述Curve块存储的参数是如何影响性能的,以及要如何调整,可以使得性能到达最优。 + +## 参考性能 + +测试场景:3台机器*10块/盘 + +盘的型号:Intel® Solid State Drive DC S3510 Series + +测试工具:[curve-fio](https://github.com/opencurve/fio#readme) + +测试版本:v1.2.5 (配置copyset.enable_odsync_when_open_chunkfile=true。 这个选项默认为false,可以优化性能,但是会有iops或者带宽抖动,请根据业务场景进行确定) + +测试卷大小:100GB + +条带化卷参数:stripeUnit=16k stripeCount=64(大io建议创建条带化卷测试) + +### 8k随机写测试数据 + +**客户端个数:** 3 + +**fio配置:** +``` +[global] +bs=8K +iodepth=128 +rw=randwrite +direct=1 +numjobs=1 +size=100G +ioengine=cbd +runtime=999999 +time_based +group_reporting +ramp_time=10s +``` + +**性能数据:** +|iops(k)|avg lat(us)|99th lat(us) +|----|-----|----| +|27.9|4590|27919 +|27.7|4614|27919 +|28.1|4549|27657 + +### 512k顺序写测试数据 + +**客户端个数:** 3 + +**fio配置:** +``` +[global] +bs=512k +iodepth=128 +rw=write +direct=1 +numjobs=1 +size=100G +ioengine=cbd +group_reporting +runtime=90 +ramp_time=10s +``` + +|bandwidth(MB/s)|avg lat(ms)|99th lat(ms) +|----|-----|----| +|338|189|372 +|338|189|485 +|343|186|397 + + +## 影响性能的关键指标 + +性能指标的查看途径有两种: +1. 直接通过服务的ip:port获取 +2. 通过监控查看([块存储监控部署](https://github.com/opencurve/curveadm/wiki/curvebs-monitor-deployment)) + +### 环境配置 + + +环境配置可以参考: [推荐配置设置](https://github.com/opencurve/curve/blob/master/docs/cn/%E6%B5%8B%E8%AF%95%E7%8E%AF%E5%A2%83%E9%85%8D%E7%BD%AE%E4%BF%A1%E6%81%AF.md) + +**需要特别说明的是**,对于使用RAID/SAS卡及Sata SSD的环境,**需要在关闭磁盘缓存后,重启机器,使 RAID/SAS 卡识别磁盘缓存已经关闭。** 如果磁盘缓存打开,对文件的sync操作会发送至磁盘,导致磁盘性能下降。 + +重启后,对SSD盘上的文件系统,进行 fio 测试,验证缓存是否关闭。 + +fio脚本: + +``` +[global] +rw=randwrite +iodepth=1 +ioengine=psync +fdatasync=1 +bsrange=4k-4k +size=4G +numjobs=32 +group_reporting +time_based=1 +thread=1 +runtime=10000 + +[disk0] +filename=/data/chunkserver0/data +[disk1] +filename=/data/chunkserver1/data +``` + +> 如果有多个SSD盘,在 fio 脚本的后面加上对应的盘。 + +> fio 测试写入的文件,最好提前通过 dd 命令创建或覆盖写一遍,dd if=/dev/zero of=/data/chunkserver0/data bs=1M count=4096 oflag=direct + +如果关闭成功,fio 报告的 IOPS 与 iostat -mtx 1 看到的 SSD 盘上的 w/s 是一致的 + +![](../images/0102-diskcache1.jpg) + +如果缓存未关闭或机器未重启,会出现 fio 报告的 IOPS 只有 SSD 盘上 w/s 一半的情况 + +![](../images/0102-diskcache2.jpg) + +### 服务端 + +**1. 复制组的leader在chunkserver上的分布是否均衡** + +在Curve块存储中,所有的读写请求都是发往leader处理的,如果复制组的leader在chunkserver上分布不均衡,会导致chunkserver上接受到请求的压力不同,导致无法完全发挥集群性能。 + +- metric指标查看:```curl leadermdsip:leadermdsport/vars | grep leadernum_range``` +查看chunkserver上leader数量最大和最小的差值, **一般这个值在5以内认为集群是均衡的** + + ``` + topology_metric_logical_pool_default_logical_pool_leadernum_range : 1.000 + ``` + +- 监控:```MDS DashBord/chunkserver状态 panel``` + + ![leadermetric](../images/0102-leadermetric.jpg) + +- leader不均衡时可以通过命令触发快速均衡:```curve_ops_tool rapid-leader-schedule```。这个命令创建的配置变更任务是随着心跳上报的,所以均衡效果在几个心跳周期之后可以看到(默认心跳周期是10s)。 + +**2. 复制组之间的心跳周期** + +在Curve块存储中,复制组的心跳周期通过chunkserver的配置项```copyset.election_timeout_ms=1000```确定,默认是1s。由于复制组的心跳和用户数据的复制都是使用的bthread,当集群压力特别大时,会导致复制组心跳超时,复制组的leader在不断的切换。有三个表现: +- 从监控上可以看到每个chunkserver上的leader不均衡,并且单个chunkserver上的leader总是在变动(参考 **1. 复制组的leader在chunkserver上的分布是否均衡**) + +- 监控项 ```chunkserver Dashbord/线程指标 Panels``` 中bthread的使用率持续飙高。更多信息的获取可以参考[brpc线程数量查看](https://github.com/apache/incubator-brpc/blob/master/docs/cn/server_debugging.md#1%E6%A3%80%E6%9F%A5%E5%B7%A5%E4%BD%9C%E7%BA%BF%E7%A8%8B%E7%9A%84%E6%95%B0%E9%87%8F) + + ![bthreadmetric](../images/0102-bthreadcountmetric.jpg) + +- chunkserver的日志中有大量leader选举日志 + + ``` + LOG(INFO) << "node " << _group_id << ":" << _server_id + << " received PreVoteResponse from " << peer_id + << " term " << response.term() << " granted " << response.granted(); + ``` + +这会导致client端有很多重试的rpc,加剧集群压力。 + +这种情况可以通过增大心跳周期规避leader频繁切换对性能的影响,即chunkserver配置项```copyset.election_timeout_ms=1000```。但这种规避方法不建议在生产环境中使用,复制组的心跳周期变大,会导致异常情况下IO的卡顿时间边长。复制组的心跳不受IO压力影响已经在优化中了,预计Q1会发布版本。 + +**3. 查看chunkserver节点上磁盘的压力** + +Curve块存储性能测试时,理想的状态是可以把磁盘跑满。如果发现有性能瓶颈,可以先查询一下,磁盘是否被打满。 + +- 通过linux命令```iostat```查看磁盘压力情况,一般看观察```util```是否接近100%,cpu 的```idle```是否接近0 + +- 通过查看监控项 ```chunkserver Dashbord/Raft关键指标 Panels``` + + ```storage_append_entries_latency``` : 写盘的延迟(一般ssd的延时在百us~几ms级别;hdd延迟在数十ms级别) + + ```raft_send_entries_latency```: 一次写盘延迟+一次rpc延迟(一般rpc的延迟在百us~几ms级别) + + ![latencymetric](../images/0102-latencymetric.jpg) + +如果底层磁盘已经压满,理论上就已经达到了集群性能上限。 + +### 客户端 + +**1. 大IO顺序写场景建议使用条带化卷** + +条带化卷的原理可以参考:[条带化设计](https://github.com/opencurve/curve/blob/master/docs/cn/curve-stripe.pdf)。概括来说,条带化是将大IO按照指定的配置,分发到多个复制组上,从而提高性能。 + +条带化卷的创建:```curve_ops_tool create -fileName=/test -userName=test -password=123 -fileLength=20 -stripeUnit=32768 -stripeCount=32``` + +**2. 直接使用 ```curve fio```测试** + +当前Curve块存储支持的几个协议nbd、openstack、iscsi都是要跟Curve[热升级](https://github.com/opencurve/curve/blob/master/docs/cn/nebd.md)模块对接的,在IO链路上会多一次RPC。当前Curve块存储版本已经稳定,如果不考虑热升级,可以去掉热升级模块,提高性能。 + +Curve块存储fio的使用方式可以参考:[Fio for Curve README](https://github.com/opencurve/fio#readme) + +## 其他指标简析 + +详见[Curve块存储监控项说明](https://github.com/opencurve/curve/blob/master/docs/cn/Curve%E7%9B%91%E6%8E%A7%E6%8C%87%E6%A0%87%E8%A7%A3%E6%9E%90.md) + +IO过程中全链路关键阶段时延的metric查看(DashBord/Pannel,指标的具体含义请查看[Curve块存储监控项说明](https://github.com/opencurve/curve/blob/master/docs/cn/Curve%E7%9B%91%E6%8E%A7%E6%8C%87%E6%A0%87%E8%A7%A3%E6%9E%90.md)): + +``` +client端: +用户接口层指标/client_write_latency +rpc层指标/write_rpc_latency + +chunkserver端: +rpc层读写指标/avg_write_lat +chunkserver层读写指标/avg_write_lat +Raft关键指标/raft_send_entries_latency +Raft关键指标/raft_service_append_entries_latency +Raft关键指标/storage_append_entries_latency +``` \ No newline at end of file diff --git a/docs/images/0102-bthreadcountmetric.jpg b/docs/images/0102-bthreadcountmetric.jpg new file mode 100644 index 0000000000..2331cbdb86 Binary files /dev/null and b/docs/images/0102-bthreadcountmetric.jpg differ diff --git a/docs/images/0102-chunkserverdashbord.png b/docs/images/0102-chunkserverdashbord.png new file mode 100644 index 0000000000..f45b6cf3be Binary files /dev/null and b/docs/images/0102-chunkserverdashbord.png differ diff --git a/docs/images/0102-diskcache1.jpg b/docs/images/0102-diskcache1.jpg new file mode 100644 index 0000000000..69f9a84947 Binary files /dev/null and b/docs/images/0102-diskcache1.jpg differ diff --git a/docs/images/0102-diskcache2.jpg b/docs/images/0102-diskcache2.jpg new file mode 100644 index 0000000000..69aac419d3 Binary files /dev/null and b/docs/images/0102-diskcache2.jpg differ diff --git a/docs/images/0102-latencymetric.jpg b/docs/images/0102-latencymetric.jpg new file mode 100644 index 0000000000..41088c4eda Binary files /dev/null and b/docs/images/0102-latencymetric.jpg differ diff --git a/docs/images/0102-leadermetric.jpg b/docs/images/0102-leadermetric.jpg new file mode 100644 index 0000000000..f84ab3e746 Binary files /dev/null and b/docs/images/0102-leadermetric.jpg differ