4

メッセージブローカーとしてRabbitMQを使用して、DjangoアプリでCeleryを実行しています。しかし、RabbitMQ はこのように壊れ続けています。まず、Django からのエラーです。後でわかるように、エラーの原因がわかっているため、トレースはほとんど重要ではありません。

Traceback (most recent call last):

  ...

  File "/usr/local/lib/python2.6/dist-packages/amqplib/client_0_8/transport.py", line 85, in __init__
    raise socket.error, msg

error: [Errno 111] Connection refused

これは、 rabbit_persister.logファイルの破損が原因であることはわかっています。これは、RabbitMQ に関連付けられているすべてのプロセスを強制終了した後、「sudo rabbitmq-server start」を実行して次のクラッシュが発生するためです。

...

starting queue recovery                                               ...done
starting persister                                                    ...BOOT ERROR: FAILED
Reason: {{badmatch,{error,{{{badmatch,eof},
                            [{rabbit_persister,internal_load_snapshot,2},
                             {rabbit_persister,init,1},
                             {gen_server,init_it,6},
                             {proc_lib,init_p_do_apply,3}]},
                           {child,undefined,rabbit_persister,
                                  {rabbit_persister,start_link,[]},
                                  transient,100,worker,
                                  [rabbit_persister]}}}},
         [{rabbit_sup,start_child,2},
          {rabbit,'-run_boot_step/1-lc$^1/1-1-',1},
          {rabbit,run_boot_step,1},
          {rabbit,'-start/2-lc$^0/1-0-',1},
          {rabbit,start,2},
          {application_master,start_it_old,4}]}
Erlang has closed

私の現在の修正:これが発生するたびに、対応する rabbit_persister.log ファイルの名前を別のもの (rabbit_persister.log.bak) に変更し、RabbitMQ を正常に再起動できます。しかし、問題は発生し続けており、その理由はわかりません。何か案は？

また、免責事項として、私は Erlang の経験がありません。Celery が好むブローカーであるため、RabbitMQ のみを使用しています。

前もって感謝します。同じ修正を何度も繰り返しているため、この問題は本当に厄介です。

4

2 に答える 2

4

パーシスターは、R​​abbitMQの内部メッセージデータベースです。その「ログ」はおそらくデータベースログのようなものであり、それを削除するとメッセージが失われます。汚れたブローカーのシャットダウンによって破損していると思いますが、それは少し問題があります。

rabbit_persisterモジュールでエラーが発生しているのは興味深いことです。そのファイルを含むRabbitMQの最後のバージョンは2.2.0なので、アップグレードすることを強くお勧めします。最良のバージョンは常に最新であり、RabbitMQAPTリポジトリを使用して取得できます。特に、パーシスターは2.2.0以降のバージョンでかなりの量の修正を確認しているため、問題がすでに解決されている可能性が高くなります。

アップグレード後も問題が発生する場合は、RabbitMQDiscussメーリングリストで報告する必要があります。（CeleryとRabbitMQの両方の）開発者は、そこで報告された問題を修正することに重点を置いています。

于 2011-12-04T13:56:44.133 に答える
0

A. 2.7.1 より前の古いバージョンの RabbitMQ を実行しているから B. RabbitMQ に十分な RAM がないからです。サーバー上で RabbitMQ を単独で実行し、そのサーバーに十分な RAM を割り当てて、RAM が永続化されたメッセージ ログの可能な最大サイズの 2.5 倍になるようにする必要があります。

RAM を追加し、ボックス上の他のサービスを強制終了するだけで、ソフトウェアを変更せずにこれを修正できる場合があります。

これに対するもう 1 つのアプローチは、ソースから独自の RabbitMQ を構築し、Tokyo Cabinet を使用してメッセージを永続化する toke 拡張機能を含めることです。Tokyo Cabinet には NFS の破損の問題があるため、NFS パーティションではなく、ローカル ハード ドライブを使用していることを確認してください。もちろん、これにはバージョン 2.7.1 を使用してください。メッセージの内容によっては、Tokyo Cabinets の圧縮設定を使用して、保持されたメッセージの読み取り/書き込みアクティビティを減らすこともできます。

于 2012-01-29T06:27:13.840 に答える