logo标签列表

RabbitMQ（beam.smp）和高CPU /内存负载问题

erlangdebianrabbitmqcelerymnesia
60

我有一台安装了Debian操作系统的电脑，运行着使用Celery和RabbitMQ技术栈的任务已经有一年时间了。最近我注意到任务没有被处理，于是我登录到了系统中并发现Celery无法连接RabbitMQ。我重新启动了RabbitMQ服务器，虽然Celery不再报错，但它现在无法执行新的任务。奇怪的是，RabbitMQ却像疯了一样消耗着CPU和内存资源。重启服务器无法解决问题。在花费几个小时在线寻找解决方案后，我决定重建服务器。

我使用Debian 7.5、RabbitMQ 2.8.4和Celery 3.1.13 (Cipater)重新构建了新服务器。大约一两个小时后，一切都恢复了正常，直到Celery再次抱怨它无法连接到RabbitMQ！

[2014-08-06 05:17:21,036: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**@127.0.0.1:5672//: [Errno 111] Connection refused.
Trying again in 6.00 seconds...
我重新启动了rabbitmq service rabbitmq-server start，但仍然遇到同样的问题：
rabbitmq再次启动后，不断地膨胀并持续占用CPU资源，逐渐占据了所有RAM和swap。
PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
21823 rabbitmq  20   0  908m 488m 3900 S 731.2 49.4   9:44.74 beam.smp

这是 rabbitmqctl status 的结果：

Status of node 'rabbit@li370-61' ...
[{pid,21823},
 {running_applications,[{rabbit,"RabbitMQ","2.8.4"},
                        {os_mon,"CPO  CXC 138 46","2.2.9"},
                        {sasl,"SASL  CXC 138 11","2.2.1"},
                        {mnesia,"MNESIA  CXC 138 12","4.7"},
                        {stdlib,"ERTS  CXC 138 10","1.18.1"},
                        {kernel,"ERTS  CXC 138 10","2.15.1"}]},
 {os,{unix,linux}},
 {erlang_version,"Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:30] [kernel-poll:true]\n"},
 {memory,[{total,489341272},
          {processes,462841967},
          {processes_used,462685207},
          {system,26499305},
          {atom,504409},
          {atom_used,473810},
          {binary,98752},
          {code,11874771},
          {ets,6695040}]},
 {vm_memory_high_watermark,0.3999999992280962},
 {vm_memory_limit,414559436},
 {disk_free_limit,1000000000},
 {disk_free,48346546176},
 {file_descriptors,[{total_limit,924},
                    {total_used,924},
                    {sockets_limit,829},
                    {sockets_used,3}]},
 {processes,[{limit,1048576},{used,1354}]},
 {run_queue,0},

/var/log/rabbitmq的一些记录：

=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
                                                                write_threshold}

=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
                                                                write_threshold}

=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
                                                                write_threshold}

=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
                                                                write_threshold}

=WARNING REPORT==== 8-Aug-2014::00:11:36 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
                                                                write_threshold}

=INFO REPORT==== 8-Aug-2014::00:11:36 ===
vm_memory_high_watermark set. Memory used:422283840 allowed:414559436

=WARNING REPORT==== 8-Aug-2014::00:11:36 ===
memory resource limit alarm set on node 'rabbit@li370-61'.

**********************************************************
*** Publishers will be blocked until this alarm clears ***
**********************************************************

=INFO REPORT==== 8-Aug-2014::00:11:43 ===
started TCP Listener on [::]:5672

=INFO REPORT==== 8-Aug-2014::00:11:44 ===
vm_memory_high_watermark clear. Memory used:290424384 allowed:414559436

=WARNING REPORT==== 8-Aug-2014::00:11:44 ===
memory resource limit alarm cleared on node 'rabbit@li370-61'

=INFO REPORT==== 8-Aug-2014::00:11:59 ===
vm_memory_high_watermark set. Memory used:414584504 allowed:414559436

=WARNING REPORT==== 8-Aug-2014::00:11:59 ===
memory resource limit alarm set on node 'rabbit@li370-61'.

**********************************************************
*** Publishers will be blocked until this alarm clears ***
**********************************************************

=INFO REPORT==== 8-Aug-2014::00:12:00 ===
vm_memory_high_watermark clear. Memory used:411143496 allowed:414559436

=WARNING REPORT==== 8-Aug-2014::00:12:00 ===
memory resource limit alarm cleared on node 'rabbit@li370-61'

=INFO REPORT==== 8-Aug-2014::00:12:01 ===
vm_memory_high_watermark set. Memory used:415563120 allowed:414559436

=WARNING REPORT==== 8-Aug-2014::00:12:01 ===
memory resource limit alarm set on node 'rabbit@li370-61'.

**********************************************************
*** Publishers will be blocked until this alarm clears ***
**********************************************************

=INFO REPORT==== 8-Aug-2014::00:12:07 ===
Server startup complete; 0 plugins started.

=ERROR REPORT==== 8-Aug-2014::00:15:32 ===
** Generic server rabbit_disk_monitor terminating 
** Last message in was update
** When Server state == {state,"/var/lib/rabbitmq/mnesia/rabbit@li370-61",
                               50000000,46946492416,100,10000,
                               #Ref<0.0.1.79456>,false}
** Reason for termination == 
** {unparseable,[]}

=INFO REPORT==== 8-Aug-2014::00:15:37 ===
Disk free limit set to 50MB

=ERROR REPORT==== 8-Aug-2014::00:16:03 ===
** Generic server rabbit_disk_monitor terminating 
** Last message in was update
** When Server state == {state,"/var/lib/rabbitmq/mnesia/rabbit@li370-61",
                               50000000,46946426880,100,10000,
                               #Ref<0.0.1.80930>,false}
** Reason for termination == 
** {unparseable,[]}

=INFO REPORT==== 8-Aug-2014::00:16:05 ===
Disk free limit set to 50MB

更新： 当我从rabbitmq.com存储库安装最新版本的rabbitmq（3.3.4-1）时，问题似乎已得到解决。最初我安装了一个（2.8.4）来自Debian存储库的版本。目前，rabbitmq-server运行顺畅。如果问题再次出现，我会更新此帖子。

更新： 不幸的是，大约24小时后，问题再次出现，其中rabbitmq关闭，并重新启动进程会导致其占用资源，直到在几分钟内再次关闭。

1
今天我遇到了这个问题，结果发现我们的（单例）RabbitMQ实例在EC2上已经用尽了其突发配额。我想提一下，因为它可能会帮助到其他人来到这个页面。 - MattDavey
5个回答
49

最终我找到了解决方案。这些帖子帮助我弄清楚。 RabbitMQ on EC2 Consuming Tons of CPU 和 https://serverfault.com/questions/337982/how-do-i-restart-rabbitmq-after-switching-machines

发生的事情是rabbitmq一直持有从未被释放的所有结果数据，导致它超载了。我清除了/var/lib/rabbitmq/mnesia/rabbit/中的所有过期数据，重新启动了rabbit后，它现在正常工作。

我的解决方案是在Celery配置文件中使用CELERY_IGNORE_RESULT = True来禁用存储结果，以确保不会再次发生。

9
如果我没有使用celery，如何解决rabbitmq的高负载问题？有什么想法吗？ - Akshay Hazari
5

您也可以重置队列：

警告：这将清除所有数据和配置！请谨慎使用。

sudo service rabbitmq-server start
sudo rabbitmqctl stop_app
sudo rabbitmqctl reset
sudo rabbitmqctl start_app

如果您的系统无响应，可能需要在重新启动后立即运行这些命令。
21
rabbitmqctl reset 命令会删除配置和数据！我得假设你不知道这一点，因为否则你就太鲁莽了，不带任何警告就建议使用该命令 :( - RubyTuesdayDONO
3

由于celery，您的内存资源不足。我遇到了类似的问题，这是由于celery后端结果使用的队列出现问题。

您可以使用rabbitmqctl list_queues命令检查有多少个队列，如果该数字不断增长，请注意检查您的celery使用情况。

关于celery，如果您没有将结果配置为异步事件，则不要配置后端以存储那些未使用的结果。

3
谢谢，我昨天已经想通了。我在我的celeryconfig.py中添加了CELERY_IGNORE_RESULT = True，根据你的说法，不指定后端也可以起作用。如果需要结果，好的方法是使用数据库（mongo，redis）作为后端。 - marcin_koss
2

我曾遇到类似的问题，后来发现是由于一些不良的RabbitMQ客户端应用程序引起的。 问题似乎是由于某个未处理的错误，不良程序一直在尝试连接到RabbitMQ代理。 一旦重新启动客户端应用程序，一切就恢复正常了（因为应用程序停止故障，并因此停止尝试无限循环地连接到RabbitMQ）。

1

另一个可能的原因是管理插件。

我正在运行启用了管理插件的RabbitMQ 3.8.1。在一个10核服务器上，即使有3个空闲消费者和没有任何消息被发送以及只有一个队列时，CPU使用率也高达1000％。

当我通过执行rabbitmq-plugins disable rabbitmq_management禁用管理插件时，使用率降至0％，偶尔会出现200％的峰值。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接