ImmichがCPU、RAM、ストレージ、ネットワークのどれによって制限されているかを見分ける方法

エヴァ・ウォン

IceWhale author

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

How to Tell Whether Immich Is Limited by CPU, RAM, Storage, or Network - Zima Store Online

固定したアップロード、閲覧、検索、またはバックグラウンドジョブのワークロードを再現し、その完了率を同じ時間帯のCPU飽和、メモリ圧迫、ストレージ遅延、ネットワークスループットと関連付けることで、Immichの制限要因を特定します。

高い使用率だけではボトルネックとは限りません。機械学習中のCPU使用率100%は健全な場合があり、高いRAM使用量はファイルシステムキャッシュかもしれません。また、アップロードが遅い原因はスマートフォンやWi-Fiにある可能性もあります。クライアントからコンテナ、ホストまで測定し、キューの進行状況を記録したうえで、疑わしい制約を1つだけ変更して再試行します。同じワークロードの改善につながったリソースが、支配的な制限要因です。

再現可能なテストとタイムラインを1つ作る

改善したい症状を1つ選びます。固定したメディアバッチの取り込み、キャッシュされていないオリジナルの表示、サムネイルの生成、Smart Searchの実行、または1本の動画のトランスコードなどです。開始時刻、最初に利用可能な結果が出た時刻、完了時刻、失敗、ジョブキューの変化を記録します。タスクを混在させると、判断につながらないリソースグラフになります。

あるユーザーの調査では、CPU、メモリ、ディスク、ネットワークの証拠を求めながら、Immichのデプロイが異常に遅い状況を説明しています。その複数リソースにまたがる診断の考え方は有用ですが、原因をサーバー上で特定するには、固定したテストを実施する必要があります。

キャッシュが温まった後にもう一度実行します。2回目が大幅に速い場合は、ハードウェアに一貫性がないと判断せず、キャッシュの状態を記録します。両方の実行が同じ段階で停止する場合は、そのタイムスタンプをホストとコンテナのメトリクス、および該当するジョブと照合します。

CPUとメモリの兆候を特定する

CPUが制限要因の場合、該当するコアで実行待ちの処理が継続的に発生し、ジョブの進行もそれに比例します。同時実行数を減らすと操作性は改善する場合がありますが、処理の消化には時間がかかります。総CPU使用率が控えめに見えても、1つのスレッドが使い切られている場合があります。そのため、余力があると判断する前に、プロセス別およびコア別の表示を確認します。

メモリが制限要因だと判断するには、圧迫の証拠が必要です。スワップの増加、メモリ回収、メジャーフォールト、OOMによる強制終了、またはコンテナの再起動などです。使用メモリが多くても、キャッシュが安定し、スワップがなく、遅延が正常なら、このテストは不合格になりません。同時実行数を減らしたワーカー1つ、または小さいモデルで再実行し、完了状況を比較します。

報告されたImmich v2.5.5のサムネイル事例では、あるデプロイで極端に多くのメモリを消費しました。このバージョンが限定されたメモリ報告は、失敗したジョブとリリースを確認する根拠になりますが、通常必要なRAM容量を示すものではありません。

ストレージ遅延とネットワークスループットを切り分ける

ストレージについては、対象のジョブを実行している間、デバイス遅延、キュー深度、スループット、ファイルシステムの空き容量、inodeの利用可能数を確認します。1秒あたりのメガバイト数が少なくなくても、多数の小さなデータベース処理やサムネイル処理が高遅延のディスク待ちになると、ストレージが制限要因になることがあります。

ネットワークについては、クライアントとサーバーの両方で測定し、ローカル経路とリモート経路を比較します。転送中に、リンクの飽和、再送、Wi-Fiの再試行、VPNの上限が同時に発生していれば、ネットワークが制限要因だと考えられます。アップロードの通信が終わった後も処理が遅い場合は、代わりにサーバー側のキューを追跡します。

ZimaSpaceの古いハードウェアで動かせるサービスの概要は、システム計画の参考になります。ただし、この診断ではハードウェアの年式ではなく、観測した遅延と処理速度を根拠にしてください。

Featured

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

ZimaCube2

1つの制約を緩和し、同じワークロードで検証する

安全な変数を1つだけ変更します。1つのジョブの同時実行数を減らす、一時的にメモリ制限を設けてテストする、稼働中のデータのコピーをより高速なストレージへ移す、有線のローカルネットワークで試す、といった方法があります。データセット、バージョン、キャッシュ状態は比較可能な条件に保ちます。完了状況と予測したメトリクスの両方が改善すれば、因果関係のテストに合格です。

アイドル時の平均値や単一のピークだけを見て、ハードウェアを購入してはいけません。ソフトウェアのエラー、空き容量の問題、競合するスケジュール済み処理を除外した後も、重要なワークロードを繰り返し支配するリソースであれば、アップグレードする価値があります。

障害を別の層へ移したり、サービスの目標を超えてキューを長くしたりする変更は元に戻します。どのリソースにも圧迫が見られないのにシステムが停止する場合は、ワークロードの定義、タイムスタンプ、コンテナ別メトリクス、ディスク遅延、ネットワークテスト、キューの進行状況、ログを添えてエスカレーションします。そのパターンは、ロック、依存関係、またはアプリケーションの障害を示している可能性があります。