我目前在生产环境中使用RabbitMQ（3.10.25），有3个节点，它包含几个队列：

• 一个经典队列
• 一个仲裁队列（用于处理nservicebus命令- NServiceBus.RabbitMQ包8.0.2）
• 一个仲裁队列“错误”
• 28个nservebus仲裁队列（nsb.v2.delay-level-xx）

经典队列每秒处理2条消息。仲裁队列不执行任何操作。
几个小时后，一个节点仍然稳定（由经典队列使用），其他两个节点的内存使用率很高。已达到水印内存限制。此外，还有很多预分配的未使用内存（似乎不正常，而且还在增加）。表其他是1.2GB以及。（不断增加）
解决这个问题的最佳方法是什么？RabbitMq或NserviceBus是否提供特定的设置？来减少内存的使用？
RabbitMQ提供了一些信息，但尚不清楚需要调整哪些设置作为起点。

**更新1：**写入/同步IO也很高。（以上截图是在一些生产者/消费者连接时创建的。即使没有生产者/消费者，内存消耗也在持续增长。IO屏幕截图为0个生产者/消费者）

**UPDATE 2：**我注意到，其中一个队列nsb.v2.verify-stream-flag-enabled显示“Cluster is in minority”。你能解释一下这是什么意思吗？它是否会导致所描述的内存问题？
**UPDATE 3：**rabbitmqctl报告的内存崩溃。如前所述，allocated_unused 和 other_ets 的值太高。

Total memory used: 3.7986 gb
Calculation strategy: rss
Memory high watermark setting: 0.4 of available memory, computed to: 3.3458 gb
**allocated_unused: 2.4707 gb (65.04 %)
other_ets: 1.2057 gb (31.74 %)**
other_proc: 0.0518 gb (1.36 %)
code: 0.0336 gb (0.89 %)
other_system: 0.0148 gb (0.39 %)
connection_other: 0.0048 gb (0.13 %)
plugins: 0.0043 gb (0.11 %)
quorum_queue_procs: 0.0025 gb (0.07 %)
reserved_unallocated: 0.0024 gb (0.06 %)
binary: 0.002 gb (0.05 %)
atom: 0.0015 gb (0.04 %)
mgmt_db: 0.0012 gb (0.03 %)
metrics: 0.001 gb (0.03 %)
mnesia: 0.0008 gb (0.02 %)
connection_channels: 0.0007 gb (0.02 %)
connection_readers: 0.0004 gb (0.01 %)
connection_writers: 0.0003 gb (0.01 %)
stream_queue_procs: 0.0001 gb (0.0 %)
quorum_ets: 0.0 gb (0.0 %)
msg_index: 0.0 gb (0.0 %)
quorum_queue_dlx_procs: 0.0 gb (0.0 %)
stream_queue_replica_reader_procs: 0.0 gb (0.0 %)
queue_procs: 0.0 gb (0.0 %)
queue_slave_procs: 0.0 gb (0.0 %)
stream_queue_coordinator_procs: 0.0 gb (0.0 %)

**更新4：**顶部进程插件已安装，我注意到下一个项目不断增加的内存使用在顶部ETS表。过了一段时间，它又开始下降并再次上升。节点的内存似乎没有被清理.：

• 名称：rabbit_stream_coordinator
• 所有者名称：ra_coordination_log_ets
• 类型：集合
• 别名：false
• 保护：公共
• 已压缩：假
  **UPDATE 5：**问题似乎是由流队列（由NServiceBus创建）引起的：'nsb_v2_verify-stream-flag-enabled'

rabbit_stream_coordinator: Error while starting replica for nsb_v2_verify-stream-flag-enabled

could not connect osiris to replica.

2023-10-03 07:58:25.972915+00:00 [error] <0.11581.46>   crasher:
2023-10-03 07:58:25.972915+00:00 [error] <0.11581.46>     initial call: osiris_replica_reader:init/1
2023-10-03 07:58:25.972915+00:00 [error] <0.11581.46>     registered_name: []
2023-10-03 07:58:25.972915+00:00 [error] <0.11581.46>     exception exit: connection_refused
2023-10-03 07:58:25.972915+00:00 [error] <0.11581.46>       in function  gen_server:init_it/6 (gen_server.erl, line 835)
2023-10-03 07:58:25.972915+00:00 [error] <0.11581.46>     ancestors: [osiris_replica_reader_sup,osiris_sup,<0.235.0>]

其他日志记录：

2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>   crasher:
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>     initial call: osiris_replica:init/1
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>     registered_name: []
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>     exception error: no case clause matching
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                      {error,
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                       {connection_refused,
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                        {child,undefined,#Ref<0.840260531.4208984066.201970>,
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                         {osiris_replica_reader,start_link,
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                          [#{connection_token =>

2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                             hosts =>

2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                             name =>
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                             reference =>
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                              {resource,

2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                               queue,<<"nsb.v2.verify-stream-flag-enabled">>},

2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                             start_offset => {0,empty},
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                             transport => ssl}]},
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                         temporary,false,5000,worker,
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>                         [osiris_replica_reader]}}}
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>       in function  osiris_replica_reader:start/2 (src/osiris_replica_reader.erl, line 108)
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>       in call from osiris_replica:handle_continue/2 (src/osiris_replica.erl, line 246)
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>       in call from gen_server:try_dispatch/4 (gen_server.erl, line 1123)
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>       in call from gen_server:loop/7 (gen_server.erl, line 865)
2023-10-03 08:29:37.869613+00:00 [error] <0.10360.34>     ancestors: [osiris_server_sup,osiris_sup,<0.235.0>]

一旦我们删除队列，内存使用似乎就稳定了，GC数也下降了。
（更新5已在RabbitMQ 3.11.20和NServiceBus nuget包8.1.3中测试）
重新启动应用程序（使用NServiceBus）后，重新创建“nsb_v2_verify-stream-flag-enabled”，并且follower仍然显示“Cluster in minority”