家族写真のバックアップ中にImmichでファンの音が大きくなるのはなぜですか？
家族写真のバックアップ中にImmichの動作音が大きくなることがあります。ファイルの受け入れによって、ネットワーク転送後にCPU、機械学習、動画、データベース、ストレージに関する追加処理が発生する可能性があるためです。そのため、ファンの騒音は発熱の兆候ではあっても、Immichのどのコンポーネントが原因かを特定するものではありません。
スマートフォンで数千枚の写真のアップロードが完了しても、サーバーではサムネイルの生成、メタデータの抽出、顔の分析、検索用表現の構築、動画の処理が続くことがあります。ファンカーブを変更したり新しいハードウェアを購入したりする前に、騒音が発生した時間帯と、実行中のジョブキューおよびホストのリソースグラフを照合してください。
ファンの回転数上昇と同時に始まったジョブを照合する
ファン速度または温度を、CPU使用率、存在する場合はGPUの稼働状況、ディスクレイテンシ、Immichのジョブ数とともに記録します。静かな状態を基準として、代表的な家族写真のバックアップを1つ開始し、アップロードが終了した時点を記録してください。特定のキューが減り続けている間もファンが高速回転しているなら、モバイル端末からの転送そのものより、その後段のジョブのほうが有力な原因です。
最近のコミュニティ報告では、数千枚の画像と動画をインポートした後にCPU使用率が高い状態が続き、サーバーが停止していると決めつけるのではなく、Immichのジョブキューを確認することが推奨されていました。このような報告はワークロードの参考情報として利用し、温度仕様として扱わないでください。メディアの構成、有効なジョブ、CPUの世代、アクセラレーター、冷却性能によって、2つのライブラリの動作は大きく異なる可能性があります。
温度が上昇しているのにCPU、GPU、ディスクの処理がほぼアイドル状態なら、この分岐では騒音を説明できません。筐体内のエアフロー、ほこり、ファン制御の挙動、隣接するコンテナ、ファイルシステムのスクラブ、バックアップソフトウェアを確認してください。ZimaSpaceのAI NASの電力、冷却、インデックス作成の負荷に関する分析は、継続的なローカル処理によって、静かなストレージ機器の動作が変わる理由を理解するのに役立ちます。
機械学習や動画処理を通常のアップロードと切り分ける
少量の制御されたバッチを実行し、ファイルの到着後に機械学習、サムネイル生成、動画関連の処理のどれが支配的になるかを確認します。画像分析によってCPUやアクセラレーターが長時間使用されることがあり、動画処理ではより長い負荷の波が発生する場合があります。サムネイル生成とメタデータ抽出では、CPU処理に加えて多数のファイルシステム操作が発生することがあります。
Immichのバックグラウンド処理に関する議論は、重要なキューの挙動を示しています。上流の処理が完了する前に後段のジョブが作成されることがあるため、システムが進行していても1つのキューが増える場合があります。件数が増えているからといって、必ずしもループが発生しているわけではありません。到着率と完了率を比較し、同じアセットで失敗が繰り返されていないか確認してください。診断中は、負荷が高いと確認できた種類の処理だけを一時停止するか減らします。ファンの騒音がすぐに下がり、家庭内のインターフェースの応答性が改善した場合は、同時実行数を下げて再開し、キューの処理完了までにどれだけ時間が延びるかを測定します。騒音が変わらない場合は、元の設定に戻し、関係のない調整を重ねるのではなく、次のリソースを確認してください。
CPU使用率で騒音を説明できない場合はストレージと冷却を確認する
ハードディスクは、オリジナルファイルの書き込み、生成ファイルの作成、データベースのチェックポイント処理、またはImmichのインポートと重なった別のNASバックアップの実行中に、稼働し続けることがあります。CPU使用率が中程度に見える場合でも、ディスクの活動によって小型筐体が温まることがあります。「CPU使用率が低い」ことを、冷却も静かなはずだという証拠とみなすのではなく、プロセッサー温度とともにドライブ温度やI/O待ち時間も記録してください。
吸気口と排気口がふさがれていないこと、ファンとヒートシンクが清潔であること、サーバーがサーマルスロットリングなしにワークロードを継続できることを確認します。独立したNASの負荷時および騒音の測定結果は、予想される仕組みを示しています。小型システムは、アイドル時よりも継続的な負荷がかかっているときのほうが、明らかに大きな音を出すことがあります。
正確なdBA値はハードウェアによって異なるため、自分の温度とファンカーブを許容範囲の基準として使用してください。
筐体を静かにするために、処理のボトルネックを断熱したり、エアフローを制限したりして解決しようとしないでください。サーバーを人の近くに置く必要がある場合は、初回の大規模インポートを許容できる時間帯にスケジュールする、測定した同時実行数を下げる、マシンを移動する、または冷却を改善してください。発熱や騒音への曝露を減らしつつ、騒音を見えない熱ストレスに変えないことが重要です。
完全なバックアップサイクルで騒音を検証する
対象を1つだけ変更した後、同じサンプルを再実行し、アップロードの完了、キューの処理完了までの時間、温度、ファンの挙動、検索の応答性、失敗したジョブを測定します。最後のアップロード後にバックグラウンド処理が落ち着くまで十分な時間を取り、転送中の時間帯だけで判断しないでください。実際にサーバーを発熱させている段階を見落とす可能性があります。
良好な結果とは、騒音が発生する時間帯が予測可能で、ハードウェアにとって安全な温度が安定し、ジョブが進行し、サーマルスロットリングや予期しない再起動がなく、ワークロードの処理完了後に基準状態へ戻ることです。その範囲を記録しておけば、後から発生したファンの騒音を、正常な家族写真バックアップサイクルと比較できます。キューが空になった後も騒音が長時間続く、1つのジョブが同じ処理を繰り返し生成する、またはImmichがアイドル状態なのにホストが熱い場合は、別個の冷却問題または競合サービスの問題として扱ってください。温度、可能であればファンRPM、リソースグラフ、キュー数、バージョン、ワークロードが終了したのに症状が続いた時刻を添えて、詳細な調査を依頼します。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
