Immichの実際のパフォーマンス上限を最も頻繁に決める依存要因とは？

エヴァ・ウォン

IceWhale author

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

What Dependencies Most Often Set the Real Immich Performance Ceiling?

Immichのパフォーマンスは通常、恒久的なハードウェア仕様ではなく、特定のワークフローで現在稼働している依存関係のうち最も遅いものによって制限されます。

アップロード、スマート検索、タイムラインの閲覧、動画再生では、クライアント、ネットワーク、サーバー、データベース、ワーカー、ストレージの異なる組み合わせを通過します。実際の上限は、エンドポイントやバックグラウンド処理の重なり方が変わると移動するため、容量について考える際は、コンポーネントの一覧ではなく処理経路から始めるのが有効です。

パフォーマンスの上限はエンドポイントごとに決まる

パフォーマンスの上限とは、指定された条件下で1つの操作が達成できる最大の有効処理速度、または最小レイテンシーです。CPU使用率が最も高くなる地点ではありません。アップロードの受け付け、検索結果の選択、表示可能なサムネイル、再生可能な動画にはそれぞれ異なる完了条件があり、依存関係の連鎖も異なります。

ZimaSpaceのImmichのデータパスに関する記事では、アップロードの受け付け、処理の準備完了、検索結果の選択、メディア配信を分けて説明しています。この区別により、機械学習ワーカーを改善するとインデックス作成は高速化できてもサムネイル配信は変わらないことや、ネットワークアクセスを高速化しても遅いデータベースクエリは改善できないことが分かります。

どのような問題報告やベンチマークでも、開始イベント、終了イベント、クライアント、メディアのまとまり、キャッシュ状態、バックグラウンド処理の負荷を記録してください。その後で必要な処理段階を描きます。上流からの処理がより速く到着したときにエンドポイントの改善を妨げる処理段階のサービス時間またはキューが、上限を決めます。

データベースとキューの状態が調整を制限することが多い

データベースはアセットを選択し、アプリケーション間の関係を保持します。一方、キューの状態はバックグラウンド処理を調整します。これらの遅延により、コンピュートワーカーに余力があっても、検索、インポート、準備完了までの時間が制限されることがあります。逆に、深いキューはキューサービス自体が遅いのではなく、流入する処理量がワーカーの処理能力を超えていることを示す場合があります。

アーキテクチャの詳細分析では、PostgreSQLがユーザー、アセット、アルバム、ベクトル埋め込みを保持し、Redisが非同期ジョブキューを管理すると説明されています。これは独立した導入構成の解説であり、ここでの価値は特定の固定リソース数ではなく、依存関係を分離している点にあります。

データベースの応答時間、接続待ち、キューの深さ、1分あたりの完了ジョブ数をまとめて観測してください。ワーカーのスループットが横ばいでデータベースの処理時間が安定しているのにキューの深さが増えるなら、ワーカーがボトルネックである可能性が高いです。すべての処理段階がデータベース待ちの周辺で停止しているなら、ワーカーの同時実行数を増やすことで上限が悪化する可能性があります。

ストレージ、メモリ、コンピュートはボトルネックを交換する

メモリによって、データベースページ、サムネイル、モデルをプロセッサーの近くに保持できます。ワーキングセットが収まらなくなると、それまでメモリ速度で処理されていたリクエストにストレージのレイテンシーが入り込みます。一方、新規インポート中は、サムネイル生成、動画処理、機械学習などの計算負荷の高い処理が支配的になることもあります。制限要因は状態やワークロードに応じて変化します。

Immichのセルフホスティング分析では、アプリケーションとデータベースに必要なメモリは比較的少ない一方、機械学習にはより多くのメモリが必要で、モデルの読み込みが影響すると説明されています。具体的な数値はリリースやモデルによって異なりますが、依存関係に関する教訓は変わりません。合計RAM容量だけでは、どのサービスがワーキングセットを失うのかは分かりません。

コールド、ウォーム、継続稼働の各フェーズを比較してください。コールドからウォームへの大きな改善は、モデルやキャッシュの読み込みを示します。広範なクエリでデバイスのレイテンシーが高くなるなら、ワーキングセットのキャッシュミスが疑われます。I/Oが安定したままコンピュートが飽和しているなら、処理が制限要因です。1つの制限要因を変更した後は、次の段階が支配的になっている可能性があるため、完全な処理経路を再実行してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

エンドポイントから依存関係へのマップを作成する

アップロードの受け付け、検索結果の応答、最後に表示されるタイムラインのサムネイル、動画の再生開始について行を作成します。列には、クライアント側の準備、ネットワーク転送、アプリケーション処理、データベースまたはキュー処理、ワーカー処理、ストレージアクセス、クライアント側のデコードを追加します。すべてのエンドポイントにすべてのコンポーネントを割り当てるのではなく、使用しない処理段階には「該当なし」と記してください。

2TBの家族向けライブラリでサムネイル生成のオフロードについて扱ったコミュニティレポートは、処理能力とNASストレージ容量を区別する実務上の必要性を示しています。これはオフロードが常に必要だと証明するものではなく、大規模なインポートでは特定のワーカー処理経路が支配的になり得ることを示しています。

代表的な実行を1回測定し、実際に観測された待ち時間だけを順位付けしてください。最上位の処理段階に対する介入を1つと、その介入を却下する条件を1つ提案します。エンドポイントが改善したら、上限が移動したためマップを更新します。改善しなければ、その仮説を破棄してください。これにより、買い物リストではなく、証拠に基づく因果関係の連鎖を作れます。