ceph 压力测试

最新推荐文章于 2024-06-13 10:37:11 发布
最新推荐文章于 2024-06-13 10:37:11 发布
阅读量832 收藏
点赞数
文章标签： java 操作系统
原文链接：https://my.oschina.net/u/1169457/blog/740819
版权

[TOC]

ceph 压力测试报告

此文档最新版本地址

概述

对ceph文件集群进行性能测试, 以确认满足我们业务需求. 此次测试主要测试S3接口读写文件性能.

测试环境

网络拓扑结构

如下图, client和三台OSD集群在同一个内网, 每台OSD机器上, 分别装有MON和RGW. 测试时同时使用多个RGW, 由客户端控制将请求分发到不同RGW服务. 因部署遗留原因, 三台OSD机器编号从2开始, 分别是 DFS2, DFS3, DFS4.

image

软硬件环境

OSD服务器
服务器硬件配置软件配置
DFS2Intel Core i7-4790@ 3.60GHz 四核八线程 8G DDR3内存 1T 7200转硬盘, 1000M网口centos 7.2, ceph 10.2.2
DFS3Intel Core i7-4790@ 3.60GHz 四核八线程 8G DDR3内存 1T 7200转硬盘, 1000M网口centos 7.2, ceph 10.2.2
DFS4Intel Core i7-4790@ 3.60GHz 四核八线程 16G DDR3内存 1T 7200转硬盘, 1000M网口centos 7.2, ceph 10.2.2
测试客户端服务器
服务器硬件配置软件配置
10.141.5.63双核 Intel Xeon CPU E7- 4850 @ 2.00GHz, 4G内存, 1000M网口centos 6.8, java 1.7.0_79
10.141.4.83四核 Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GHz, 8G内存, 1000M网口centos 6.7, java 1.8.0_92
测试软件

基于aws api自己写的 java 客户端. 另外, 有推荐 cosbench 的. 以后可以看看.

maven依赖:

<dependency>
	<groupId>com.amazonaws</groupId>
	<artifactId>aws-java-sdk-s3</artifactId>
	<version>1.9.0</version>
</dependency>

压测数据

注意: 压测过程中, index副本数设置为1, 会比默认的3效率高些.

中等文件写入压测

测试内容: 文件大小95M,上传50次
在客户端5个线程,20个线程,50个线程 3种情况下得出数据:

1个副本 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
575.73162.960.66
2065.94772.3060.758
50(一条请求超时)83.3757.1950.5997
数据简单分析:
  • 最高写入速度也在70 M/s左右.
  • 三台OSD中的两台磁盘io几乎达到100%, 一台在90%左右. 磁盘成为性能瓶颈.
  • 线程数过多(50), 性能不升反降, 还会有超时现象.
2个副本 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
5139.24734.24390.359
20147.91332.2370.338
50138.83234.3460.360

数据简单分析: 瓶颈与1个副本1个RGW类似, 瓶颈在磁盘io. 两个副本最大写入速度在35M/s左右.

3个副本 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
1223.85921.300.223
5227.56320.9540.2197
20234.08820.370.21359

数据简单分析: 瓶颈与1个副本1个RGW类似, 瓶颈在磁盘io. 三个副本最大写入速度在30M/s左右.

小文件写入压测

测试内容: 文件大小30 000字节,上传5000次
客户端在启用20个线程,100个线程,200个线程 3种情况下得出数据:

设置了 index 分片为16. 默认index不分片, 会造成写索引时单台OSD成为瓶颈, 磁盘io占满(大约每秒写30个对象).

两个副本, 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
2052.4262.79695.37
10034.784.2158143.76
20034.4174.26145.277

资源占用 dstat信息:
20个线程:
image
100个线程:
image
200个线程:
image

磁盘占用 iostat信息:
20个线程:
image
100个线程:
image
200个线程:
image

数据简单分析:

  • 最高文件上传速度在每秒145个文件左右. 从20个线程到100个线程过程中, 写入速度明显提升; 100个线程后, 达到峰值.
  • 在压测过程中, 系统CPU占用很低. 从20个线程增长到200个线程, CPU占用增长不明显, 系统空闲CPU一直维持在80%以上.
  • 到100个线程以后, 磁盘 io 占用率达到100%, 成为系统瓶颈. 尽管写入量并不大, 但是因为大量小文件导致大量写入, 使磁盘时间占满.
  • 客户端在线程少的情况下, 不足以达到最高吞吐量.
单副本, 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
2041.8333.505119.523
10030.9294.741161.66
20040.9843.577122

数据简单分析:

  • 系统占用情况和磁盘占用情况和两个副本时相似, 这里省略.
  • 单副本最高文件写入速度在每秒160个左右. 从客户端20个线程到100个线程过程增长明显, 100个线程达到峰值, 从100到200之间有下降趋势.
  • 在200个线程时, 比100个线程速度要下降. 再数据出来以后又测试了多次, 200个线程一般和100个线程速度持平. 这个数据是一个特例.
  • 和两个副本相比, 因为要一份数据不需要保存两份到不同机器上, 减少了了网络和磁盘开销. 导致速度要比两个副本快.
三个副本, 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
2074.0181.9867.55
10047.2833.101105.746
20045.9833.1887108.7
  • 系统占用情况和磁盘占用情况和两个副本时相似, 这里省略.
  • 三个副本情况下, 最高文件写入速度在每秒105个左右. 从客户端20个线程到100个线程过程中, 增长明显; 100个线程达到峰值; 超过100个线程, 写入速度保持在105个左右.
  • 和两个副本相比, 因为一份数据需要保存到三台机器上, 增大了网络和磁盘开销. 导致速度要比两个副本慢.

大文件读取压测

因文件读取耗费大量CPU, 所以使用83测试机, 不让客户端配置成为性能瓶颈.

压测方式: 上传30个100M的文件, 下载时随机选取文件下载.

三个副本, 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
2044.8751.1142106.259
10044.2861.129107.672
20044.41.126107.395

内存占用 free -g:

[root@dfs2 ~]# free -g
              total        used        free      shared  buff/cache   available
Mem:              7           1           2           0           3           5
Swap:             7           0           7

磁盘占用 iostat:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.00    3.00     0.00     0.02    16.00     0.03   10.50    0.00   10.50  10.50   3.15
dm-0              0.00     0.00    0.00    4.00     0.00     0.02    12.00     0.03    7.88    0.00    7.88   7.88   3.15
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.00    6.00     0.00     0.03    10.67     0.06   10.17    0.00   10.17  10.17   6.10
dm-0              0.00     0.00    0.00    6.00     0.00     0.03    10.67     0.06   10.50    0.00   10.50  10.17   6.10
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

系统资源占用 dstat:
image

数据简单分析:

  • 大文件读取, 单个rgw, 最高在107M左右. 从客户端20线程增加到200线程, 读取速度增长不明显.
  • 内存还有足够余量, 磁盘io占用也不高.
  • 从系统资源占用上来看, RGW所在机器网卡接收和发送已经达到114M/s左右, 1000M网卡理论最快速度在 1000M bit/8 = 125M 每秒. 所以可以认为网卡已经跑满, 瓶颈在1000M网卡上.
一个副本, 1个RGW
两个副本, 1个RGW
thread cnttime used(s)write speed(M/s)object speed(obj/s)
2044.6631.119106.763
10043.9321.138108.5398
20043.9611.137108.468

数据简单分析:

  • 数据和三个副本下情况相似. 瓶颈在网卡上.

小文件读取压测

压测方式: 上传100 000个小文件, 下载时随机选取文件下载, 下载100000次.

thread cnttime used(s)write speed(M/s)object speed(obj/s)
2030.4373285.474996.347
10028.1863547.86104.04
20028.5783499.19102.61

rgw机器内存占用情况.

[root@dfs2 ~]# free -g
              total        used        free      shared  buff/cache   available
Mem:              7           1           0           0           6           5
Swap:             7           0           7

rgw机器, 磁盘占用情况

[root@dfs2 ~]# iostat -mdx 2
Linux 3.10.0-327.22.2.el7.x86_64 (dfs2) 	08/29/2016 	_x86_64_	(8 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.01     3.09    1.06   13.40     0.14     0.56    98.73     0.51   35.16    4.11   37.63   7.69  11.13
dm-0              0.00     0.00    1.07   13.96     0.14     0.56    94.99     0.76   50.65    4.26   54.21   7.41  11.13
dm-1              0.00     0.00    0.00    0.04     0.00     0.00     8.05     0.00   21.78    5.51   22.67   0.71   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     5.50    0.00   10.00     0.00     0.08    17.20     0.10   10.40    0.00   10.40  10.40  10.40
dm-0              0.00     0.00    0.00   12.50     0.00     0.08    13.76     0.11    8.56    0.00    8.56   8.32  10.40
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

RGW机器资源占用情况 dstat:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
 18   7  74   0   0   2|   0   108k|  78M  116M|   0     0 |  29k  191k
 18   6  73   0   0   2|   0   116k|  76M  115M|   0     0 |  29k  191k
 18   6  74   0   0   2|   0    48k|  77M  116M|   0     0 |  30k  189k
 18   6  74   0   0   2|   0    36k|  80M  116M|   0     0 |  30k  189

数据简单分析:

  • 小文件读取速度可达每秒100M, 每秒可以读取3500个大约3K的文件. //TODO 内存策略? 这些数据已经缓存到内存中?
  • 从硬件使用情况来看, 读取瓶颈在1000M网口上.

硬盘参数优化, 写入压测(nobarrier)

开启/关闭 xfs nobarrier 参数:

# 开启
mount -o remount,nobarrier {/dev/mapper/cl_bogon-root} {/}
# 关闭
mount -o remount,barrier {/dev/mapper/cl_bogon-root} {/}
压测数据:

副本数为3, index分片为8, 分别在barrier和nobarrier上传文件:

barrier 文件大小30k, 上传5000次
thread cnttime used(s)write speed(M/s)object speed(obj/s)
1225.0180.6522.22
2055.7192.6389.7
10046.4843.154107.56
nobarrier 文件大小30k, 上传5000次
thread cnttime used(s)write speed(M/s)object speed(obj/s)
148.1473.045103.848
2011.23713.0486444.958
1009.96914.708501.55
barrier 文件大小100M, 上传50次
thread cnttime used(s)write speed(M/s)object speed(obj/s)
1223.85921.300.223
5227.56320.9540.2197
20234.08820.370.21359
nobarrier 文件大小100M, 上传50次
thread cnttime used(s)write speed(M/s)object speed(obj/s)
1144.1433.080.3468
5135.58335.1690.3687
20141.8233.620.3525

数据简单分析:

  • 关闭 xfs文件系统 barrier 选项以后, 使小文件写入性能提升5倍左右. 效果非常可观. 100M左右文件, 性能提升为以前的1.65倍左右(网卡还没跑满, 瓶颈在磁盘io).
  • 官方虽然不建议关闭nobarrier选项, 但是我们有数据多机器写入多个副本. 但是存在OSD机器在一个机房, 当遭遇同一机房停电情况, 数据就会损坏的极端情况. 这个视具体情况而定. 如果写入确实是系统瓶颈, 则建议使用nobarrier选项. 也可以临时不使用nobarrier选项, 当达到性能瓶颈以后, 再使用.

压测总结

  1. 100M文件写最高 入单副本 70M/s, 两个副本35M/s, 三个副本20M每秒, 瓶颈在磁盘io. //TODO 进一步分析哪个环节影响效率(文件数据写入/索引写入/日志写入) 这块可以通过加入更多OSD服务器, 升级SSD硬盘来进一步优化.
  2. 30K文件写入在index分片(16个分片)的情况下, 单副本写入每秒能达到160个文件, 两副本最高能达到每秒145个文件写入, 三副本最高能达到每秒 105个文件. 性能瓶颈在磁盘io上. index不分片, 写入index让对应机器磁盘成为瓶颈. 最高在每秒30个文件左右.
  3. 100M文件读取, 1~3个副本, 都能达到 100M/s 的读取速度. 性能瓶颈在1000M网卡上.
  4. 30K文件读取, 1~3个副本, 都能达到100M/s的速度. 性能瓶颈在1000M网卡上. //TODO 这个会对缓存进行清理再测测试.
  5. 测试过程中千兆网络很容易成为系统瓶颈. 在生产部署时, 最好使用万兆网络. 考虑client网络和cluster网络分离(http://docs.ceph.com/docs/master/rados/configuration/network-config-ref/)
  6. 测试过程中, index 副本数设置为1, 没有找到index丢失的情况下(概率低), 从数据文件重建的方法, 建议线上环境设置大于等于2.
  7. 关闭 xfs文件系统 barrier 选项以后, 使文件写入性能提升明显. 如果对写入要求较高的场景, 建议使用nobarrier选项.
  8. 因文件写入瓶颈在磁盘io上, 测试过程中, 还增加OSD 操作线程数, OSD操作硬盘线程数, 小文件写入都没有提升.
  9. 因为测试过程中, RGW部署在OSD服务器上, RGW和同一台机器上的OSD访问网络开销会小很多. 分开部署网络开销会高一些. 网络影响很大.

转载于:https://my.oschina.net/u/1169457/blog/740819

chenglang0914
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Ceph入门到精通-Cosbench压测报错-Client calculated content hash didn‘t match hash calculated by Amazon S3. Th
隔壁老瓦的专栏
05-05 826
【代码】Ceph入门到精通-Cosbench压测报错-Client calculated content hash didn't match hash calculated by Amazon S3. Th。
压力测试
weixin_52295158的博客
12-03 2200
压力测试   压力测试分两种场景：一种是单场景，压一个接口的；第二种是混合场景，多个有关联的接口。压测时间，一般场景都运行10-15分钟。如果是疲劳测试，可以压一天或一周，根据实际情况来定。 压测任务需求的确认 压测前要明确压测功能和压测指标，一般需要确定的几个问题： 固定接口参数进行压测还是进行接口参数随机化压测？ 要求支持多少并发数？ TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？ 压服务器名称还是压服务器IP，一般都是压测指定的服务器 压测设置 线程数：并发数量，能跑多少量。具体说是一次存在
ceph之常用命令
zincooo的博客
08-15 889
处于down状态下的OSD不会从集群的CRUSH MAP中移除，此时还不会进行数据迁移，当执行out操作之后，会从CRUSH MAP删除这个OSD，此时就会进行数据迁移。此时只是对外停止服务，不会改变CRUSH MAP信息，所有上层的访问都会拒绝。获取当前用户已经消耗的配额量，配额的统计数据是异步更新的，可以带上 --sync-stats 参数来获取最新的数据。Bucket配额作用于用户的某一个bucket，通过uid指定用户。最大对象数和最大存储用量的值是负数则表示不启用指定的配额参数。
Ceph性能测试、优化及硬件选型详解|万字长文
NewTyun的博客
12-03 9526
一般基准测试原则基准测试的主要测试案例是：线性读写（大块，长队列），单位MB/sIOPS（每秒输入/输出操作数）中的小块（4-8kb，iodepth=32-128）的高度并行随机读写IO...
第27讲：Ceph存储集群高可用性与性能压测实战
最新发布
江晓龙的博客
06-13 1103
当停掉ceph-node-2节点中的Monitor组件后，集群状态就开始显示WARN了，提示集群中有一个Monitor组件已经宕掉，现在可用的Monitor组件还剩下ceph-node-1和ceph-node-3等节点，并且挂掉的ceph-node-2节点已经不再仲裁节点列表中了，当前在仲裁列表中的节点只剩下了ceph-node-1和ceph-node-3。2）for循环写入数据的同时，停掉ceph-node-2节点的MDS组件，观察MDS主从切换一瞬间，对于数据写入的影响。
Ceph入门到实战
08-15
SDS（英文：Software Define Storage）软件定义存储作为新基建（云计算中基础设施建设）重要的一环，Ceph作为未来统一软件定义存储系统，提供了RBD块存储，RGW对象存储和CephFS文件存储接口的接入，本课程结合在企业实践由浅入深多面剖析Ceph存储，一个分为三篇：基础篇、进阶篇和高阶篇，基础篇介绍Ceph的基础概念，Ceph分布式集群部署，RBD块存储的使用，RGW对象存储使用，CephFS文件存储的使用；进阶篇介绍Ceph运维中常见的操作，包括集群扩容，集群管理，CRUSHMAP定制，RBD快照克隆，RBD增量备份与恢复，RGW高可用集群；高阶篇介绍Ceph和kubernetes集成，Ceph与KVM集成，Ceph与openstack云平台集成，SDK开发等内容。备注：本课程以Ceph官方文档为主，不提供资料下载。【【课程大纲】
使用COSBench工具对ceph s3接口进行压力测试
weixin_33698823的博客
09-05 1121
一、COSBench安装 COSBench是Intel团队基于java开发，对云存储的测试工具，全称是Cloud object Storage Bench 吐槽下，貌似这套工具是intel上海团队开发的，竟然没有中文的相关资料。 同所有的性能测试工具一样，COSBench也分控制台和发起请求的driver，且driver可以分布式部署。可以支持swift、s3、Openstack等接口 1...
浅谈压力测试
mengxiaoqi的专栏
07-21 754
1、压力测试post请求：
ceph压力测试结果
12-13
ceph分布式对象存储测试，常用命令以及ceph操作使用
ceph心跳丢失问题分析
06-12
最近测试了ceph集群承载vm上限的实验，以及在极端压力下的表现，发现在极端大压力下，ceph集群出现osd心跳丢失,osd mark成down, pg从而运行在degrade的状态。分析了根本原因，总结成ppt分享。
ceph-qe-scripts:QE为Ceph测试编写的各种QE脚本
03-29
通过这些脚本，用户可以快速检查Ceph部署的健康状况，进行大规模的压力测试，并且能够有效地发现和解决潜在的问题，提高Ceph系统的整体质量。同时，这些脚本也是开源社区贡献的重要部分，用户可以根据自身需求进行...
ceph安装部署（centos6.6）
02-06
一：简介 1 二：部署环境介绍 1 三：集群配置准备工作 2 四：安装ceph软件包 6 五：安装ceph对象网关 9 六、搭建ceph集群 10 6.1、配置mon节点 10 ...8.1、磁盘压力测试软件推荐 23 九:故障排查 23
ceph常用维护操作文档
03-25
Ceph运维实践,监控及日志管理 Ceph的原理 Ceph常见异常与解决 Ceph压力测试,性能分析和优化
Fio压测工具和io队列深度理解和误区
热门推荐
niepangu的专栏
09-08 1万+
Fio 是个强大的IO压力测试工具，我之前写过不少fio的使用和实践，参见 这里。 随着块设备的发展，特别是SSD盘的出现，设备的并行度越来越高。利用好这些设备，有个诀窍就是提高设备的iodepth, 一把喂给设备更多的IO请求，让电梯算法和设备有机会来安排合并以及内部并行处理，提高总体效率。 应用使用IO通常有二种方式：同步和异步。 同步的IO一次只能发出一个IO请求，等待内核完成才
Ceph性能测试工具和方法
weixin_30697239的博客
07-27 411
前言 本文主要针对Ceph集群进行块设备的性能和压力测试，使用场景可以理解为云平台（Openstack）的计算节点上的各虚机对其云硬盘（ceph rbd存储）进行读写性能测试，采用anssible加自行编写的测试工具（基于fio）的方式实现，整体的结构和场景如下图所示： 使用fio进行rbd块设备性能测试 首先，先来看看Ceph自带的性能测试工具，如rados bench...
Ceph 压测相关整理
dengxiafubi的博客
06-25 1616
１．压测Ceph带宽数据 指的是硬盘或设备(路由器/交换机)在传输数据的时候数据流的速度 (1) 在rbd pool创建一个test块设备，大小为100G，这个大小可以超过pool本身大小，因为是瘦分配． [root@node-1 ~]# rbd create rbd/test2 --size 100G --object-size 4M --image-feature layering -...
第四课 ceph基础学习-RGW高可用集群和集群测试
QnHyn
10-19 1154
RGW高可用和集群测试
ceph压力测试结果总结
weixin_34304013的博客
03-06 422
万兆网速的ceph分布式存储单虚拟机下的带宽和iops测试结果： 　　带宽： 　　　　写：700-850MB 　　　　读：800-900MB 　　iops： 　　　　写：15000-20000 　　　　读：45000-55000 转载于:https://www.cnblogs.com/qfdxxdr/p/8512557.html...
Ceph性能测试工具和方法。
weixin_30709929的博客
08-29 380
0. 测试环境 同 Ceph 的基本操作和常见故障排除方法 一文中的测试环境。 1. 测试准备 1.1 磁盘读写性能 1.1.1 单个 OSD 磁盘写性能，大概 165MB/s。 root@ceph1:~# echo 3 > /proc/sys/vm/drop_caches root@ceph1:~# dd if=/dev/zero of=/var/lib/ceph/o...
ceph io读写测试
05-19
在进行Ceph IO读写测试时，我们通常会使用一些工具来模拟读写操作并收集性能数据，例如： 1. fio：是一种流行的IO基准测试工具，它可以模拟各种读写模式和IO负载，并生成各种性能报告和统计数据。 2. rados bench...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值