rclone 同步海量文件时内存占用过高怎么通过 GOGC、--list-cutoff 与 --max-buffer-memory 优化【免费下载链接】rclonersync for cloud storage - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files项目地址: https://gitcode.com/GitHub_Trending/rc/rclone用 rclone 同步目录时如果内存占用持续走高甚至触发 OOM常见原因在 docs/content/faq.md 中有明确说明rclone 用 Go 语言编写并依赖垃圾回收器默认配置下 GC 在堆大小翻倍时才运行而最常见的内存高占用来源是单个目录里包含数百万个文件。下面按文档给出的三个手段——GOGC环境变量、--list-cutoff与--max-buffer-memory参数——给出各自的适用条件和用法最后说明如何核对优化效果。先判断高内存来自哪一部分rclone 的内存占用主要与两部分相关目录列表。v1.70 之前的 rclone 必须把单个大目录的全部条目加载为 rclone 对象每个对象约占 0.5k–1k 内存v1.70 及以后当某个目录的条目数超过--list-cutoff阈值时rclone 会自动把目录条目写入磁盘并在那里排序内存占用显著下降。传输缓冲区。多线程传输大多不额外吃内存但有些后端会文档举的例子是 s3 后端的上传此时--transfers设得越高缓冲区总内存越大。--list-cutoff主要解决前者GOGC是全局收紧 GC 的行为--max-buffer-memory解决后者。如果机器内存紧张、无法确定瓶颈在哪可以先用 docs/content/rc.md 的 pprof 方法见最后一节做一次内存画像再下手。调低 GOGC 让 GC 更频繁工作Go 的 GC 默认在堆大小翻倍后才回收意味着存活数据之上允许堆积一倍的待回收对象。FAQ 给出的调优方式是设置GOGC环境变量为更低的值文档示例为export GOGC20FAQ 对效果的表述是让垃圾回收器更努力地工作以 CPU 占用为代价降低内存大小。也就是说这是一个明确的 CPU/内存权衡不适合在 CPU 已经吃紧的机器上盲目调低。如果你通过 rclone 的远程控制接口rc运行 rclone也可以在运行中调整 GC 目标百分比而无需重启进程rclone rc debug/set-gc-percent gc-percent20docs/content/rc.md 中debug/set-gc-percent的说明该调用触发回收的时机是新分配数据占上次回收后存活数据的比例达到该百分比初始值即启动时GOGC环境变量的值未设置时为 100。注意为了维持内存限制运行时可能实际把这个百分比调得更低负值等效于关闭 GC除非达到内存限制。用 --list-cutoff 控制大目录的排序位置--list-cutoff的完整文档见 docs/content/docs.md要点如下同步时 rclone 在比较前需要排序目录条目。低于阈值默认 1,000,000时条目保存在内存中——文档估算 1,000,000 条目大约需要1GB RAM超过阈值后rclone 把目录条目存到磁盘上排序几乎不占内存这个磁盘排序方式比内存排序效率略低且只适合 bucket 类后端如 s3、b2、azureblob、swift——而这恰恰是最可能在单个目录里有数百万条目的后端。命令在 docs/content/flags.md 中的定义是--list-cutoff int To save memory, sort directory listings on disk above this threshold (default 1000000)使用方式就是在同步命令上显式设置阈值。例如目录规模已知在几十万级别、机器只有几 GB 内存时可以把阈值调低让 rclone 提前改用磁盘排序rclone sync remote:bigbucket/localdir remote:backup:bigbucket \ --list-cutoff 100000反过来说如果目录条目远小于百万条、内存也宽裕保持默认值即可不必为小目录付出磁盘排序的开销。用 --max-buffer-memory 限制多线程传输的缓冲区docs/content/docs.md 对--max-buffer-memory的说明设置后rclone 作为缓冲区分配的内存不超过给定额度不设置、设为0或off则不限制。注意它是SizeSuffix类型2G、512M这类写法都可以该额度覆盖--buffer创建的缓冲区以及多线程传输使用的缓冲区文档指出的矛盾是--transfers越高吞吐越好但部分后端如 s3 上传每个传输都要额外内存--max-buffer-memory让你可以把--transfers放心调大同时让缓冲内存不压垮机器。docs/content/flags.md 中的定义--max-buffer-memory SizeSuffix If set, dont allocate more than this amount of of memory as buffers (default off)多线程上传大文件时的一种典型组合是高并发 缓冲区上限rclone copy localdir remote:bucket:dir \ --transfers 32 \ --max-buffer-memory 2G即允许 32 路并发但缓冲区总量封顶 2G达到上限后 rclone 会自己调度而不是靠你逐个压低--transfers。这个 flag 自 v1.70 引入见 docs/content/changelog.md如果你的 rclone 版本更旧需要升级或改用 FAQ 提到的针对超大同步的 wiki 脚本 workaround。验证优化是否生效文档提供两类核对手段都属于只读检查core/memstats远程调用docs/content/rc.md返回 rclone 进程内存统计文档指出大多数人最关心的三个值HeapAlloc—— rclone 实际在用的内存HeapSys—— rclone 从操作系统获取的内存Sys—— 向 OS 请求的内存总量是虚拟内存可能包含未使用部分。调用示例rclone rc的用法与 docs/content/docs.md 中rclone rc core/bwlimit rate1M示例相同rclone rc core/memstats对比优化前后HeapAlloc的变化即可判断GOGC/--list-cutoff是否起效。heap 画像docs/content/rc.md 的 Debugging memory use 一节。若 rclone 以--rc --rc-no-auth跑在本地默认端口文档提醒非回环地址上不要使用--rc-no-auth先安装 Go然后go tool pprof -text http://localhost:5572/debug/pprof/heap文档给出的输出是示例结果仅用于说明报告格式flat/cum 两列列出占用内存最多的函数不代表你必然得到相同数值-web参数则会在浏览器中打开图形视图。限制与边界磁盘排序的后端范围--list-cutoff触发的磁盘排序only work well for the bucket based backendss3、b2、azureblob、swift 等对非 bucket 后端的大目录效果不保证文档原话如此没有给出其他后端的替代阈值建议。GOGC 的代价调低GOGC是用 CPU 换内存文档未给出通用推荐值20只是示例。版本依赖--list-cutoff的自动磁盘落盘与--max-buffer-memory均从 v1.70 起可用更早版本遇到单目录百万级文件时文档指向 wiki 上的脚本 workaround。如果调低阈值后同步明显变慢这是磁盘排序slightly less efficient的预期表现不是故障。三个手段可以组合使用--list-cutoff解决大目录列表、--max-buffer-memory给多线程缓冲封顶、GOGC作为全局兜底收紧 GC 行为。按上面的验证方式核对HeapAlloc后再决定是否继续调低阈值或 GOGC 值。【免费下载链接】rclonersync for cloud storage - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files项目地址: https://gitcode.com/GitHub_Trending/rc/rclone创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 rclone 同步海量文件时内存占用过高怎么通过 GOGC、--list-cutoff 与 --max-buffer-memory 优化？
rclone 同步海量文件时内存占用过高怎么通过 GOGC、--list-cutoff 与 --max-buffer-memory 优化【免费下载链接】rclonersync for cloud storage - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files项目地址: https://gitcode.com/GitHub_Trending/rc/rclone用 rclone 同步目录时如果内存占用持续走高甚至触发 OOM常见原因在 docs/content/faq.md 中有明确说明rclone 用 Go 语言编写并依赖垃圾回收器默认配置下 GC 在堆大小翻倍时才运行而最常见的内存高占用来源是单个目录里包含数百万个文件。下面按文档给出的三个手段——GOGC环境变量、--list-cutoff与--max-buffer-memory参数——给出各自的适用条件和用法最后说明如何核对优化效果。先判断高内存来自哪一部分rclone 的内存占用主要与两部分相关目录列表。v1.70 之前的 rclone 必须把单个大目录的全部条目加载为 rclone 对象每个对象约占 0.5k–1k 内存v1.70 及以后当某个目录的条目数超过--list-cutoff阈值时rclone 会自动把目录条目写入磁盘并在那里排序内存占用显著下降。传输缓冲区。多线程传输大多不额外吃内存但有些后端会文档举的例子是 s3 后端的上传此时--transfers设得越高缓冲区总内存越大。--list-cutoff主要解决前者GOGC是全局收紧 GC 的行为--max-buffer-memory解决后者。如果机器内存紧张、无法确定瓶颈在哪可以先用 docs/content/rc.md 的 pprof 方法见最后一节做一次内存画像再下手。调低 GOGC 让 GC 更频繁工作Go 的 GC 默认在堆大小翻倍后才回收意味着存活数据之上允许堆积一倍的待回收对象。FAQ 给出的调优方式是设置GOGC环境变量为更低的值文档示例为export GOGC20FAQ 对效果的表述是让垃圾回收器更努力地工作以 CPU 占用为代价降低内存大小。也就是说这是一个明确的 CPU/内存权衡不适合在 CPU 已经吃紧的机器上盲目调低。如果你通过 rclone 的远程控制接口rc运行 rclone也可以在运行中调整 GC 目标百分比而无需重启进程rclone rc debug/set-gc-percent gc-percent20docs/content/rc.md 中debug/set-gc-percent的说明该调用触发回收的时机是新分配数据占上次回收后存活数据的比例达到该百分比初始值即启动时GOGC环境变量的值未设置时为 100。注意为了维持内存限制运行时可能实际把这个百分比调得更低负值等效于关闭 GC除非达到内存限制。用 --list-cutoff 控制大目录的排序位置--list-cutoff的完整文档见 docs/content/docs.md要点如下同步时 rclone 在比较前需要排序目录条目。低于阈值默认 1,000,000时条目保存在内存中——文档估算 1,000,000 条目大约需要1GB RAM超过阈值后rclone 把目录条目存到磁盘上排序几乎不占内存这个磁盘排序方式比内存排序效率略低且只适合 bucket 类后端如 s3、b2、azureblob、swift——而这恰恰是最可能在单个目录里有数百万条目的后端。命令在 docs/content/flags.md 中的定义是--list-cutoff int To save memory, sort directory listings on disk above this threshold (default 1000000)使用方式就是在同步命令上显式设置阈值。例如目录规模已知在几十万级别、机器只有几 GB 内存时可以把阈值调低让 rclone 提前改用磁盘排序rclone sync remote:bigbucket/localdir remote:backup:bigbucket \ --list-cutoff 100000反过来说如果目录条目远小于百万条、内存也宽裕保持默认值即可不必为小目录付出磁盘排序的开销。用 --max-buffer-memory 限制多线程传输的缓冲区docs/content/docs.md 对--max-buffer-memory的说明设置后rclone 作为缓冲区分配的内存不超过给定额度不设置、设为0或off则不限制。注意它是SizeSuffix类型2G、512M这类写法都可以该额度覆盖--buffer创建的缓冲区以及多线程传输使用的缓冲区文档指出的矛盾是--transfers越高吞吐越好但部分后端如 s3 上传每个传输都要额外内存--max-buffer-memory让你可以把--transfers放心调大同时让缓冲内存不压垮机器。docs/content/flags.md 中的定义--max-buffer-memory SizeSuffix If set, dont allocate more than this amount of of memory as buffers (default off)多线程上传大文件时的一种典型组合是高并发 缓冲区上限rclone copy localdir remote:bucket:dir \ --transfers 32 \ --max-buffer-memory 2G即允许 32 路并发但缓冲区总量封顶 2G达到上限后 rclone 会自己调度而不是靠你逐个压低--transfers。这个 flag 自 v1.70 引入见 docs/content/changelog.md如果你的 rclone 版本更旧需要升级或改用 FAQ 提到的针对超大同步的 wiki 脚本 workaround。验证优化是否生效文档提供两类核对手段都属于只读检查core/memstats远程调用docs/content/rc.md返回 rclone 进程内存统计文档指出大多数人最关心的三个值HeapAlloc—— rclone 实际在用的内存HeapSys—— rclone 从操作系统获取的内存Sys—— 向 OS 请求的内存总量是虚拟内存可能包含未使用部分。调用示例rclone rc的用法与 docs/content/docs.md 中rclone rc core/bwlimit rate1M示例相同rclone rc core/memstats对比优化前后HeapAlloc的变化即可判断GOGC/--list-cutoff是否起效。heap 画像docs/content/rc.md 的 Debugging memory use 一节。若 rclone 以--rc --rc-no-auth跑在本地默认端口文档提醒非回环地址上不要使用--rc-no-auth先安装 Go然后go tool pprof -text http://localhost:5572/debug/pprof/heap文档给出的输出是示例结果仅用于说明报告格式flat/cum 两列列出占用内存最多的函数不代表你必然得到相同数值-web参数则会在浏览器中打开图形视图。限制与边界磁盘排序的后端范围--list-cutoff触发的磁盘排序only work well for the bucket based backendss3、b2、azureblob、swift 等对非 bucket 后端的大目录效果不保证文档原话如此没有给出其他后端的替代阈值建议。GOGC 的代价调低GOGC是用 CPU 换内存文档未给出通用推荐值20只是示例。版本依赖--list-cutoff的自动磁盘落盘与--max-buffer-memory均从 v1.70 起可用更早版本遇到单目录百万级文件时文档指向 wiki 上的脚本 workaround。如果调低阈值后同步明显变慢这是磁盘排序slightly less efficient的预期表现不是故障。三个手段可以组合使用--list-cutoff解决大目录列表、--max-buffer-memory给多线程缓冲封顶、GOGC作为全局兜底收紧 GC 行为。按上面的验证方式核对HeapAlloc后再决定是否继续调低阈值或 GOGC 值。【免费下载链接】rclonersync for cloud storage - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files项目地址: https://gitcode.com/GitHub_Trending/rc/rclone创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考