V2EX › felix021 的所有回复 › 第 10 页 / 共 43 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 6 7 8 9 10 11 12 13 14 15 ... 43

❮

❯

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@Arnie97 哈哈哈 tag 确实很“灵”

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@tkl 感谢看到结尾，我照顾不到所有人口味，我自己写得开心就行。

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@buffzty 那你觉得写成什么样更好呢？

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@cydian google 搜一下 qr code ascii 有几个提供在线生成的服务。

linux 下也有个 libqrencode3 可以搞这个，google-authenticator 就是用它来生成终端下的 qrcode 的。

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@bitdepth 嗯，对，但是我说的不是 malloc 清空 page 内容，是说 OS 给的 page 是全零的，否则可能会暴露其他进程的数据，有安全风险。

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@sagaxu 对，底下原理都一样的

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@azh7138m 和大佬们相比，感觉写得比较水，不敢去装逼

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@bsidb 对，推荐看那篇 What a C programmer should know about memory，可以搜到中文翻译的版本

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@gemini767 可以了解一下 docker 底层的实现（ cgroup ），严格来说不是共享 kernel

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@Meltdown 会的，一般 api 层的实现都会维护比较复杂的内存管理，找 os
分配和回收开销很大，不会每次都穿透。

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@gemini767 我们这个服务内存要求比较大，目前用的是物理机，正在做架构调整

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@Dreamacro 升级的时候没细看 release notes，估计看了也不知道影响会这么大

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@phpcyy 那看起来是 race runtime 的问题，细节你得看看那个 issue 做了啥

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@phpcyy 我好像看错了你的问题，是说测试环境用了 -race 出现内存异常，但是线上没用 -race 就正常？

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@tt67wq 下次我还是贴图吧。。感觉损失了好多转化（捂脸）

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@egen 当天定位了问题，几个小时吧

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@ysmood 理论上是的，但是这个周期可能很长。

想要监控到这部分内存，需要 Linux 内核采集更多信息，以及更新整个监控方案的相关逻辑。

我注意到有开发者给内核提了个 patch，但是开发者前年过世了，不知道后续情况如何：

mm: add a separate RSS for MADV_FREE pages
https://lore.kernel.org/patchwork/patch/760453/

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@phpcyy 看起来你这个 case 就是多线程竞争共享变量的处理不当导致了内存泄漏，-race 注入了很多代码，会导致性能下降（ race-enabled binaries can use ten times the CPU and memory ），但是可能带来的意外收获是大幅降低了竞争冲突出现的概率。

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@ysmood 其实对于大部分的场景，dontneed 和 free 的差别可能都不会被观测到，我们的场景比较特殊，内存占用比较大，会导致 RSS 太大触发报警。

解决问题，可以使用 go1.12 新增的 GODEBUG=madvdontneed=1 这个环境变量，切回到原来的模式。

监控反应的情况是否“真实”要看怎么定义了。。。这个未回收的页面可以如何体现，确实是个不错的问题

2020 年 4 月 26 日

回复了 felix021 创建的主题 › Go 编程语言 › 踩坑记： go 服务内存暴涨

@pmispig 因为这些页面还没被 OS 回收，所以不会计入到 free 的 buff/cache ；不过如果用 rnutime.MemStats 看应该是能看到被 go runtime 使用的内存没有暴涨

1 ... 6 7 8 9 10 11 12 13 14 15 ... 43

❮

❯