@bazingaterry 看具体的项目，有的还在用 govendor，有些升级到 go mod 了。

@liuxu 这个事情比你估计的还复杂一点，读取 smaps，其实是让内核遍历进程的页表，这个操作需要对页表加锁，如果期间出现了 page fault 之类需要修改页表的操作会增加业务延迟。

在监控做这个事情的话，影响会比较大，除非系统在每次 madvise 都更新统计信息 ，每次直接读取这个统计信息，才能降低对业务的影响。

@liuxu 理论上是这样的，但是因为监控链路没有更新，无法区分 [是真的内存要挂了] 还是 [暂时没被回收] ，如果升级了，结果就是，要么不停报警到常态忽略直到某天突然 gg，要么不报警直到某天突然 gg 。

@HangoX 对照了呀，线上都灰度了，应该是正好挑到了 3.16 内核的机器，没踩坑

@fyibmsd 多谢建议，其实我就是讲个故事，加点图故事性更好。

@qieqie 嗯 严谨一点的话应该把这个对照也放出来。不过差别确实很多，否则也不会因为 RSS 报警了。

`man ps` 对 rss 的定义比较粗：

RSS resident set size, the non-swapped physical memory that a task has used (in kiloBytes)

按这个定义，是包含页表中所有已分配、未写到 swap 的内存。

对比下 `man top` ，有更多精细的指标，把内存分成了 4 个象限。

@Gea 面试不会问到这么坑的，关于字节跳动的面试细节，你可以参考我文末我贴的那篇链接

@monsterxx03 提个小建议，如果检测到输出不是 tty （例如重定向到文件）的情况，就不要用 \x1b 做高亮，不然 vim 打开就变这样了：

goroutines:

^[[33m1^[[0m ^[[33mwaiting^[[0m ^[[33m^[[0m ^[[33mmain (/usr/local/go/src/runtime/proc.go:109)^[[0m
^[[33m2^[[0m ^[[33mwaiting^[[0m ^[[33m^[[0m ^[[33mforcegchelper (/usr/local/go/src/runtime/proc.go:240)^[[0m

@superbai 部门相当多，广告，ailab，飞书，基础架构等，我没有完整 list; 这些岗位都有的，文末附的链接(所有职位)你可以点开看一下，我们组这边需要 go 和 python

注：不做某件事情，当然是为了更快

估计 C++规范对 placement new 没有做内存清零的要求，具体做不做就看编译器的实现了。

ref： https://stackoverflow.com/questions/10490191/does-placement-new-zero-out-the-memory

@rrfeng 嗯，老架构，业务快速跑，很多问题就暴露出来了，我们正在重构

@hallDrawnel @ms2008 旧的 Ganglia 、新的 openfalcon+grafana，我们都在用，看场景和习惯

@freefcw 嗯，而且因为 runtime 更新很快，很多知识过期也很快，年纪大了就容易跟不上……

@buffzty 你可以换个视角，大多数人来 v2 不是来学习，是来消遣的。

@buffzty 这是通过少量多次的正反馈提高读者阅读兴趣的一种方法，全都是文字干巴巴的对于大多数人更容易 TLDR 。

这个问题一两百字能不能说得完，取决于读者的情况，release notes 里倒是很简洁，一次就能看懂的有多少呢。

@jonnn 嗯，这个坑有点偏门，我们厂内去年 7 月份就已经有团队踩过了。。。

@saberlong 现场没有了可能是比较难查 ，如果还有现场的话，上面说的 GODEBUG=madvdontneed=1 可以试试。

另外对于很难定位的问题，我还会用尝试删掉无关的逻辑，找到可能会导致问题的最小集。

@mahone3297 对，但是这需要内核提供更精细的数据，以及整个监控链路的相关改造，周期会比较长了。