jemalloc内存统计问题

[shyhc]

我们现在遇到一个问题，mem+cmem的内存要比jmem-mapped小，属于正常范围；但是jmem-mapped比top统计的进程占用res小很多（前者400Mb，后者3g+），想问下大家是否遇到过这类问题，有没有好的排查思路

[t0350]

之前遇到过类似的。是因为 os 的 /sys/kernel/mm/transparent_hugepage/enabled 配置打开了，导致 jemalloc 还给系统后的某些页，被合并成了大页，算到 rss 占用去了。

默认值应该是 [madvise] ，好像某些云厂商会改成 always。

[shyhc]

之前遇到过类似的。是因为 os 的 /sys/kernel/mm/transparent_hugepage/enabled 配置打开了，导致 jemalloc 还给系统后的某些页，被合并成了大页，算到 rss 占用去了。

默认值应该是 [madvise] ，好像某些云厂商会改成 always。

我这边确实是开着的(always)，但是我关掉之后，发现这个问题还是存在

[lvzixun]

之前遇到过类似的。是因为 os 的 /sys/kernel/mm/transparent_hugepage/enabled 配置打开了，导致 jemalloc 还给系统后的某些页，被合并成了大页，算到 rss 占用去了。 默认值应该是 [madvise] ，好像某些云厂商会改成 always。

我这边确实是开着的(always)，但是我关掉之后，发现这个问题还是存在

改成madvise之后 需要重启进程才能生效。

[shyhc]

之前遇到过类似的。是因为 os 的 /sys/kernel/mm/transparent_hugepage/enabled 配置打开了，导致 jemalloc 还给系统后的某些页，被合并成了大页，算到 rss 占用去了。 默认值应该是 [madvise] ，好像某些云厂商会改成 always。

我这边确实是开着的(always)，但是我关掉之后，发现这个问题还是存在

改成madvise之后 需要重启进程才能生效。

我改成never了 重启过系统 确认有修改成功 但是问题还在

[lvzixun]

可能的问题如下：

1. 确认jemalloc统计的VIRT 整个虚拟内存的大小与top查看的VIRT 是否一致，以此确认所有的malloc/free 都被jemalloc管理。
2. 确认jemalloc的decay垃圾回收状态中dirty + muzzy 的内存大小，是否与top中rss相差的数值一致。
3. 确认是否开启了THP，确认下/sys/kernel/mm/transparent_hugepage/enabled 是否是设置的 [madvise] 或者 [never] 而不是 [always] 。 同时通过如下命令: cat /proc/<pid>/smaps | grep AnonHugePages ，确认进程运行中是否存在THP 大页。

---

1. 是排除是否有不被jemalloc管理的内存。
2. 是排除是否有被jemalloc的垃圾回收中的内存。
3. 是排除THP的影响。 从经验上来看， 大概率是3, THP导致的。你可以看下对应进程的smaps数据， 确定进程运行中是否有大页。

[shyhc]

可能的问题如下：

1. 确认jemalloc统计的VIRT 整个虚拟内存的大小与top查看的VIRT 是否一致，以此确认所有的malloc/free 都被jemalloc管理。

2. 确认jemalloc的decay垃圾回收状态中dirty + muzzy 的内存大小，是否与top中rss相差的数值一致。

3. 确认是否开启了THP，确认下/sys/kernel/mm/transparent_hugepage/enabled 是否是设置的 [madvise] 或者 [never] 而不是 [always] 。 同时通过如下命令: cat /proc/<pid>/smaps | grep AnonHugePages ，确认进程运行中是否存在THP 大页。

4. 是排除是否有不被jemalloc管理的内存。

5. 是排除是否有被jemalloc的垃圾回收中的内存。

6. 是排除THP的影响。 从经验上来看， 大概率是3, THP导致的。你可以看下对应进程的smaps数据， 确定进程运行中是否有大页。

1.2 我把jemalloc报告输出到文件，看了下没有特别大的数值 3 之前就查看过AnonHugePages，大小都是0

我描述下我这边的问题表现，麻烦大佬再帮忙看看： 用机器人反复去登录登出，登录时，查看jmem-mapped和top rss，看起来是对应的上的；但登出时，agent都清理退出了（一个玩家一个agent），jmem统计的内存指标也会跟着减少，mem与cmem也没发现有异常大的服务，但top查看的rss下降的幅度很小（表现确实有点像thp大页合并），这个时候查看jmem-mapped比top rss要小很多，最后进程会在多次机器登入登录之后，内存一直上涨直至oom，看起来更像是有内存泄漏

[sniper00]

老哥，趁这个机会，有空测下mimalloc呗，想知道它的数据表现

[t0350]

@shyhc 应该已经排除过非 je 管理的 malloc/free 了？

[shyhc]

@shyhc 应该已经排除过非 je 管理的 malloc/free 了？

开启jemalloc 默认就是jemalloc接管所有的内存分配吧 （malloc调用被hook）

[shyhc]

老哥，趁这个机会，有空测下mimalloc呗，想知道它的数据表现

考虑试试换个内存分配器，之前试过直接用glibc，效果很差

[shyhc]

同步一下，最后确定是本地docker容器的原因（我们机器人在docker容器内，游戏进程在宿主机内），把docker容器转移到其他机器时，jemalloc和top rss的统计就正常了