go-sdk
go-sdk copied to clipboard
v7.9.7 上传问题
从v7.9.5升级到最新 v7.9.7 后, 服务频繁OOM, 查看最近SDK源码后,发现新增了 ioutil.ReadAll, 将用户上传的数据一次性读入内存. 针对小文件还好,稍大一点的文件就非常占用内存.原先只需要不到100M内存的服务,现在至少需要1G内存. (而且这个策略还额外造成了整体上传的延时)
感觉明显是一个倒退,如果是为了重试,希望可以把是否重试的开关交给用户选择.
@suconghou 请问你是用什么 API 上传文件的?我们最近确实修改了表单上传的逻辑,将文件内容完整加载到本地内存,表单上传用于 4M 以下小文件,一般不会导致内存不够的问题。大文件推荐使用分片上传,最近也没有什么变更。
@bachue 我们的主要场景是10M - 20M 的高清图片和一些 100M 左右的小视频,之前一直也是用表单上传,运行良好,只升级了一下版本,服务就崩了.
几十兆的东西没必要非得用分片上传,反而更麻烦.
@suconghou v7.9.7 之前的版本中,表单上传在特殊场景存在小问题,为了修复这个问题需要加载表单信息到内存,所以会提高内存峰值。所以如果您 SDK 升级到 v7.9.7,强烈建议使用分片上传。
@YangSen-qn
分片上传没有 类似 PutWithoutSizeWithoutKey 的API呢, 用来替换 formUploader.PutWithoutKey(ctx, &ret, upToken, body, dataLen, &extra)
body 没有可预知的准确大小, key 也要根据hash, mime 生成的.
@suconghou formUploader 上传,如果不知道大小,size 传 -1 即可
@YangSen-qn
这个我知道,我就是这么用的, 现在你们说要改成resumeUploader,但resumeUploader没发现有 PutWithoutSizeWithoutKey 这种上传的API呀. 看清楚上下文问题.
@suconghou 分片上传暂时没有既不设置 key 也不设置 size 的接口,后续会添加。
我们正在构建一个文件上传中间服务,期望以流的形式传输,但看到 ioutil.ReadAll 之后很明显与需求不符,为此替换成文件会多一次磁盘io
感觉你这个对象上传写的不好啊,为啥 formUploader.PutWithoutKey(ctx, &ret, upToken, body, dataLen, &extra),
好难用,不能直接用 storage.NewBucketManager吗?上传对象在创建一个 formUploader,能不能参考下华为的obs写法,我觉得这个写了就很简单。

@opvexe 建议使用新的版本的 github.com/qiniu/go-sdk/v7/storagev2/uploader 的 UploadManager