s3cmd 快速评估RADOSGW的性能
来源:互联网 发布:互联网共享打印机端口 编辑:程序博客网 时间:2024/06/05 20:38
前言
前面介绍了如何使用s3cmd 测试RADOSGW,基本局限在功能测试。近日,有人报CEPH集群 纠删码Pool的S3功能太弱,3节点集群,9个OSD,性能只能达到100MBps左右,因为上传的file大小都在50~100M之间,所以这个值有点低。
客户并没有好的测试手段,用6个Windows客户端,使用CloudBerry拖拽的方式上传object,那集群S3的性能到底如何呢?摆在面前的问题是如何快速的测试RADOSGW的上传性能 100MBps是否合理呢。
我想到了s3cmd这个工具,只要有足够的并发数,不难测试集群的汇聚带宽。
在3个客户端分别连3个存储节点,在客户端上分别执行如下命令:
seq 0 9999 | xargs -I{} -P 40 s3cmd put bean s3://bucket/{}seq 10000 19999 | xargs -I{} -P 40 s3cmd put bean s3://bucket/{}seq 20000 29999 | xargs -I{} -P 40 s3cmd put bean s3://bucket/{}
发现速度很慢:
查看atop信息,系统并不繁忙
磁盘和CPU都没有到达瓶颈,而client到存储节点的网络是万兆,也不是瓶颈,那问题出在哪里呢?
通过strace跟踪一个s3cmd put,看出了端倪,原来上传的buffer是4K。
解决办法
s3cmd 提供了send_chunk和recv_chunk这两个选项,默认都是4096字节。毫无疑问,对于传输几十M甚至上G的文件到s3 bucket,这个buffer太小了。
对于测试上传,我将send_chunk调整成了262144字节(256KB),整体性能立刻显著提升,直到达到系统某项设备达到瓶颈:
性能提升了三倍,从atop的信息来看,磁盘已经到达极限。此外因为纠删码会消耗CPU资源,因此,考虑到存储服务器只有8核,因此,CPU也成为了瓶颈。 注意,设个send_chunk也并非是越大越好,太大的send_chunk会导致s3cmd传输失败而不得不重传,反而降低效率。
其它
另外一个值得关注的问题是每个磁盘150MB以下的速度也值得怀疑,从iostat的avgrq-sz看出,基本都在300(sector)以下,即低于150K。这个问题就不在此处讨论了。
- s3cmd 快速评估RADOSGW的性能
- 分类器的性能评估
- 分类器的性能评估
- 性能评估
- 性能评估
- 性能评估
- 总线架构性能评估--ARM的解决之道
- 如何评估系统的性能是否稳定
- 探索评估cpu性能的方法
- Cross-Validation算法性能的评估
- 评估 Linux on POWER 的性能
- 如何评估系统的性能是否稳定
- 机器学习算法的性能评估
- 图像处理算法的性能评估
- 评估分类器性能的度量
- 如何评估模型的预测性能?
- 3.1. Cross-validation: 评估 estimator 的性能
- 对ceph radosgw的一些理解
- Android WebView加载后有白边框的问题
- 第13章[1]:运算符的重载基本属性
- 批量建立软链接
- android输入框自动顶上去问题解决。
- Hibernate基础知识(7)
- s3cmd 快速评估RADOSGW的性能
- mr项目优化总结
- CTex的基本使用方法
- Hibernate学习笔记1(运行过程)
- swift学习之数组、字典和字符串
- nginx的配置以及参数设置
- css3 animation(loading)
- linux中wget 、apt-get、yum rpm区别
- windows下caffe训练自己的图片前期准备lmdb