バックアップ時間帯に合わせて写真サムネイル処理を最適化する方法

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

サムネイルの生成では、元ファイルの読み取り、多数の小さな派生ファイルの書き込み、データベース行の更新が行われるため、動画エンコードや機械学習とCPUを奪い合う可能性があります。NASバックアップ中に実行すると、両方の処理が長引き、写真を閲覧する際のインタラクティブな操作のレイテンシも増加することがあります。

目的は、サムネイル生成を恒久的に遅くすることではありません。バックアップと競合しているリソースを測定し、関係する同時実行数だけを減らし、各負荷の高い処理に明確な実行時間帯と、予定時間を超過した場合の復旧ルールを設定します。一時的なスロットリングが気付かないうちに恒久的な制限にならないよう、通常のワーカー設定を文書化しておきます。

ワーカーを変更する前に競合を測定する

サムネイルの未処理キューがない状態で通常のバックアップを実行し、所要時間、ストレージのレイテンシ、ネットワークスループット、CPU使用率を記録します。別の日に、バックアップの通信がない状態で代表的なサムネイルバッチを処理し、同じ指標を取得します。

制約されているリソースによって対策が決まります。ディスクレイテンシが高い場合は、読み取りと書き込みの処理を時間的にずらすと効果的です。CPUが飽和している場合は画像ワーカーを減らします。データベースボリュームが過負荷の場合は、データベースストレージと派生ファイル用ストレージを分離する必要があります。

Immichでは、ジョブとワーカーのドキュメントで説明されているジョブキューとワーカー制御を利用できます。編集前に現在の値を記録しておけば、実験に失敗しても確実に元へ戻せます。

静穏時間帯と超過時のルールを設定する

復旧要件が最も厳しい時間帯にバックアップを配置し、その前後の時間帯をサムネイル処理用に確保します。キューの起動によってファイルのオープンやデータベース処理が急増する可能性があるため、両方を同じ分に開始するのは避けてください。

バックアップが長引いた場合の動作を定義します。安全なルールは、バックアップの完了が報告されるまでサムネイルワーカーを削減または一時停止し、その後、2つのスケジュールを無計画に重複させるのではなく、通常の同時実行数に戻すことです。

大量のインポート後にキャッチアップ用の時間帯を確保します。これがないと、夜間のワーカー数を低く設定した場合、日中に利用可能なリソースがあるにもかかわらず、ユーザーがサムネイルを何日も待たされることがあります。

ボトルネックに合わせて同時実行数を調整する

一度に変更するワーカークラスまたは同時実行数は1つだけにし、同じサイズのバッチを処理します。CPU使用率だけで成功を判断するのではなく、バックアップの所要時間やインタラクティブ操作のレイテンシと、キューの処理速度を比較します。

元ファイルとバックアップが同じHDDを共有している場合、CPUの上限を上げるよりも、同時に実行する画像読み取り数を減らす方が効果的なことがよくあります。元ファイルが高速ストレージ上にあり、データベースが負荷の高い状態なら、ワーカー数を増やす前にデータベースの処理を移動または保護します。

両方の処理中もネットワークマウントを安定させてください。Immichネットワークストレージガイドでは、マウント済みでも停止したパスがアプリケーションのジョブ問題のように見える理由を説明しています。

1サイクルを最後まで検証し、通常のサービスに戻す

バックアップを完全に実行した後、サムネイル処理の時間帯を設け、その一連の流れを観察します。開始時刻と終了時刻、ストレージレイテンシの最大値、キューの深さ、失敗したジョブ、処理中にユーザーが最近の写真を開けるかどうかを記録します。

未処理キューが解消したら、削減した設定がキャッチアップ保護のためだけのものであれば、同時実行数を文書化した通常値に戻します。恒久的なスロットリングは、意図的に行い、測定したサービス目標に基づいて設定してください。

バックアップの所要時間が予測可能な状態に保たれ、サムネイルキューが計画したキャッチアップ時間内に解消され、失敗したジョブやアセットの欠落がない場合に、変更は成功です。エラー率またはデータベースレイテンシが上昇した場合は、直前に行った同時実行数の変更をロールバックします。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.