ceph 压力测试

时间  2019-12-05
标签 ceph 压力 测试 繁體版
原文   原文链接

[TOC]java

ceph 压力测试报告

此文档最新版本地址ios

概述

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

测试环境

网络拓扑结构

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

image

软硬件环境

OSD服务器

服务器 硬件配置 软件配置
DFS2 Intel Core i7-4790@ 3.60GHz 四核八线程 8G DDR3内存 1T 7200转硬盘, 1000M网口 centos 7.2, ceph 10.2.2
DFS3 Intel Core i7-4790@ 3.60GHz 四核八线程 8G DDR3内存 1T 7200转硬盘, 1000M网口 centos 7.2, ceph 10.2.2
DFS4 Intel 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效率高些.app

中等文件写入压测

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

1个副本 1个RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 5|75.731|62.96|0.66 20|65.947|72.306|0.758 50(一条请求超时)|83.37|57.195|0.5997 数据简单分析:性能

  • 最高写入速度也在70 M/s左右.
  • 三台OSD中的两台磁盘io几乎达到100%, 一台在90%左右. 磁盘成为性能瓶颈.
  • 线程数过多(50), 性能不升反降, 还会有超时现象.

2个副本 1个RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 5|139.247|34.2439|0.359 20|147.913|32.237|0.338 50|138.832|34.346|0.360

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

3个副本 1个RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|223.859|21.30|0.223 5|227.563|20.954|0.2197 20|234.088|20.37|0.21359

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

小文件写入压测

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

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

两个副本, 1个RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|52.426|2.796|95.37 100|34.78|4.2158|143.76 200|34.417|4.26|145.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 cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|41.833|3.505|119.523 100|30.929|4.741|161.66 200|40.984|3.577|122

数据简单分析:

  • 系统占用状况和磁盘占用状况和两个副本时类似, 这里省略.
  • 单副本最高文件写入速度在每秒160个左右. 从客户端20个线程到100个线程过程增加明显, 100个线程达到峰值, 从100到200之间有降低趋势.
  • 在200个线程时, 比100个线程速度要降低. 再数据出来之后又测试了屡次, 200个线程通常和100个线程速度持平. 这个数据是一个特例.
  • 和两个副本相比, 由于要一份数据不须要保存两份到不一样机器上, 减小了了网络和磁盘开销. 致使速度要比两个副本快.

三个副本, 1个RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|74.018|1.98|67.55 100|47.283|3.101|105.746 200|45.983|3.1887|108.7

  • 系统占用状况和磁盘占用状况和两个副本时类似, 这里省略.
  • 三个副本状况下, 最高文件写入速度在每秒105个左右. 从客户端20个线程到100个线程过程当中, 增加明显; 100个线程达到峰值; 超过100个线程, 写入速度保持在105个左右.
  • 和两个副本相比, 由于一份数据须要保存到三台机器上, 增大了网络和磁盘开销. 致使速度要比两个副本慢.

大文件读取压测

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

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

三个副本, 1个RGW

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|44.875|1.1142|106.259 100|44.286|1.129|107.672 200|44.4|1.126|107.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 cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|44.663|1.119|106.763 100|43.932|1.138|108.5398 200|43.961|1.137|108.468

数据简单分析:

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

小文件读取压测

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

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 20|30.437|3285.4749|96.347 100|28.186|3547.86|104.04 200|28.578|3499.19|102.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 cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|225.018|0.65|22.22 20| 55.719|2.63|89.7 100|46.484|3.154|107.56

nobarrier 文件大小30k, 上传5000次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|48.147|3.045|103.848 20| 11.237|13.0486|444.958 100|9.969|14.708|501.55

barrier 文件大小100M, 上传50次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|223.859|21.30|0.223 5|227.563|20.954|0.2197 20|234.088|20.37|0.21359

nobarrier 文件大小100M, 上传50次

thread cnt|time used(s)|write speed(M/s)|object speed(obj/s) --|--|--|-- 1|144.14|33.08|0.3468 5|135.583|35.169|0.3687 20|141.82|33.62|0.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访问网络开销会小不少. 分开部署网络开销会高一些. 网络影响很大.
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程