开源版emqx V5.8.6 内存回收问题

EMQX 版本

EMQX 5.8.6

EMQX 安装部署方式

下载二进制安装包安装

EMQX 集群情况

仅单节点

服务器(运行 EMQX 的机器)硬件配置

阿里云8核 16GB

服务器操作系统和平台

debian12, amd64

测试场景

之前接入了44w设备,内存使用了12.8G左右,后面连接数降到了30w,内存还是用到了12G, 后面连接降到12w,内存用到了8G,感觉非常不正常,每次降低连接都持续观察了几小时,没有太大变化

有什么报错么,没有报错就是正常的,erlang申请的内存要不用了,也不会这么快还给操作系统的
ps还有一点,就看你的clean start 是不是false的,如果是,即使设备不在线了,只要mqtt session还没过期,也是会一直有内存占用的。

clean start 是true,没有报错,但有少量的告警,我设置了qos 最大是0,但设备端一些老设备用的qos2,这种告警每分钟可能几百条也不多,别的异常没看到

和阿里云NLB负载均衡有没有关系呢?

没有任何关系

但是我之前内网压力,32G内存可以保存100w在线,云服务器上,远低于这个数。最难受的是44w在线和33w在线,内存波动不到1G,中间间隔2天左右

那建议你可以用置顶的常见问题中的observer_cli工具看看是什么情况

请帮忙看看,目前连接数34.5w,内存占用13G,看起来好像是有大量僵尸连接没有回收掉?需要怎么优化处理呢?

这个显示应该是没有问题的(非常健康)。

  1. Total 是 7.0049G Process 只占用 4.9G
  2. 你看到的内存占用 13G,应该是 erlang 虚拟机在连接数高时以前申请过 13G 的内存,但是他并没有在连接数少的时候还回去(这个内存是不是还给操作系统的机制是自动的,不可以控制的,当然如果你的操作系统的内存不够了,他也会还回去,他就是怕后面还需要再申请,所以就直接没有释放)具体内部细节是 erlang VM 决定的,想了解的话,可以问问 AI,自己探索一下。

里面的 die,这个不是大量僵尸连接的意思,是说这个进程检测时还是活着的,结果下一秒就挂了。就是客户端的连接下一秒的状态就离线了。是正常的。

总结:
要判断内存是不是降下来,就看 observer_cli 的 Total 和 Process 就行了。这个是实际正在使用的,最为准确。至于 alloc 的内存什么时候还回去给操作系统,这个不可控制。

好的,明白了,多谢大佬解惑 :smiley: