首页 > 其他分享 >Ceph性能测试总结

Ceph性能测试总结

时间:2023-04-25 10:45:05浏览次数:39  
标签:总结 性能 带宽 Ceph IOPS 4K 测试 随机

Ceph性能测试总结

测试目的:

通过对ceph集群块接口常见性能指标进行简单测试,达到以下几个目的:

  1. 了解当前集群配置方案对硬件性能的利用情况;
  2. 验证集群性能计算公式的正确性;
  3. 识别集群性能瓶颈点;
  4. 为后续性能优化提供部分参考;

测试指标:

块接口IOPS,带宽,时延

硬盘性能一般使用以下几个指标对其性能进行描述:

  • IOPS:每秒读/写次数,单位为次(计数)。存储设备的底层驱动类型决定了不同的 IOPS。
  • 带宽:每秒的读写数据量,单位为MB/s。
  • 时延:IO操作的发送时间到接收确认所经过的时间,单位为秒。

ceph提供的3种接口:块,文件和对象接口都是基于rados层进行的包装,通过测试块接口能够将集群的整体性能充分挖掘出来。

测试原则:

  1. 理论上网络带宽是可以远大于磁盘带宽的,但目前OSD节点磁盘密度过高,所需带宽无法满足,这种条件下网络带宽会成为瓶颈,导致集群最大带宽没有参考价值;
  2. 所有的测试结果都建立在同一个条件下:网络带宽未被osd占满,所有磁盘带宽被osd几乎全部占满(100%使用率);
  3. 本次测试是针对ceph有bcache时的性能情况;
  4. 测试结果数据统计方法:多个客户端同时并发时,统计读写带宽和IOPS时计算所有客户端求和结果,读写时延取平均值;
  5. 查看节点上磁盘带宽使用命令iostat -dmx 3,查看节点上网络带宽使用命令sar -n DEV 3

环境信息:

名称 说明 数量/单位
mon节点 mon + mds + mgr + rgw 3
osd节点 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
128GB memory
16 * 2.4TB SAS
4 * 480GB SSD
2个10GE网卡组成一个bond口(public network 和 cluster network共用)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
5
OS CentOS Linux release 7.5.1804
kernel: 4.17.6-1.el7.elrepo.x86_64
bcache ssd与sas按照1比4进行聚合
cache_mode: writeback
ceph luminous v12.2.7 + blustore + 3副本
fio 3.1

集群性能计算公式:

首先需要测试出OSD所使用单盘的各项性能指标,然后按照下面公式推算集群总体性能

  1. 每块SAS磁盘作为一个OSD,有一块SSD磁盘专门跑RocksDB。数据会被直接写入到data分区(裸盘)中,而对象元数据会被写到RocksDB和RocksDB的WAL中,也就是单OSD的写放大系数就变成1;
  2. 假设OSD个数为N;
  3. 假设副本数是M,数据直到写入M个OSD之后才响应,因此对于多副本存储池,写放大系数是M;
  4. 因为ceph软件会损耗CPU资源,也会损耗一些性能,损耗系数定为0.7;
  5. 假设单块SSD的4K随机读IOPS是R,4K随机写IOPS是W,1M顺序写带宽是B。
    在不考虑网络瓶颈和CPU瓶颈的情况下,ceph存储池的性能估算公式是:
  • 4K随机读IOPS = R*N *0.7
  • 4K随机写IOPS = W*N *0.7/(M)
  • 1M顺序写带宽 = B*N *0.7/(M)

测试方法及脚本

  • 创建60个测试卷
for i in {1..60};do rbd create fio_test$i --size 10G; done
  • 对卷进行填充,由于ceph使用了cow机制,如果不填充后面在写数据的时候需要进行空间分配,会影响性能结果
for i in {1..60}; do fio -ioengine=rbd -pool=rbd -rbdname=fio_test$i -clientname=admin -direct=1 -iodepth 256 -thread -rw=write -bs=1m -size=10G -numjobs=1  -runtime=300 -name=mytest; done
  • 准备一个脚本用于在screen内执行一条命令 myscreen.sh
    格式:myscreen.sh <screen_name>
#!/bin/bash
set -x
screen_name=$1
cmd=$2
screen -dmS $screen_name
screen -x -S $screen_name -p 0 -X stuff "$cmd"
screen -x -S $screen_name -p 0 -X stuff $'\n'
  • 通过myscreen.sh同时执行多条fio命令
    示例:同时开启5个fio client,跑4k随机写,卷名字以fio_test开头加客户端序号
for i in {1..5}; do ./myscreen.sh s$i "fio -ioengine=rbd -pool=rbd -rbdname=fio_test$i -clientname=admin -direct=1 -iodepth 256 -thread -rw=randwrite -bs=4k -size=10G -numjobs=1  -runtime=300 -name=mytest"; done

性能测试结果

单盘性能

测试项 IOPS BW(MB/s) AVG_LAT(ms)
4K随机读 4K随机写 64K/1M顺序读 64K/1M顺序写 4K随机读 4K随机写
SSD盘+xfs 67.9k 22.2k 495 409 0.118 0.091
SAS裸盘 1129 749 256 246 4.1 1.3
bcache聚合设备裸盘 72.6k 56.2k 256 243 0.071 0.067

集群性能

测试项 IOPS BW(MB/s) AVG_LAT(ms)
4K随机读 4K随机写 64K/1M顺序读 64K/1M顺序写 4K随机读 4K随机写
集群总性能 116k 88k 4500 1800 0.965 2.541

小结

集群1M顺序读带宽测试:
1M顺序读带宽按照公式应该为 240MB/s * 80 * 0.7 = 13440MB/s
实际测试结果为 4500MB/s,大约为总性能的33%

原因分析:
9个clients同时并发大块读时osd节点资源占用情况如下:
磁盘%util大约40%,
osd节点占用网卡带宽大约900MB/s,通过iperf工具测试bond口带宽为1GB/s,
此时带宽为性能瓶颈,读性能接近网卡带宽的总和900MB/s * 5 = 4500MB/s,符合实际测试结果值。

集群1M顺序写带宽测试:
1M顺序写带宽按照公式应该为 240MB/s * 80 * 0.7 / 3 = 4500MB/s
实际测试结果为 1800MB/s,大约为总性能的40%

原因分析:
3个clients同时并发大块写时osd节点资源占用情况如下:
磁盘%util大约40%,
osd节点占用网卡带宽大约900MB/s,通过iperf工具测试bond口带宽为1GB/s,
此时带宽为性能瓶颈,写性能接近网卡带宽的总和900MB/s * 5 / 3 = 1500MB/s,和实际测试结果值相差不大。

集群4K随机写IOPS测试:
4K随机写IOPS按照公式应该为: 56.2k * 4 * 5 * 0.7 / 3 = 262k

注:4K随机写数据基本能够全部落盘到SSD cache中,
且当cache写满后存在回刷的性能损耗,因此集群4K随机写IOPS的理论计算公式是按照SSD盘的数量20来计算得到

实际测试结果为88k,大约为总性能的33%

原因分析:
8台服务器,每个上面5个clients,同时并发测试4k随机写时osd节点资源占用情况如下:
磁盘%util大约60%
单个client IOPS:2200,集群总IOPS为 2200 * 5 * 8≈88k
fio跑时单节点cpu最大IOPS大约为10k,此时cpu成为瓶颈,如果要将集群IOPS跑满还需要增加client来提高压力

集群4k随机读IOPS测试:
4K随机写IOPS按照公式应该为: 72.6k * 4 * 5 * 0.7 = 1016.4k
实际测试结果为116k,大约为总性能的11%

原因分析:
和4k随机写性能结果类似,cpu为性能瓶颈

综上,当前环境部署方案能够满足常见的性能指标,文件和对象接口由于只部署了1个进程或主备部署,无法将所有磁盘性能发挥到最大,因此对于mds和rgw要考虑在多主的场景下做性能测试,目前社区版本的多mds及多rgw还不够稳定需要持续进行优化;
后续如果业务要求带宽不满足可以通过增加osd节点网络带宽来提升性能;
如果业务要求IOPS不满足可以通过增加节点或提高节点上cpu性能来提升性能;

标签:总结,性能,带宽,Ceph,IOPS,4K,测试,随机
From: https://www.cnblogs.com/xuning-xuning/p/17351917.html

相关文章

  • ceph满盘导致业务停止后的终极补救措施
    ceph满盘导致业务停止后的终极补救措施现象:磁盘满,osd异常此时ceph集群停止业务,且不能执行rbdrmglance/*****命令删除任何文件。解决办法:方法一:调高ceph的满盘比例,比如原值0.95为满盘,现在修改为0.98修改所有ceph节点/etc/ceph/ceph.conf添加monosdfullratio=0.98monosd......
  • 接口测试快速入门1简介
    简介本章介绍应用程序编程接口(APIapplicationprogramminginterface)和API测试。API测试是软件测试活动的一个重要方面(在典型的基于服务的软件开发过程中)。它包括测试应用程序的业务组件,通常表示为API,然后再开发UI。一个微服务处理单一需求的API。什么是API测试?API对应用层进......
  • 离散数学第一部分内容总结
    一、命题逻辑命题:能够判断真假的陈述句称作命题。一个命题的“结果”,称为真值。例:X>Y不是命题,因为无法判断真假。明天会下雨是命题,可以判断真假。(但真值无法确定) 命题变元:命题标识符如仅是表示任意命题的位置标识,就称为命题变元。它是位置标识,不是能判真假的陈述句。......
  • Redis 报错总结一
    Redis报错总结一Invalidargumentduringstartup:Failedtoopenthe.conffile:redis.window.conf【1】cmd运行redis-server.exeredis.windows.conf报错:提示找不到配置文件。加上文件路径:可以启动成功【2】解决办法【2.1】便捷启动1cd到redis安装目录,输入以......
  • 4.24总结
    --基础查询--1.查询多个字段/*1.查询多个字段SELECT字段列表FROM表名;SELECT*FROM表名;--查询所有数据去除重复记录SELECTDISTINCT字段列表FROM表名;3.起别名AS:AS也可以省略*/droptableifexistsstu;CREATETABLEstu(idint,namevarchar(20),......
  • BusTub 通关总结
    Project#0-C++Primer是个前期热身项目,考察对C++的掌握。要求实现一个并发Trie支持的kv存储,存储map到任何类型的value的stringkey。Trie中的每个节点存储一个键的单个字符,并且可以有多个子节点,这些子节点表示不同的可能的下一个字符。当到达一个键的结尾时,将设......
  • 4.24每日总结
       今天是第一阶段验收,王老师说这次的展示的功能比较单一,场景应用的构想也不够完善。今天看到一个组用python写的人脸识别,效果很好,与我们web端相比确实体现了差距。这几天会抓紧时间完善功能和场景应用的问题。......
  • 软件自动化测试初学者忠告
    题外话测试入门很多受过高等教育的大学生经常问要不要去报测试培训班来入门测试。答案是否。高等教育的合格毕业生要具备自学能力,如果你不具备自学能力,要好好地反省一下,为什么自己受了高等教育迷恋于各种入门级别的培训?是没有毅力还是不知道学习方法?没有毅力的话,要自己多看些......
  • SpringSecurity从入门到精通:登录接口代码实现&测试接口
    登录接口代码实现 @RestController @RestControllerpublicclassLoginController{@AutowiredprivateLoginServcieloginServcie;@PostMapping("/user/login")publicResponseResultlogin(@RequestBodyUseruser){returnloginServ......
  • 2020年总结
    时光飞逝,转眼的时间又到了2021年,记得也是去年这个时候写下了,2019年的总结,主要是对测试和开发的一些技术栈的总结,还附有两个xmind图片。今年对以往的过去做一次总结,在2020年这一年中,还是一如既往的坚持博客的编写,今年总共输出了44篇博客,并且在四月份的时候,申请成为博客专家,同时也感......