私は約1年間、セロリとrabbitmqでタスクを実行するdebianボックスを持っています。最近、タスクが処理されていないことに気づいたので、システムにログインし、セロリがrabbitmqに接続できないことに気付きました。 rabbitmq-serverを再起動しましたが、セロリはもう不満を言っていませんでしたが、今では新しいタスクを実行していません。奇妙なことは、rabbitmqがCPUとメモリリソースをむさぼり食っていたということです。サーバーを再起動しても問題は解決しません。解決策をオンラインで探すのに数時間費やした後、サーバーを再構築することにしました。
Debian 7.5、rabbitmq 2.8.4、celery 3.1.13(Cipater)で新しいサーバーを再構築しました。セロリが再びrabbitmqに接続できないと不平を言い始めるまで、約1時間ほどすべてが再び美しく働きました!
[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とスワップをゆっくりと引き継いで再び膨張し始めました。
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
PDATE: rabbitmq.comリポジトリから最新バージョンのrabbitmq(3.3.4-1)をインストールすると、問題が解決したようです。もともと、Debianリポジトリからインストールされたもの(2.8.4)がありました。これまでrabbitmq-serverはスムーズに動作しています。問題が再発した場合、この投稿を更新します。
PDATE:残念ながら約24時間後に問題が再発し、rabbitmqがシャットダウンしてプロセスを再起動すると、数分以内に再びシャットダウンするまでリソースが消費されます。
最後に解決策を見つけました。これらの投稿はこれを理解するのに役立ちました。 CPUを大量に消費するEC2のRabbitMQ および 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
を使用して結果の保存をすべて無効にし、これが再び発生しないようにすることでした。
キューをリセットすることもできます:
警告:これはすべてのデータと設定をクリアします!注意して使用してください。
Sudo service rabbitmq-server start
Sudo rabbitmqctl stop_app
Sudo rabbitmqctl reset
Sudo rabbitmqctl start_app
システムが応答しない場合は、再起動後にこれらのコマンドを実行する必要がある場合があります。
セロリが原因でメモリリソースが不足しています。同様の問題が発生し、セロリバックエンドの結果で使用されるキューに問題がありました。
Rabbitmqctl list_queuesコマンドを使用して、存在するキューの数を確認できます。その数が前夜に増える場合は注意してください。その場合は、セロリの使用を確認してください。
セロリについては、同義のイベントが結果を取得していない場合、それらの未使用の結果を保存するためのバックエンドを構成しないでください。
同様の問題が発生しましたが、それは不正なRabbitMQクライアントアプリケーションが原因であることが判明しました。問題は、未処理のエラーのために、不正なアプリケーションがRabbitMQブローカーへの接続を継続的に試行していたことであったようです。クライアントアプリケーションが再起動すると、すべてが正常に戻りました(アプリケーションが誤動作を停止し、無限ループでRabbitMQへの接続試行を停止したため)