上手。Sidekiqを使用してバックグラウンドでビデオファイルを変換しています。同じペイロードオブジェクトでジョブが重複しないように、 sidekiq-unique-jobsgemを使用します。
並行性が25のデフォルトのキューで、オプションなしでsidekiqプロセスを実行します。
問題は、長時間処理された後のすべてのジョブ（ビデオファイルは非常に大きい）がキューのバックログに送られますが、処理されたジョブのサイズも増加していることです。
仕事は完了したものでもユニークなものでもありません。私は立ち往生しています。前もって感謝します
UPD：
PumaをWebサーバーとして実行しています。
sidekiq-unique-jobsgemなしで実行してみてください。とにかく、だまされてからあなたを守っているのは 30 分間だけです。その gem は、Redis のハッシュキーを 30 分後に自動期限切れに設定します (構成可能)。sidekiqそれ自体が、24 時間後に Redis で自動期限切れになるようにジョブを設定します。
明らかにあなたのアプリは見えませんが、同じファイルをあまり頻繁に処理したくないに違いありません。代わりに、アプリケーション レイヤーでこれを制御し、独自のハッシュキーを追跡して、unique-jobs gem が行っていることと同様のことを行います。
hash = Digest::MD5.hexdigest(Sidekiq.dump_json(md5_arguments))
また、sidekiq-unique-jobsミドルウェアがsidekiq、ジョブが正常に完了したかどうかを判断するのを妨げている可能性もあります。同じ構成で長時間実行されるジョブでこれをテストしている人はあまりいないに違いありません。
ミドルウェアを追加しなくてもこの動作が続く場合はresque、試してみてください。その宝石でこの種の動作を見たことはありません。失敗したジョブには、管理 GUI に便利な再試行オプションがあります。
sidekiq の主な利点は、マルチスレッドであることです。それでも、大規模なビデオ プロセスでの 25 の同時実行は、それを少し押し上げる可能性があります。私の経験では、フォークは安定性と移植性に優れており、アプリケーションのスレッド セーフ (YMMV) に関する心配が少なくなります。
何をするにしても、これらのシステムが Redis のデータに設定する自動有効期限の TTL 設定を認識していることを確認してください。ジョブのサイズと性質は、ジョブが 24 時間簡単にバックアップできることを意味します。これらの自動削除は、データベース レイヤーで行われます。ジョブが自動的に削除された場合に警告するアプリケーション層へのコールバックはありません。sidekiqたとえば、コードでは、「リークの可能性を回避するために」自動期限切れ動作が導入されました。(参照) これらのジョブを本当に実行する必要がある場合、これはあまり心強いことではありません。