和EMQX频繁断开连接，其他客户端有订阅5000个的也没有这么频繁断开连接，我这个大概订阅了不到500个设备
这个是4.3.5版本的错误
2022-01-12T16:24:30.491111+08:00 [warning] ZHENGTAI-MQTT-GATHER@39.103.232.179:46576 [MQTT] socket_error: busy
热升级到4.3.11后报错: ZHENGTAI-MQTT-GATHER@39.103.232.179:50712 [MQTT] socket_error: timeout
要么就是 socket_error: error
配置文件没有过多修改
你客户端消费能力不足，就是所有设备端产生的消息，你一个客户端进行消费，一个客户端消费不过来导致tcp层面断开了。跟emqx 本身没关系了。采用共享订阅，增加客户端进行分担消费。或者采用企业版桥接到其他存储上
好的我先试试
再咨询一个问题 Dropped msg due to mqueue is full， 我看到其他帖子中回复是要修改max_inflight 这个值和最大队列值，那这个值修改多少合适呢
最好不要动这个值。消费能力不足，队列最终还是要满的，要解决设备的处理能力
那这个值呢max_mqueue_len默认配置是1000这个是否能调整，调整多少合适，我看别的帖子官方建议是增大
可以调整，没有最合适的值，要根据你的业务逻辑看。还有就是不推荐增加队列长度来解决，设备异常之后队列消息会全丢
这个错误之前也没有出现过，近期才出现，设备现在也就不到500块，按理来说不应该出现这个问题。
按照您的回复，现在的问题就在于，消费端不稳定，频繁断开重连，导致队列中有很多堆积的消息没法处理。我觉得得先处理频繁断开重连的问题，正在导致堆积的原因就是频繁断开重连，如果连接正常的话不应该出现这个问题
追踪一下出问题的设备，定位一下它的业务流程是不是有问题。参考文档，还有就是希望你能贴出来更全的日志，还有平时的业务操作和业务逻辑，你提供的错误信息只有最底层的报错code，没有堆栈也没有其他告警，很难看出来问题
2022-01-13T05:21:02.300542+08:00 [warning] TTTTTTTT@127.0.0.1:36562 [Session] Dropped msg due to mqueue is full: Message(Id= Õi!ȤôC¢m%¸, QoS=1, Topic=/RTG, From=<<“000013258”>>, Flags=[], Headers=#{peerhost => {218,204,253,250}, properties => #{},proto_ver => 4,protocol => mqtt, username => <<"">>}) 目前业务逻辑就是订阅主题后，设备会周期上报，程序端收到数据后应答设备，然后数据入库
如果你的业务上做了消费后的应答，就别用 QoS 1 的消息等级，QoS 1 的消息消耗比较大，你的设备已经消费不掉了
好的，谢谢，我这边更改一下程序端的qos级别，设备端是否重启一下会好点？队列值适当增大一下试试
重启就要丢数据了，做好准备
好的，我程序端 应答qos级别改为0，那么订阅主题的QOS级别需要改为0么，目前是1
订阅没关系，不过最好都是用QoS0
主要是设备端消费的时候，消费到的消息应该是QoS0，这样会减少消耗，但这是发布端控制的
都按照昨天的修改了Dropped msg due to mqueue is full: Message这个错不再报了，现在又开始频繁重连了，而且订阅主题超慢，别的客户端订阅900多个也没有这个问题，很难搞
这就是队列加大的副作用啊，所以不推荐你增大队列。消息，订阅都会堆积在队列里，要增加终端的消费能力
我有一个客户端订阅了5000设备都没问题，唯独这种设备460左右，一直有问题。这个我不知道解释成啥，太难了
