主题正文#11 个月前
一个报表转换服务,Pod 的 RSS 会从 300MB 慢慢涨到 1.2GB。先入为主觉得是泄漏,但几次 heap profile 都没有看到持续增长的对象。
后来把注意力放回任务本身:最多四十个并发,每个都要解压一份不小的文件。任务结束后堆会降,进程占用却不会马上还给系统。把并发降到八个以后,稳定在 500MB 左右,吞吐反而没掉多少。
我对 runtime 什么时候归还内存还没完全弄懂,所以不敢说问题已经解释干净。至少这次提醒我,“不是泄漏”也不等于内存配置没问题。
一个报表转换服务,Pod 的 RSS 会从 300MB 慢慢涨到 1.2GB。先入为主觉得是泄漏,但几次 heap profile 都没有看到持续增长的对象。
后来把注意力放回任务本身:最多四十个并发,每个都要解压一份不小的文件。任务结束后堆会降,进程占用却不会马上还给系统。把并发降到八个以后,稳定在 500MB 左右,吞吐反而没掉多少。
我对 runtime 什么时候归还内存还没完全弄懂,所以不敢说问题已经解释干净。至少这次提醒我,“不是泄漏”也不等于内存配置没问题。
C++ 里也经常把 RSS 上涨直接叫泄漏。先把峰值、并发和任务大小对应起来,比盯着一张总内存曲线有用。
建议把并发数和 cgroup 内存画在一张图上。现在稳定不代表永远够,输入文件再变大一倍时还是可能顶上限。