0

私はいくつかのバックグラウンド サービスでdelayed_jobを実行していますが、これらはすべて最近まで分離して実行されていました。たとえば、電子メールの送信、レポートの作成などです。

最後のステップとして、別のdelayed_jobを提出するために、1つのdelayed_jobが必要になりました。

  1. delay.deploy() -delayed_job がこれを実行すると、デプロイ アクションがトリガーされ、その最後のステップは ...
  2. delay.update_status() -delayed_job がこのジョブを実行すると、開始したデプロイのステータスがチェックされます。デプロイがまだ進行中の場合は、delay.update_status() を再度呼び出します。デプロイが停止している場合は、最終的なデプロイ ステータスを db レコードに書き込みます。

ステップ 1 は問題なく動作します。5 秒後、delayed_job がデプロイを起動し、デプロイが開始され、delay.update_status() が呼び出されます。

しかし、ここでは update_status() が 5 秒で起動するのではなく、delayed_job がビジー ループに入り、多数の update_status 呼び出しを実行し、一時停止することなく非常に激しくループします。

これらすべての呼び出しでログがいっぱいになり、update_status の終了条件に達するまで (デプロイが最終的に成功または失敗するまで) サーバーの速度が低下し、再び静かになることがわかります。

Delayed_Job::delay() を間違って使用していますか? このユースケースの基本的な内容が欠けていますか?

4

1 に答える 1

0

OK、これは「予期される動作」であることがわかりました。既にdelayed_jobを実行しているコードにいて、遅延を指定せずに .delay() を再度呼び出すと、すぐに実行されます。パラメータ run_at を追加する必要があります。

  delay(queue: :deploy, run_at: 10.seconds.from_now).check_status

Google グループのディスカッションを見る

于 2013-05-10T05:54:22.670 に答える