今天就跟大家聊聊有关 ossutil上传性能调优 的示例分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
在新化等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供做网站、网站设计 网站设计制作按需求定制开发,公司网站建设,企业网站建设,高端网站设计,全网整合营销推广,外贸网站制作,新化网站建设费用合理。
摘要： 经常碰到内部同学或者外部客户问ossutil关于并发上传性能的问题。本文简单描述下ossutil并发上传原理并举例说明。 用户可从这里获取ossutil。 参数 --recursive 上传文件到oss时，如果file_url为目录，则必须指定--recursive选项，否则无需指定--recursive选项。
经常碰到内部同学或者外部客户问ossutil关于并发上传性能的问题。本文简单描述下ossutil并发上传原理并举例说明。
用户可从这里获取ossutil。
上传文件到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自行设置的默认并发达不到用户的性能需求时，用户可以自行调整该两个选项来升降性能。
该选项设置大文件分片上传/下载/拷贝时，每个分片的大小。
默认情况下，不需要设置该值，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。
cdn.com/d05c9a5264819e0ef373602d64f5392f1d0e462d.png">
根据当时客户场景，下载速度大概在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，网络，进程/线程情况
看完上述内容，你们对 ossutil上传性能调优 的示例分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
