ImmichがCPU、メモリ、ネットワーク、またはストレージのどれに制約されているかをテストする方法

エヴァ・ウォン

IceWhale author

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

How to Test Whether Immich Is CPU-, Memory-, Network-, or Storage-Bound

再現可能な1つの操作でImmichをテストし、リソース待ち時間とレイテンシーを関連付け、制御された介入によって疑わしいボトルネックを確認します。

ダッシュボードのスナップショットだけでは、有益なアクティビティと有害な競合を区別できません。固定したメディアとクライアント条件の下で、アップロードの受け付け、サムネイル表示、スマート検索の応答など、1つのエンドポイントを測定し、その後、制限要因と疑われるリソースだけを変更します。

1つのエンドポイントと再現可能なベースラインを定義する

まず、観測可能な形でエンドポイントを明確にします。「Immichは遅い」ではテストできませんが、「再起動後、同じタイムラインの20個のサムネイルが表示されるまで4秒かかる」ならテストできます。後続の実行で意図した1つの変数だけが変わるよう、クライアント、ネットワーク経路、アカウント、写真セット、開始条件を固定します。

Immichのデータパスモデルは、アップロード、処理、データベースの選択、メディア配信が異なる依存関係を経由することを示しています。検索選択を対象とするテストでは、結果リストの表示時間と画像のレンダリング時間を分けて計測してください。そうしないと、高速なクエリの後に低速なファイル読み取りが続いた場合でも、1つの区別不能な遅延として報告されます。

ベースラインは少なくとも3回実行し、中央値と、実用上重要な最遅パーセンタイルの両方を保存します。キュー深度、コンテナごとのCPU使用率、メモリプレッシャー、スワップアクティビティ、ネットワークスループットと再送、ディスクレイテンシー、I/Oキュー深度を記録します。ボトルネックの主張では、リソースのシグナルとエンドポイントの遅延が一致していなければなりません。

CPU飽和とメモリプレッシャーを分離する

CPUバウンドの実行では、実行可能な処理がプロセッサ時間を待ち続けるため、エンドポイントのレイテンシーは持続的なコア使用率の飽和やスロットリングに連動するはずです。一方、メモリバウンドの実行では、リクレーム、スワップ、コンテナの強制終了、モデルの繰り返し読み込みなどが現れることがあります。どちらもCPUチャートを多忙に見せますが、介入に対する反応は異なります。

最近の独立したImmichリソースガイドでは、総RAMを1つの要件として扱うのではなく、サーバー、PostgreSQL、Redis、機械学習コンポーネントに分けて使用量を説明しています。このサービスレベルの視点は重要です。ホストの空きメモリが十分でも、コンテナの上限が小さい場合があり、大きなファイルキャッシュがあるからといって、必ずしもメモリ逼迫がないとは限りません。

メモリを一定に保ったままバックグラウンドワーカーの並行数を減らすか、割り当てるCPUを増やして、CPUプレッシャーを検証します。ワーカー数を変えずにスワップアクティビティをなくすか、制限されたメモリ上限を引き上げて、メモリプレッシャーを検証します。エンドポイントが一貫して改善しない場合は、このテストにおける主な境界要因としてそのリソースを棄却します。

ネットワーク遅延とストレージ遅延を区別する

リモートメディアは両方を経由するため、ネットワークとストレージの制限は同時に現れることがよくあります。リンクが飽和すると1秒あたりの転送バイト数が制限され、ストレージの競合があると、リンクが空いていても読み取りや書き込みの完了時間が増加します。そのため、リモートクライアントだけでテストすると、遅いファイル配信を誤って別の層の問題と判断する可能性があります。

KingstonのSSD分析では、表面的なシーケンシャル速度以外にも、ストレージの応答に影響するバックグラウンド処理、ファームウェアの挙動、キャッシュ、ホストコマンドを重視しています。Immichでは、小さなサムネイルやデータベース操作が多数発生するため、単一の大容量ファイルの帯域幅結果よりも、レイテンシーとキューの挙動のほうが有用な情報になります。

サーバーのデータセットを変更せず、有線のローカルクライアントからエンドポイントを繰り返し実行し、次に通常のリモート経路から実行します。別途、ホスト上で代表的なファイルセットを読み取り、デバイスのレイテンシーを監視します。ローカルクライアントでのみ改善するならネットワーク経路が関係し、ホスト側で待ち時間が持続するならストレージまたはそのマウントが関係しています。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

介入マトリクスを使って各原因を採用または棄却する

テスト前に、CPU、メモリ、ネットワーク、ストレージの4行を作成します。各行に、予想される症状、対象を絞った介入、棄却条件を1つずつ記入します。これにより、結果が出た後に診断が変わるのを防ぎ、複数のアップグレードを一度に購入する理由ではなく、否定的な結果も有用な情報として扱えます。

公開されているImmichの現場レポートでは、十分なインターネット帯域幅があるにもかかわらずサムネイルが遅延する例が示されており、仕様だけでは不十分な理由が分かります。重要な証拠は、メディアの対象グループ、キャッシュ状態、ジョブ、クライアント、アプリケーションバージョンを固定したまま、対象を絞った変更によって測定したエンドポイントが変化するかどうかです。

CPUはプロセッサの負荷軽減によってレイテンシーが改善した場合のみ、メモリはリクレームの軽減によって改善した場合のみ、ネットワークは経路の負荷軽減によって改善した場合のみ、ストレージはデバイスまたはマウントの待ち時間低下によって改善した場合のみ、原因として採用します。2つの介入が有効だった場合は、両方の順序で再実行してください。最初のボトルネックを取り除いた後で初めて、2番目のボトルネックが見えることがあるためです。