目前我的的场景是这样的：
我们的设备的人脸设备，然后我们是同时操作100台设备，每台设备下发500人。
问题是：
通过日志查询出现部分设备发送心跳ping包超时的情况
通过查看emqx的日志是
想知道一般设备出现心跳ping包超时的情况是什么情况引起的，我们要如何排查对应的问题。对应的emqx也没有具体的日志
这个 keepalive_timeout 是说 MQTT 的保活机制超时，即设备没有在规定的时间内上报 PINGREQ 。在移动网路环境下，这是一个常见的现象，你可以将设备测的 Keepalive 设置小一些，让设备保持稍微高一点的保活频率。一般情况设置 30s 比较合适。
目前设置的是60s了。我想了解的是引起设备端发送pingreq包超时的原因有哪些情况引起的
60s 问题也不大。
- 比如客户端跟服务器之间的网络断了，但 emqx 一侧无法知道这个情况，因为服务端的 TCP 协议栈没有收到 FIN，这时候就会出现保活超时。
- 另外如果客户端出现了某些问题，比如忙于处理某些任务而耽误了发送 PINGREQ，也会出现这种问题。
在互联网的环境下，永远也不要假设tcp的连接是长期保持连接状态的。
实际的情形是：随时可能因为偶然的网路问题而断开。
但你可以在断开的时候尽早知道那个设备断开了，然后再自动连线，然后系统也能够知道哪个设备又上线了。
这些就够了.
有没有可能是设备端那边的pingreq包已经发出来了，但是因为emqx的消息堆积导致emqx处理不过来而导致超时呢
断开是正常的，但是这种情况设备断开后，设备本身是无感的，所以它没有重新发起重连，导致离线
"设备无感"是设备端firmware的问题，如果设备发出pingreq 在有限的时间内（例如3秒内）没有收到对应的pingresp 包，则应该认为连接已经断开了。
不会的，因为 emqx 还能正常的处理 PINGREQ 超时的逻辑，所以它并不忙。你可以观察 emqx 的 CPU 使用率。
过去 1min/5mins/15mins 的系统负载。