emqx 一直有告警,但服务器资源还很充足

EMQX 版本

emqx 5.0.25

centos7 安装包部署

EMQX 集群情况

2个节点组成集群

服务器(运行 EMQX 的机器)硬件配置

CPU 16核 内存32G

服务器操作系统和平台

centos7



使用资源也不高,但日志在报 Mnesia is overloaded

不是系统整体的负载太大,是单个 MQTT Bridge 连接上的负载太高。
看了你的另一个帖子 使用数据集成功能下的数据桥接出现大批量数据发送失败问题,服务器资源占用不到,但收不完所有消息

可以在集群 A 上多建立几个 MQTT Bridge,把需要桥接到集群 B 的消息通过主题分开,让不同的 Bridge 客户端进行发送,每个 Bridge 负责一部分主题的消息,分摊负载。

我现在分了多个MQTT Bridge连接了,但出现很多已发送未确认以及超期回复,请问这些数量是集群A问题还是集群B的问题?我理解是集群B没有来得急应答吗?如何进一步优化呢?

是集群 B 的问题,它的响应速度不够了。
在集群 B 看起来,集群 A 的这个桥接等同于一个 MQTT 客户端。按照 #4913 截图中的情况看,相当于有一个客户端以 2000msg/s 的速度向它 publish 消息。对于单个连接进程来说,这个速率已经比较高了。我测试过用 loop 网卡单个连接也只能稳定在 8000msg/s 左右。

使用多个 bridge 连接的目的,是让不同的 bridge 发送不同 topic 的消息,来降低每个 bridge 发送消息的速率。需要细化的是主题里面通配符订阅的那一部分。目前看起来和之前一样还是会都发送 gw/data/yum/# ,Bridge 执行速率也没有降下来。

那我给集群A增加连接池,然后集群B再加节点不知是否可以解决问题呢?目前主题是不能拆了,这个定下来后没法修改,影响范围较大,所以想通过加资源或者其它配置来解决不知是否可行?

内网的话可以尝试配置 bridge egress 使用 qos1 或 qos0

bridge egress 这种方式我使用共享订阅,集群B发现也是有数据订阅不全的问题。我分别用客户端向集群A发50条数据,但集群B只订阅到38条。

另外,我发现,集群B订阅集群A的主题是每秒8000左右的数据量才会丢失,目前这种丢失有什么办法避免?

另外我自己做了一个测点,在同样大数据的主题下增加一个主题层级做测试,用工具向集群A发10条消息,而集群B收到只有2条,然后从集群A的日志追踪看到。推到集群B的数量是一致的

bridge egress 使用共享订阅

具体是指什么,是在集群B上添加 mqtt bridge 并从集群A上共享订阅消息?

另外 trace 是追踪的特定 clientid 还是 topic


这是集群B的桥接配置。
trace 追踪的 clientid。