rabbitMQ一些配置上的问题

rabbitMQ的日志插件:
开启日志记录插件（可通过管理界面查看）
rabbitmq-plugins enable rabbitmq_tracing
rabbitmqctl trace_on
打开 trace 会影响消息写入功能，适当打开后请关闭。
安装上面的插件并开启 trace_on 之后，会发现多了两个 exchange：amq.rabbitmq.trace 和 amq.rabbitmq.log，类型均为：topic。
只要订阅这两个主题，就能收到：客户端连接、消息发收等具体信息了。
设置rabbitmq日志级别和路径：vi /etc/rabbitmq/rabbitmq.conf

[

  {rabbit, [{log_levels, [{connection, warning}]}]}

].

也可以这样写成

[

  {rabbit, [{log_levels, [{connection, error}]}]}

].

rabbitMQ日志文件路径设置：vi /etc/rabbitmq/rabbitmq-env.conf

RABBITMQ_LOG_BASE=/vol/pic/log/rabbitmq
ps:默认路径/var/log/rabbitmq

 

 网络分区恢复：http://www.rabbitmq.com/partitions.html
/etc/rabbitmq.config

[

 {rabbit,

  [{tcp_listeners,[5672]},

   {cluster_partition_handling, ignore}]

 }

].

 

rabbitmq节点容量配置：http://www.rabbitmq.com/memory.html
rabbitmqctl set_vm_memory_high_watermark 0.5  // 将rabbitmq占用机器的内存上限改为0.5
可以通过 rabbitmqctl status 查看结果中的　　{vm_memory_high_watermark,0.5}

内存管理
RabbitMQ服务器在启动时会计算系统内存总大小。然后会根据vm_memory_high_watermark参数指定的百分比，进行控制.可通过命令 rabbitmqctl set_vm_memory_high_watermark fraction 动态设置。
        默认下，vm_memory_high_watermark的值为0.4,当RabbitMQ使用的内存超过40%时，系统会阻塞所有连接。一旦警报解除（消息被消费者取走，或者消息被写到硬盘中）,系统重新恢复工作。
    32位系统的单进程内存使用最大为2G,即使系统有10G,那么内存警报线为2G*40%.
    在日志中可以找到内存限制的相关信息
例如 ：/home/data/rabbitmq/log
=INFO REPORT==== 28-Apr-2015::14:11:16 ===
Memory limit set to 3804MB of 7609MB total.
    当vm_memory_high_watermark为0时，不再有内存警报。并且所有的消息发布都将停止。这个方法可用来，如果要禁止消息发布的情况。

磁盘管理 
     在日志中可以找到内存限制的相关信息
        例如 ：/home/data/rabbitmq/log
            =INFO REPORT==== 28-Apr-2015::14:11:16 ===
            Disk free limit set to 50MB
            当RabbitMQ内存使用达到预设值，并且阻塞信息发布前，会尝试把内存中的信息输出到磁盘上。持久化信息和非持久化信息都将被写到磁盘。（持 久化信息一进入队列就会被写到磁盘）
            如果磁盘的预设值为50%，内存预设值默认是0.4，那么就是当内存使用量达到20%时，队列信息会被写到磁盘上。
 可以通过设置 vm_memory_high_watermark_paging_ratio （默认值为0.5）来改变写入磁盘的策略，例如：

[{rabbit, [{vm_memory_high_watermark_paging_ratio, 0.75},          {vm_memory_high_watermark, 0.4}]}].

 

The above configuration starts paging at 30% of memory used, and blocks publishers at 40%.
上面的配置将会在内存全用30%时将队列信息写入到磁盘，阻塞信息发布是在内存使用40%时发生。
    建议vm_memory_high_watermark 不超过50%.

RabbitMQ队列超长导致QueueingConsumerJVM溢出
解决RabbitMQ队列超长QueueingConsumer导致JVM内存溢出的问题
      我们的服务器使用RabbitMQ作为消息中转的容器。某天我怀疑RabbitMQ队列是否都能及时消化。于是用命令查询了下：rabbitmqctl list_vhosts | grep -P ".*\.host" | xargs -i rabbitmqctl list_queues -p {} | grep "queue"。  不查不知道，一查吓一跳：大多数服务器的队列基本上都是空的，但是有些服务器的某个队列竟然有超过500W条的记录。一般RabbitMQ进程占用内存不过100M-200M，这些队列超长的RabbitMQ进程可以占用超过2G的内存。
      显然消息队列的消费者出现了问题。开发查看日志发现作为该队列消费者的Java服务的日志也卡住了，重启服务后（这点做得不对，应该用jstat、jstack进行排查，而不是直接重启）又很快卡住。这时候他才想起来用jstat，通过jstat发现JVM内存都耗尽了，之后进入无尽的Full GC，所以当然不会处理队列消息和输出日志信息了。jstat的输出如下：

--------------------------------------------------------------------------

[root@mail ~]# jstat -gcutil 29389

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  

100.00   0.00 100.00 100.00  59.59   1639    2.963 219078 99272.246 99275.209

--------------------------------------------------------------------------

       使用jmap导出这时候的Java堆栈，命令：jmap -dump:format=b,file=29389.hprof  29389。将得到的dump文件放到MAT（Eclipse Memory Analyzer）里进行分析，发现很明显是QueueingConsumer持有大量对象导致JVM内存溢出，截图如下：    

 上网搜索了下，发现有人遇到了类似的问题：RabbitMQ QueueingConsumer possible memory leak 。解决办法是调用Channel的basicQos方法，设置临时内存中最多保存的消息数。这个数值的设置建议参考 《Some queuing theory: throughput, latency and bandwidth》 权衡决定。
      拍脑袋将basicQos设置为16后重启服务，队列终于开始消化了。用jstat 观察JVM内存使用情况，也没有再出现剧增溢出的现象。
      总结：使用RabbitMQ的时候，一定要合理地设置QoS参数。我感觉RabbitMQ的默认做法其实是很脆弱的，容易导致雪崩。“You have a queue in Rabbit. You have some clients consuming from that queue. If you don't set a QoS setting at all (basic.qos), then Rabbit will push all the queue's messages to the clients as fast as the network and the clients will allow.“。 这样如果由于某些原因，队列中堆积了比较多的消息，就可能导致Comsumer内存溢出卡死，于是发生恶性循环，队列消息不断堆积得不到消化，彻底地悲剧了。

 disk space full问题：
由于RabbitMQ在磁盘上产生数据主要有以下两个因素：
日志，默认路径是：/var/log/rabbitmq
mnesia数据库，默认路径是：/var/lib/rabbitmq/mnesia
所以，可以有以下两种方式解决disk space full的问题：
清理磁盘空间
更改日志和mnesia数据库的位置。通过在rabbitmq-env.conf中添加配置解决，如下

$ cat /etc/rabbitmq/rabbitmq-env.conf
RABBITMQ_MNESIA_BASE=/home/rabbitmq/mnesia
RABBITMQ_LOG_BASE=/home/rabbitmq/logs
ref: http://www.linuxidc.com/Linux/2014-06/103783.htm

 

参考：https://blog.csdn.net/u014308482/article/details/52947590