ossutil上传性能调优 的示例分析

13次阅读
没有评论

今天就跟大家聊聊有关  ossutil 上传性能调优 的示例分析,可能很多人都不太了解,为了让大家更加了解,丸趣 TV 小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

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

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

用户可从这里获取 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 自行设置的默认并发达不到用户的性能需求时,用户可以自行调整该两个选项来升降性能。

–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,网络,进程 / 线程情况

看完上述内容,你们对  ossutil 上传性能调优 的示例分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注丸趣 TV 行业资讯频道,感谢大家的支持。