Mosquitto 持久化消息积压导致网关内存耗尽的排查

一次 Mosquitto 持久化消息积压导致网关内存耗尽的排查

某 Orange Pi Zigbee 网关运行一段时间后出现内存紧张。etah-mqtt 服务已经停止，但网关依然卡顿，无法通过停止业务服务恢复内存。

本文记录这次问题的定位过程、根因和最终处理方式。

执行 top 时，网关总内存约 1 GB，可用内存仅约 51 MB，Swap 约 500 MB 几乎耗尽：

text 复制代码

KiB Mem : 1023516 total, 36116 free, 942140 used, 45260 buff/cache
KiB Swap: 511756 total, 32 free, 511724 used, 52392 avail Mem

按 RSS 排序进程后，发现问题不在 etah-mqtt，而在 MQTT Broker：

bash 复制代码

ps -eo pid,ppid,user,comm,rss,vsz,%mem --sort=-rss | head -20

text 复制代码

PID  USER       COMMAND      RSS      %MEM
769  mosquitto  mosquitto    702140   68.6

mosquitto 单进程占用约 686 MB 内存，是 Swap 被耗尽的直接原因。

先重启 Mosquitto：

bash 复制代码

systemctl restart mosquitto
free -h

重启后可用内存恢复到约 678 MB，Swap 使用量也从约 500 MB 降至约 14 MB。这确认了内存压力来自 Mosquitto，而不是系统缓存或 etah-mqtt 残留进程。

继续检查持久化文件：

bash 复制代码

ls -lh /var/lib/mosquitto/mosquitto.db

结果如下：

text 复制代码

-rw------- 1 mosquitto mosquitto 921M mosquitto.db

Mosquitto 开启了持久化：

conf 复制代码

persistence true
persistence_location /var/lib/mosquitto/

mosquitto.db 会保存持久客户端会话、离线 QoS 消息和 Retain 保留消息。数据库增长到约 921 MB 后，Mosquitto 在运行或重启加载数据时占用了大量内存，最终导致网关物理内存和 Swap 耗尽。

网关还配置了同一主题的双向 QoS 1 桥接：

conf 复制代码

topic zigbee2mqtt/# out 1
topic zigbee2mqtt/# in  1

该配置本身不必然导致问题，但在上游不可用、客户端离线、消息高频或桥接消息回流时，会增加 QoS 消息积压和持久化数据增长的风险。

停止 Mosquitto 后直接清除旧数据库，再启动服务：

bash 复制代码

systemctl stop mosquitto
rm -f /var/lib/mosquitto/mosquitto.db
systemctl start mosquitto

该操作会清除以下历史数据：

生产环境更推荐先移动文件而非直接删除，确认业务正常后再清理备份：

bash 复制代码

systemctl stop mosquitto
mv /var/lib/mosquitto/mosquitto.db \
  /var/lib/mosquitto/mosquitto.db.bak-$(date +%F-%H%M%S)
systemctl start mosquitto

不建议仅为避免文件增长而关闭持久化。对于设备离线后仍需补发 QoS 消息、保留设备最后状态或恢复客户端会话的场景，persistence true 仍然有必要。

本次在 Mosquitto 配置中加入以下两项：

conf 复制代码

max_queued_messages 50
message_size_limit 262144

修改后重启并确认服务正常：

bash 复制代码

systemctl restart mosquitto
systemctl status mosquitto --no-pager

定期监控持久化数据库和 Broker 内存：

bash 复制代码

du -h /var/lib/mosquitto/mosquitto.db
ps -eo pid,user,comm,rss,%mem --sort=-rss | head -10
free -h

本次问题并非普通的 Linux 缓存占用，而是 Mosquitto 持久化数据库过大，导致 Broker 占用大量物理内存和 Swap。短期通过重启释放内存，最终通过清除历史数据库并限制每个客户端的队列数量、单条消息大小恢复稳定。持久化可以保留，但需要持续限制积压来源并监控数据库增长。