13

私は次の設定をしています：

  • 100 ワーカーのジェネリック ワーカー プール
  • 50 人のワーカーを含む優先度の高いワーカー プール
  • ほとんどの場合、タスクが非常に長いタイムアウト (応答に最大 20 秒かかる HTTP 要求の実行) で I/O の待機に費やされるため、このような大きな数を使用しました。
  • RabbitMQ をブローカーとして使用する
  • 次のパラメーターを使用して、celery'd github の init.dスクリプトを使用して、celeryd をデーモンとしてセットアップしました。CELERYD_OPTS="--time-limit=600 -c:low_p 100 -c:high_p 50 -Q:low_p low_priority_queue_name -Q:high_p high_priority_queue_name"

私の問題は、キューが「バックアップ」しているように見えることがあることです...つまり、タスクの消費が停止します。これにはシナリオがあるようです：

  • すべてのワーカーが使い果たされているわけではないことが示されますが、ブローカーで「未確認」メッセージがゆっくりと蓄積されます。celery inspect activeつまり、いくつかのアクティブなタスクしか表示されません。
  • キューは、蓄積することなく、新しいタスクの消費を停止します。
  • 「デッド」状態の場合strace、ワーカープロセスで使用しても何も返されません...ワーカーからのアクティビティは完全にゼロです

以下に関する情報や指針をいただければ幸いです。

  • どうすればデバッグできますか。straceワーカー プロセスが何をしているかを確認するために使用できますが、これまでのところ、ワーカーがハングしていることを伝えるのに役立ちました。
  • これを監視する方法と、自動回復を行う方法。セロリを管理するためのツールはたくさんあります (flowerただしevents、どちらもリアルタイムで優れていますが、自動監視/警告機能はありません)。Supervisord を使用して独自の監視ツールを作成したほうがよいのでしょうか?

また、django-celery からタスクを開始しています

4

3 に答える 3

4

非常に基本的なキュー ウォッチドッグは、cron によって毎分実行される 1 つのスクリプトだけで実装できます。まず、(ワーカーで) 実行されると、事前定義されたファイルにアクセスするタスクを起動します。次に例を示します。

with open('/var/run/celery-heartbeat', 'w'):
    pass

次に、スクリプトはそのファイルの変更タイムスタンプをチェックし、1 分 (または 2 分など) 以上離れている場合は、アラームを送信したり、ワーカーやブローカーを再起動したりします。

複数のマシンがある場合は少し複雑になりますが、同じ考え方が当てはまります。

于 2014-02-20T21:25:37.600 に答える
3

これは、ワーカーがタスクをプリフェッチしているためだと思います。それでも問題が解決しない場合は、セロリを 3.1 に更新して-Ofairworker オプションを使用できます。以前使ってみた設定オプション-OfairはCELERYD_PREFETCH_MULTIPLIER. ただし、CELERYD_PREFETCH_MULTIPLIER = 1ワーカーは 1 つのタスクを事前にプリフェッチするため、設定 (最小値) は役に立ちません。

http://docs.celeryproject.org/en/latest/whatsnew-3.1.html#prefork-pool-improvements 、特にhttp://docs.celeryproject.org/en/latest/whatsnew-3.1.html#caveatsを参照してください。

于 2014-02-13T08:47:21.497 に答える