emqx相关信息：
版本：5.7.1
开源版、集群部署（3节点）、运行在k8s
客户端（发布者）：
mqtt版本：3.1.1
向主题devices/register/request发布消息
客户端（订阅者）
mqtt版本：3.1.1
订阅$share/g1/devices/register/request这个共享主题
测试流程：
1.并发发布3w条消息
2.启动4个客户端订阅消息（部署在k8s，处理逻辑包含读写mysql）
3.订阅一段时间后，不再订阅了，查看emqx日志，如下：
如何配置mailbox_overflow？后续会有几十万甚至百万的消息
要配置什么 mailbox_overflow？你在哪里看到的文档，方便贴一下么，我没太明白。
疑问点1:
errorContext: connection_shutdown, reason: #{max => 1000,reason => mailbox_overflow,value => 3188}, offender: [{pid,<0.1819025.0>},{name,connection},{mfargs,{emqx_connection,start_link,[#{listener => {tcp,default},limiter => undefined,zone => default,enable_authn => true}]}}]
疑问点2:
[warning] clientid: center-10.244.140.101, msg: socket_error, peername: 10.244.140.101:47856, reason: timeout
目前看来，订阅端消费一段时间的消息后就不再订阅了（emqx管理后台看不到订阅了，处理逻辑也不执行了），应该是上面的2个问题导致的，请问如何解决？
只要在 emqx 管理后台没有看到订阅，那就是没订阅成功，可以先排查一下客户端代码。
一开始是有订阅的，并且订阅端的逻辑也有在执行，随着设备端发布的消息越来越多，就出现了上面贴出来的错误信息，然后订阅的主题就不见了，但是订阅端跟emqx还保持着连接
emqx 不会无故取消订阅的，可以看看是不是设备重连没有发起重新订阅
[warning] msg: busy_dist_port, portinfo: [{port,#Port<0.8>},{name,“tcp_inet”},{links,[<0.2712.0>,<0.2179.0>]},{id,64},{connected,<0.2712.0>},{input,1159826443},{output,174},{os_pid,undefined}], procinfo: [{pid,<0.4284.0>},{memory,29768},{total_heap_size,3358},{heap_size,2586},{stack_size,26},{min_heap_size,233},{proc_lib_initial_call,{emqx_broker,init,[‘Argument__1’]}},{initial_call,{proc_lib,init_p,5}},{current_stacktrace,[{mnesia_tm,async_send_dirty,6,[{file,“mnesia_tm.erl”},{line,2076}]},{mnesia_tm,dirty,2,[{file,“mnesia_tm.erl”},{line,1140}]},{emqx_broker,handle_cast,2,[{file,“emqx_broker.erl”},{line,553}]},{gen_server,try_handle_cast,3,[{file,“gen_server.erl”},{line,1121}]},{gen_server,handle_msg,6,[{file,“gen_server.erl”},{line,1183}]},{proc_lib,init_p_do_apply,3,[{file,“proc_lib.erl”},{line,241}]}]},{registered_name,emqx_broker_32},{status,suspended},{message_queue_len,22},{group_leader,<0.4032.0>},{priority,normal},{trap_exit,false},{reductions,2864959},{last_calls,false},{catchlevel,2},{trace,0},{suspending,},{sequential_trace_token,},{error_handler,error_handler}]
压测发布50w消息的时候，emqx出现这样的告警，是需要优化什么吗？需要怎么进一步处理呢？
这个日志的直接原因是单条 tcp 所收发的消息过于多了。
PS：即使使用共享订阅，一条 tcp 连接每秒能处理的消息也是有上限的。经验值是单条不要超过 3000 QPS。
物理主机配置如下：
emqx集群：开源版、6个节点、5.7.1版本、部署在k8s
客户端发布50w的消息，最大并发是3000，启动40个共享订阅者将消息生产到消息队列，客户端跟emqx集群是内网通信
经多次测试，每次发布消息成功的成功率是87%左右，剩下的都是报了连接emqx超时，报错信息如下：
network Error : dial tcp 172.16.250.224:0->172.16.250.83:31274: i/o timeout
请问是emqx集群因为瞬间的io太大吃不消，导致部分客户端连接不上的吗？可以怎么优化下？
如果最大并发就 3000 QPS，你这配置完全够的，感觉你这配置上 10W QPS 都没问题。
看不出来有什么问题。你的发布客户端有多少个。看系统的负载怎么样？
发布客户端是50w个，一个客户端就发布一条消息，一台机器配了10张网卡，每张网卡发起5w个连接
看系统的负载是均衡的
我也遇到了同样的问题，共享订阅，客户端订阅的主题数到14w左右就会报这个错误，配置是emqx单节点，4核8G
