【问题标题】:RabbitMQ (beam.smp) and high CPU/memory load issueRabbitMQ (beam.smp) 和高 CPU/内存负载问题
【发布时间】:2014-09-29 12:17:56
【问题描述】:

我有一个使用 celery 和 rabbitmq 运行任务的 debian box 大约一年。最近我注意到没有处理任务,所以我登录系统并注意到 celery 无法连接到 rabbitmq。我重新启动了 rabbitmq-server,即使 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) 似乎问题已解决。最初我从 Debian 存储库安装了一个(2.8.4)。到目前为止,rabbitmq-server 工作顺利。如果问题再次出现,我会更新这篇文章。

更新: 不幸的是,大约 24 小时后,问题再次出现,rabbitmq 关闭并重新启动进程会使其消耗资源,直到它在几分钟内再次关闭。

【问题讨论】:

  • 我今天遇到了这个问题,结果证明我们的(单例)RabbitMQ 实例已经用尽了 EC2 上的突增限额。我想我会提到它可能会帮助其他登陆此页面的人。

标签: erlang debian rabbitmq celery mnesia


【解决方案1】:

我终于找到了解决方案。这些帖子有助于解决这个问题。 RabbitMQ on EC2 Consuming Tons of CPUhttps://serverfault.com/questions/337982/how-do-i-restart-rabbitmq-after-switching-machines

所发生的事情是,rabbitmq 一直保留着所有从未释放到过载的结果。我清除了/var/lib/rabbitmq/mnesia/rabbit/ 中的所有陈旧数据,重新启动了rabbit,它现在工作正常。

我的解决方案是在 Celery 配置文件中禁用与 CELERY_IGNORE_RESULT = True 一起存储结果,以确保不会再次发生这种情况。

【讨论】:

  • 如果我不使用 celery,如何停止rabbitmq 的高负载问题。有什么想法吗?
【解决方案2】:

你也可以重置队列:

警告这会清除所有数据和配置!谨慎使用。

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

如果您的系统没有响应,您可能需要在重新启动后立即运行这些命令。

【讨论】:

  • rabbitmqctl reset 破坏配置和数据!我不得不假设你不知道这一点,因为在没有这个警告的情况下提出这样的建议是很鲁莽的:(
【解决方案3】:

你因为 celery 耗尽了内存资源,我遇到了类似的问题,这是 celery 后端结果使用的队列有问题。

您可以使用 rabbitmqctl list_queues 命令检查有多少队列,如果该数字永远增长,请注意。在这种情况下,请检查您的芹菜用途。

关于 celery,如果您没有以异步事件的形式获得结果,请不要配置后端来存储那些未使用的结果。

【讨论】:

  • 谢谢,我昨天想通了。我在我的 celeryconfig.py 中添加了 CELERY_IGNORE_RESULT = True ,从你所说的不指定后端也可以解决问题。如果需要结果,好的方法是使用数据库(mongo、redis)作为后端。
【解决方案4】:

我遇到了类似的问题,结果证明是由于一些流氓 RabbitMQ 客户端应用程序造成的。 问题似乎是由于一些未处理的错误,流氓应用程序不断尝试与 RabbitMQ 代理建立连接。 重新启动客户端应用程序后,一切都恢复正常(因为应用程序停止了故障,并且停止尝试在无限循环中建立与 RabbitMQ 的连接)

【讨论】:

  • 你救了我的命!
【解决方案5】:

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

我正在运行启用了管理插件的 RabbitMQ 3.8.1。 在 10 核服务器上,我的 CPU 使用率高达 1000%,有 3 个空闲消费者,没有发送一条消息,还有一个队列。

当我通过执行 rabbitmq-plugins disable rabbitmq_management 禁用管理插件时,使用率下降到 0%,偶尔达到 200%。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-04
    • 2021-04-19
    • 2014-03-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多