ossutil上传性能调优

摘要: 经常碰到内部同学或者外部客户问ossutil关于并发上传性能的问题。本文简单描述下ossutil并发上传原理并举例说明。 用户可从这里获取ossutil。 官网:https://help.aliyun.com/document_detail/50452.html代码:https://github.com/aliyun/ossutil 参数 --recursive 上传文件到oss时,如果file_url为目录,则必须指定--recursive选项,否则无需指定--recursive选项。

经常碰到内部同学或者外部客户问ossutil关于并发上传性能的问题。本文简单描述下ossutil并发上传原理并举例说明。

用户可从这里获取ossutil。

官网:https://help.aliyun.com/document_detail/50452.html
代码:https://github.com/aliyun/ossutil

参数
--recursive
上传文件到oss时,如果file_url为目录,则必须指定--recursive选项,否则无需指定--recursive选项。
从oss下载或在oss间拷贝文件时

如果未指定--recursive选项,则认为拷贝单个object,此时请确保src_url精确指定待拷贝的object,如果object不存在,则报错。
如果指定了--recursive选项,ossutil会对src_url进行prefix匹配查找,对这些objects批量拷贝,如果拷贝失败,已经执行的拷贝不会回退。
在进行批量文件上传(或下载、拷贝)时,如果其中某个文件操作失败,ossutil不会退出,而是继续进行其他文件的上传(或下载、拷贝)动作,并将出错文件的错误信息记录到report文件中。成功上传(或下载、拷贝)的文件信息将不会被记录到report文件中。

批量操作出错时终止运行的情况

如果未进入批量文件迭代过程,错误已经发生,则不会产生report文件,ossutil会终止运行。如,用户输入cp命令出错时,不会产生report文件,而是屏幕输出错误并退出。
如果批量操作过程某文件发生的错误为:Bucket不存在、accessKeyID/accessKeySecret错误造成的权限验证非法等错误,ossutil会屏幕输出错误并退出。
report文件名为:ossutil_report_日期_时间.report。report文件是ossutil输出文件的一种,被放置在ossutil的输出目录下,该目录的路径可以用配置文件中的outputDir选项或命令行--output-dir选项指定,如果未指定,会使用默认的输出目录:当前目录下的ossutil_output目录。

ossutil不做report文件的维护工作,请自行查看及清理用户的report文件,避免产生过多的report文件。

并发控制参数
--jobs选项控制多个文件上传/下载/拷贝时,文件间启动的并发数
--parallel控制上传/下载/拷贝大文件时,分片间的并发数。
默认情况下,ossutil会根据文件大小来计算parallel个数(该选项对于小文件不起作用,进行分片上传/下载/拷贝的大文件文件阈值可由--bigfile-threshold选项来控制),当进行批量大文件的上传/下载/拷贝时,实际的并发数为jobs个数乘以parallel个数。该两个选项可由用户调整,当ossutil自行设置的默认并发达不到用户的性能需求时,用户可以自行调整该两个选项来升降性能。

--bigfile-threshold参考详情,请参考ossutil大文件断点续传

--part-size选项
该选项设置大文件分片上传/下载/拷贝时,每个分片的大小。

默认情况下,不需要设置该值,ossutil会根据文件大小自行决定分片大小和分片并发,当用户上传/下载/拷贝性能达不到需求时,或有其他特殊需求时,可以设置这些选项。

如果设置了该选项(分片大小),分片个数为:向上取整(文件大小/分片大小),注意如果--parallel选项值大于分片个数,则多余的parallel不起作用,实际的并发数为分片个数。

如果将part size值设置得过小,可能会影响ossutil文件上传/下载/拷贝的性能,设置得过大,会影响实际起作用的分片并发数,所以请合理设置part size选项值。

性能调优
如果并发数调得太大,由于线程间资源切换及抢夺等,ossutil上传/下载/拷贝性能可能会下降,所以请根据实际的机器情况调整这两个选项的数值,如果要进行压测,可以一开始将两个数值调低,慢慢调大寻找最优值。

如果--jobs选项和--parallel选项值太大,在机器资源有限的情况下,可能会因为网络传输太慢,产生EOF错误,这个时候请适当降低--jobs选项和--parallel选项值。

如果文件数太多大小有不太平均,直接同时使用--jobs=3 --parallel=4进行设定(文件间并发为3,单文件内的并发为4),同时观察MEM, CPU,网络情况,若并未打满网络、占满CPU,则可以继续上调--jobs和--parallel。

真实案例

根据当时客户场景,下载速度大概在265M/s。

案例解析
在默认情况下,因为是多文件下载,所以会同时下载5个文件(version<=1.4.0,文件间的并发数为5)。

因为平均每个文件大小在1.1G,默认会为每个下载的文件开12个线程(单个文件内的并发数为12,在没有设置parallel参数和partsize参数时会根据文件大小计算出)。

那么在客户的环境里ossutil在运行期间至少有5*12= 60 个线程在跑。这么多并发应该会直接打满网卡,CPU应该也很拥挤。建议在并发下载时观察环境CPU,网络,进程/线程情况。

根据客户的截图,建议对每个文件分片100M~200M进行并发,比如设为100M每个分片,这样每个文件下载的并发数就是filesize/partsize。
ossutil cp oss://xxx xxx -r --part-size=102400000

如果文件数太多大小有不太平均,直接同时使用--jobs=3 --parallel=4进行设定(文件间并发为3,单文件内的并发为4)

总的建议就是:jobs * parallel 与CPU核数为1:1,2:1,但不要太大。

进一步解释
不是oss需要多少资源,是每个并发(读取文件,分片,上传等操作)所需的CPU,mem,网络等。

--jobs是多文件间的并发度,默认是5(version <= 1.4.0,之后是3)
--parallel是大文件内部分片并发度,在没有设置parallel参数和partsize参数时会根据文件大小计算出,最大不会超过15(version <= 1.4.0,之后是12)
如果文件数太多大小又不太平均,可以同时使用--jobs=3 --parallel=4进行设定(文件间并发为3,单文件内的并发为4,具体数字根据机器情况调整)
小结
cp默认并发执行,cp大文件用分片并发下载,小文件用put;默认开启CRC校验。
在oss间拷贝文件,目前只支持拷贝object,不支持拷贝未complete的Multipart。
总的建议

jobs * parallel 与CPU核数为1:1,2:1,但不要太大
并发数太多会直接打满网卡,CPU也会拥挤。建议在并发时观察环境CPU,网络,进程/线程情况
Reference
ossutil大文件断点续传

原文链接请添加链接描述

本文为云栖社区原创内容,未经允许不得转载。

原文地址:http://blog.51cto.com/13876536/2156426

时间: 2024-10-10 18:05:52

ossutil上传性能调优的相关文章

盘点linux系统中的12条性能调优命令。

导读 性能调优一直是运维工程师最重要的工作之一,如果您所在的生产环境中遇到了系统响应速度慢,硬盘IO吞吐量异常,数据处理速度低于预期值的情况,又或者如CPU.内存.硬盘.网络等系统资源长期处于耗尽的状态,那么这篇文章将着实的能帮助到你,如果没有也请先收藏起来. 1,hdparm查看硬度读取速度: 命令:hdparm -t /dev/sda5 打印:Timing buffered disk reads: 254 MB in 3.01 seconds = 84.34 MB/sec 说明:能够指定具体

项目总结50:Linux服务器上web项目Java项目性能调优

项目总结50:Linux服务器上web项目Java项目性能调优 最近上线的电商项目,发现非常卡,用户体验非常差,折腾了好久之后,也逐渐找到原因,并针对原因解决方案,先整理总结. 项目基本情况: 1-使用阿里ECS.OSS等一系列相关服务: 2-用户总量1W+,日活量500+ 3-电商项目,有APP.小程序.管理平台三个模块,其中接口150+ 4-项目使用SSM框架: 5-项目tomcat服务,数据库Mysql,Redis放在一个同一个服务器上: 问题表现: 1-接口反应非常慢,导致APP和小程序

性能测试分析与性能调优诊断--史上最全的服务器性能分析监控调优篇

一个系统或者网站在功能开发完成后一般最终都需要部署到服务器上运行,那么服务器的性能监控和分析就显得非常重要了,选用什么配置的服务器.如何对服务器进行调优.如何从服务器监控中发现程序的性能问题. 如何判断服务器的瓶颈在哪里等 就成为了服务器性能监控和分析时重点需要去解决的问题了. 1     服务器的性能监控和分析 1.1      Linux服务器的性能指标监控和分析 1.1.1       通过vmstat深挖服务器的性能问题 1.1.2       如何通过mpstat 分析服务器的性能指标

性能调优攻略

关于性能优化这是一个比较大的话题,在<由12306.cn谈谈网站性能技术>中我从业务和设计上说过一些可用的技术以及那些技术的优缺点,今天,想从一些技术细节上谈谈性能优化,主要是一些代码级别的技术和方法.本文的东西是我的一些经验和知识,并不一定全对,希望大家指正和补充. 在开始这篇文章之前,大家可以移步去看一下酷壳以前发表的<代码优化概要>,这篇文章基本上告诉你--要进行优化,先得找到性能瓶颈! 但是在讲如何定位系统性能瓶劲之前,请让我讲一下系统性能的定义和测试,因为没有这两件事,后

Android界面性能调优手册

转载:https://androidtest.org/android-graphics-performance-pattens/#11 界面是 Android 应用中直接影响用户体验最关键的部分.如果代码实现得不好,界面容易发生卡顿且导致应用占用大量内存. 我司这类做 ROM 的公司更不一样,预装的应用一定要非常流畅,这样给客户或用户的第一感觉就是快.又卡又慢的应用体验,会影响客户或用户对产品的信心和评价,所以不可忽视. 目录 一. Android渲染知识 1.1 绘制原理 1.2 掉帧 1.3

CoreAnimation6-基于定时器的动画和性能调优

基于定时器的动画 定时帧 动画看起来是用来显示一段连续的运动过程,但实际上当在固定位置上展示像素的时候并不能做到这一点.一般来说这种显示都无法做到连续的移动,能做的仅仅是足够快地展示一系列静态图片,只是看起来像是做了运动. 我们之前提到过iOS按照每秒60次刷新屏幕,然后CAAnimation计算出需要展示的新的帧,然后在每次屏幕更新的时候同步绘制上去,CAAnimation最机智的地方在于每次刷新需要展示的时候去计算插值和缓冲. 之前,我们解决了如何自定义缓冲函数,然后根据需要展示的帧的数组来

ASP.NET性能调优

性能调优 最佳实践的核心就是旨在提高网站性能. Excetional Performance团队总结出了一系列可以提高网站速度的方法.可以分为7大类34条.包括内容.服务器.cookie.CSS.Javascrīpt.图片.移动应用等七部分. 其中内容部分一共十条建议: 一.内容部分 尽量减少HTTP请求 减少DNS查找 避免跳转 缓存Ajxa 推迟加载 提前加载 减少DOM元素数量 用域名划分页面内容 使frame数量最少 避免404错误 1.尽量减少HTTP请求次数 终端用户响应的时间中,有

[转载] 性能调优攻略

原文: http://coolshell.cn/articles/7490.html 作为架构工程师, 性能调整是平时经常需要做的工作了, 这篇文章对性能调优方面做了一个很好的综述, 不知道怎么入手的同学们, 赶紧看一下吧 关于性能优化这是一个比较大的话题,在<由12306.cn谈谈网站性能技术>中我从业务和设计上说过一些可用的技术以及那些技术的优缺点,今天,想从一些技术细节上谈谈性能优化,主要是一些代码级别的技术和方法.本文的东西是我的一些经验和知识,并不一定全对,希望大家指正和补充. 在开

apache性能调优(转)

一.总结前一天的学习 在前两天的学习中我们知道.了解并掌握了Web Server结合App Server实现单向Https的这样的一个架构.这个架构是一个非常基础的J2ee工程上线布署时的一种架构.在前两天的教程中,还讲述了Http服务器.App Server的最基本安全配置(包括单向https的实现), 它只是避免了用户可以通过浏览器侵入我们的Web访问器或者能够通过Web浏览器来查询我们的Web目录结构及其目录内的文件与相关内容,这种入侵我们把它称为: Directory traversal