小型ホームサーバーで家族の写真バックアップ用にImmichを最適化する方法
小規模なホームサーバーでImmichを調整する際は、まずアップロードとデータベースの応答性を保護し、そのうえで、測定したCPU、メモリ、ストレージの負荷に応じて、サムネイル生成、動画処理、機械学習処理を制限またはスケジュールします。
対象となる負荷は、アイドル状態のダッシュボードではありません。複数のスマートフォンが写真や動画をアップロードする夜間に、バックアップ、検索、派生メディアのジョブが競合する状況です。そのピーク時の状態を記録し、同時実行数またはスケジュールの設定を一度に1つだけ変更して、オリジナルとデータベースのバックアップを維持してください。キューの処理が遅くなるのは許容できますが、アップロードの失敗、スワップの発生、データベースの応答停止は許容できません。
調整前に家族で最も忙しいアップロードを測定する
スマートフォンの写真、短い動画、大きめの動画を1本含む、実際の利用を代表するバッチを作成します。アップロード開始からキューがゼロに戻るまで、完了時間、ジョブキューの深さ、CPU、メモリ、スワップ、ディスクレイテンシ、空き容量、ネットワークスループットを記録してください。このベースラインから、実際に飽和しているリソースを特定できます。
小規模サーバーでのImmichの機械学習に関する議論では、ライブラリの規模、モデルの選択、処理を後回しにできるかどうかによって、必要なハードウェアに関する判断が変わることが示されています。アイドル時の使用率だけを見て購入や調整を行わないよう、この負荷に応じた比較を参考にしてください。
合格条件は、アップロードの応答性が維持され、許容した時間内にバックログが処理されることです。メモリのスワップが発生したり、コンテナが再起動したりする場合は、まず同時実行数を減らしてください。CPU使用率が上限に達していても操作が応答するなら、負荷の高い処理をスケジュールします。複数のサービスでストレージレイテンシが上昇する場合は、モデルを変更する前に、アクティブなデータ経路を保護してください。
同時実行ジョブ数を制限し、負荷の高い処理をスケジュールする
すべてのワーカーを一律に抑えるのではなく、測定で負荷が高いと分かったキューの同時実行数を減らします。動画のトランスコードと機械学習は、異なるリソースを大きく消費することが多く、メタデータの抽出やサムネイル生成は、利用可能になるまでの体感時間に影響します。1つのキューだけを変更し、同じバッチを再実行して、応答性と処理完了までの時間の両方を比較してください。
大規模なライブラリのスキャン、バックアップ、任意の再処理は、家族がアップロードする時間帯を避けてスケジュールします。低速なディスクを1台しか搭載していないサーバーで、ストレージスナップショット、データベースのメンテナンス、動画のトランスコードを同時に実行しないでください。合格条件は、キューを永続的に増加させることなく、ピーク時の競合を抑えられることです。
調整中も、再試行回数の上限とログを確認できる状態にしておきます。ジョブが失敗した場合は、失敗が目立たなくなるまでワーカー数を減らすのではなく、以前の設定に戻してエラーに対処してください。目標は処理を制御することであり、処理を隠すことではありません。
アクティブな状態を高速に保ち、オリジナルを保護する
可能であれば、データベースと頻繁に書き込まれる派生データを、低レイテンシで信頼性の高いストレージに配置します。一方、オリジナル用のストレージ層は、容量、耐久性、バックアップ設計を基準に選択してください。ローカル容量を空けるためだけに、データベースの生データディレクトリを安易なネットワーク共有へ移動するのは避けます。
独立したImmichセルフホスティングガイドでは、家庭向け写真サービスにおけるストレージ、アクセス、リモート利用をめぐる、より広範な判断について説明しています。アーキテクチャの背景として参照し、実際のパスと障害発生時の動作は自分の環境で検証してください。
ZimaSpaceの家族写真バックアップガイドは、調整を復旧可能性より優先しないための助けになります。処理が高速になっても、テストされていないデータベースやオリジナルファイルのバックアップを補うことはできません。
家族のワークフローを再テストし、停止基準を設定する
同じバッチを、別の家族が写真を閲覧、検索し、オリジナルをダウンロードしている状態で再実行します。合格条件は、アップロードが成功し、操作に支障がなく、スワップの連鎖やコンテナの再起動が発生せず、計画したオフピーク時間内にキューが処理されることです。
サーバーを再起動し、マウントと制限が維持されていることを確認してから、ローカルネットワーク外で1台のスマートフォンのバックグラウンドアップロードをテストします。平均ではなく、ピーク時の利用状況を1週間記録してください。同じ名前のリソースが、安全な調整を行った後も繰り返し目標を超える場合にのみ、新しいハードウェアを検討します。
キューが処理され続けたり、派生アセットが不足したりする場合は、制限を元に戻します。空き容量が測定したバースト要件を下回ったら、同時に実行するジョブを増やすのをやめてください。問い合わせやエスカレーションの際は、1枚の使用率スクリーンショットではなく、固定したテストバッチ、CPU・メモリ・ストレージレイテンシのグラフ、キュー名、変更前後の設定を提示します。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
