环境
- EMQX 版本：4.2.14
- 操作系统版本：Ubuntu 18.04.5 LTS
emqx日志有报错 maximum heap size reached客户端未被关闭但消息有丢失，请问这个怎么排查？
这个就是客户端消息太多没消息卡住了，累积太多内存大就退出了
意思是客户端消费太慢导致客户端消息堆积在emqx？然后就报错了？我需要怎么解决呢？我看到有设置force_shutdown_policy这个参数比如说10000|64MB但是我不知道emqx的默认大小是多少所以我不懂这个该设置多少合适
这个就是合适的，不用改。你客户端订阅把消息消费完就可以，不用改这个配置
请问这句话是啥意思啊大佬？客户端消息太多没消息卡住了是啥意思看不懂啊
就是消息 publish 没消费的意思，这只是一种可能，你能找到那个客户端么？
我注意到你日志 log 等级是 info，你是不是开了 debug 等级，这个生产最好调成 warning ，
debug 会打卬 payload，如果 payload 过大，也会这样。
日志过多还会严重影响性能，生产务必调成 warning 以上的
您好感谢回复，我有两个问题想咨询,第一个问题:对于“是不是开了 debug 等级，这个生产最好调成 warning ，
debug 会打卬 payload，如果 payload 过大，也会这样“”。这句话是不是可以这样理解：如果日志级别是debug如果payload消息过大因为要日志要输出payload内容就会引起该报错，如果日志改成warning级别哪怕是payload过大，因为日志不需要输出payload内容也不会引起该报错。第二个问题：我消息发送端设置的服务质量（qos）设置为0所以说消息接收方可能也会因为网络波动的原因收不到消息，那对于这种情况是不是我只要把qos设置为1或者2就可以解决因为网络波动导致的消息没被消费的问题？
想排查一下出现这个报错具体是什么原因引起的，可以通过什么措施排查呢？
上面也全是我的经验猜想，你可以详细描述一下出现问题的场景，私信我更全的日志。我看看。方向就是有客户端的消费能力不足了，造成了消息累积。
具体的排查方法见：
里面查 CPU 或内存高的那一段。observer_cli工具。