近期项目引入了 cliet-go watch Pod ,但内存开始非预期地水涨船高。
Watch 的 Pod 数量大概 3.3k 左右,实际内存在 130MB 左右。但是内存涨幅巨大。
观察项 | 引入 watch 前 | 引入 watch 后 | 涨幅 |
---|---|---|---|
ps | 182MB | 825MB | 643MB |
heapSys | 367MB | 755MB | 388MB |
heapInuse | 94MB | 699MB | 605MB |
pprof | 62MB | 369MB | 307MB |
这个我找到社区的一个Issue,大概就是 informer 的 relfector 踩了一个 gogc 的坑,将[]pod
转成[]*pod
时,原来的 slice 无法 gc ,最终导致双倍的 Pod 内存压力。
但是当前现状是,整体 Pod 实际 size 只有 130MB ,双倍也就是 260MB ,加上 Slice 的 buffer 算 300MB ,和 pprof 的涨幅比较吻合(即涨幅 300MB ),但是和 HeapInuse 的涨幅就差太多了,但是从监控上看 RSS 涨幅又与 HeapInuse 的涨幅一致(即涨幅 600MB)。所以又回到了第一个问题。
另外,关于 client-go 这个双倍内存的问题,之前提到的 Issue 里,有个大佬开源了一个工具说解决了这个问题,但我用下来,实际没解决。。。,所以大家是怎么解决的呢?由于 Kubernetes 并不是我在维护,所以升级版本之类的就不可行了。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.