这个怎么判断qos 2 pending/ACK 增量明显回落呢
发布端用 QoS 1 发布时，客户端最终收到的就是 QoS 1。MQTT 下行 QoS 取“发布 QoS”和“订阅 QoS”的较低值，所以订阅记录是 QoS 2 不会把一条 QoS 1 消息升级成 QoS 2；这批广播不需要去改 250 万客户端的订阅。
如果以后所有消息都只需要 QoS 1，最稳的是客户端对同一 Topic Filter 重新 SUBSCRIBE QoS=1。服务端也能改单个在线客户端：
emqx ctl subscriptions show <ClientId>
emqx ctl subscriptions add <ClientId> <Topic> 1
emqx ctl subscriptions show <ClientId>
但不要这样批量改 250 万连接：客户端重连后再次按 QoS 2 订阅，还会改回去。
建议还是：改客户端订阅配置，或者广播发布端固定用 QoS 1。
判断 pending/ACK 回落时先分清实际下行 QoS。你现在用 QoS 1 发布，就看 QoS 1，不再看 messages.qos2.sent / PUBCOMP：
QoS 1 批次未完成量 ≈ Δmessages.qos1.sent - Δpackets.puback.received
QoS 2 批次未完成量 ≈ Δmessages.qos2.sent - Δpackets.pubcomp.received
这些都是累计计数器。广播前记一次基线，发布后每 2～5 秒采一次，并把所有个节点的数据求和。先只发一个主题，记录未完成量的峰值；等它降到峰值的 5%～10% 以下，并连续 3 次不再上升，再发下一批。业务流量会让这个估算没有那些准，所以不要拿单节点或单次采样判断。
先验证 QoS 1 ： messages.qos1.sent 增量与 packets.puback.received 增量逐步追平，同时 packets.puback.missed、delivery.dropped、tcp_closed 没继续增长。
将qos2降低为qos1 后 没有出现客户端掉线现象了，这不是就能确定是网络带宽不够呢
QoS 1 是 PUBLISH → PUBACK，
QoS 2 是 PUBLISH → PUBREC → PUBREL → PUBCOMP。
降到 QoS 1 ，业务 payload 大小基本没变，但控制报文、未完成状态和等待时间都减少了，所以 busy_port、客户端处理、LB、丢包/重传中的任一瓶颈都会缓解。
再加上前面的 busy_port tcp_inet、90% tcp_closed、whole 慢订阅和 PUBCOMP missed，现在能确定的是 QoS 2 下行确认路径发生了背压，但是不能只归因于网卡带宽。
同一批广播分别用 QoS 1/QoS 2 做对照，所有节点同步抓：
sar -n DEV 1
nstat -az | egrep 'TcpRetransSegs|ListenOverflows|ListenDrops'
emqx ctl broker metrics | egrep 'bytes.sent|messages.qos[12].sent|packets.puback.received|packets.pubcomp.received|packets.pubcomp.missed'
如果故障时网卡 TX 持续接近链路上限，且重传/丢包同步增长，才能判断带宽或网络质量是主因；
如果 TX 没到上限但 ACK 延迟、busy_port、tcp_closed 增长，继续查客户端处理线程、LB、socket 队列和发布 burst。