jemalloc内存统计问题 about skynet HOT 11 CLOSED

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

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

from skynet.

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

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

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

from skynet.

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

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

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

from skynet.

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

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

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

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

from skynet.

可能的问题如下：

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数据， 确定进程运行中是否有大页。

from skynet.

可能的问题如下：

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，看起来更像是有内存泄漏

from skynet.

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

from skynet.

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

from skynet.

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

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

from skynet.

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

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

from skynet.

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

from skynet.