3

誰かがこの問題を見たことがあるのだろうか。私は、sucker_punch gem バージョン 1.1 を使用して Passenger 3 で Rails 3.2 を実行しています。

私は長時間実行されている sucker_punch ジョブ (約 10 時間かかります) を持っています。これは一晩のバッチです。私はPhusion Passengerで実行しています（3つのワーカースレッドだと思います）

status from passenger-status
----------- General information -----------
max = 3
count = 0
active = 0
inactive = 0
Waiting on global queue: 0

私の sucker_punch ジョブは非同期で実行されます。ジョブの一部として、他の非同期の小さな sucker_punch ジョブを実行します (それぞれ約 30 秒かかります)。

何が起こっているのかを正確に判断することはできませんが、「時々」長時間実行されているジョブが停止するか、停止しているように見えます。sucker_punch ジョブ全体にデバッグ コードを追加しました。

begin
rescue Exception => e
  logger.error(e)
  raise e
end

ただし、例外は見られませんでした。長時間実行されている sucker_punch が強制終了されたのではなく、停止されたと仮定しますか? または、ある種のデッドロックの可能性はありますか?

これの興味深い部分。長時間実行されているジョブが正常に機能する場合と、そうでない場合があります。

4

1 に答える 1

5

正解です。現在、Passenger は、プロセスがバックグラウンド タスクではなく Web リクエストのみを処理すると想定しています。このため、Passenger はバグのあるアプリをチェックするために一定の制限を課しています。これらの制限の 1 つは、プロセスがシャットダウンするように指示された場合、1 分以内にシャットダウンする必要があるということです。そうでない場合、Passenger は強制的にシャットダウンします。残念ながら、これはアプリ プロセス内でバックグラウンド タスクを実行するという概念と本質的に互換性がありません。

現在、これについて未解決の問題があります: https://github.com/phusion/passenger/issues/1211

将来これに取り組むことになるかもしれませんが、現時点では優先度の高い項目とは見なされていません。Sidekiq のようなアウトプロセス バックグラウンド ワーカー システムを使用することをお勧めします。

于 2014-07-12T21:31:54.917 に答える