なぜメディアNASでサムネイル生成が高いCPUおよびI/O負荷を引き起こすのか？

サムネイル生成は、メディアNASで高いCPU負荷とストレージI/Oを引き起こすことがあります。小さなプレビューははるかに大きなパイプラインの最終出力に過ぎないためです。NASはソースファイルの検出、読み取りとデコード、フレームの選択や変換、新しい画像のエンコード、結果の書き込み、メディアインデックスの更新を行う必要があります。

最初のライブラリスキャン、再構築、大量インポートの際に作業負荷が顕在化します。なぜなら同じパイプラインが何千もの写真やビデオに繰り返し適用されるからです。出力容量は小さいままでも、ソースの読み取り、デコーダーの処理、一時データ、データベーストランザクション、ファイル作成がシステムを忙しくさせます。

サムネイルが書き込まれる前に何が起こるのか？

メディアスキャナーはまずファイルを列挙し、タイプ、寸法、再生時間、向き、コーデックを特定するのに十分なメタデータを読み取ります。その後、サムネイル戦略を選択します：画像のリサイズ、埋め込みプレビューの抽出、ビデオフレームのデコード、または複数フレームを解析してクリップをよりよく表すものを選ぶ方法です。

変換自体は計算パイプラインです。ピクセルは圧縮フォーマットからデコードされ、回転、カラーマネジメント、リサイズされ、小さなJPEG、WebP、または他のプレビューフォーマットにエンコードされます。libvipsのサムネイルパイプラインは読み込みとリサイズを組み合わせており、対応する画像フォーマットでは読み込み時の縮小が高速化できると記載しています。

エンコード後、アプリケーションはプレビューファイルを書き込むか、別のキャッシュに画像データを保存し、ソースと派生物の関係を記録します。どの段階でも失敗や変更があると後で再生成が必要になるため、ライブラリの再構築は、目に見えるメディアファイル自体が変わっていなくても作業を繰り返すことがあります。バージョンアップにより、アプリケーションが寸法、コーデック、キャッシュキーを変更すると派生物が無効になることもあります。

なぜ小さなプレビューに大量のソース読み取りが必要なのか？

圧縮メディアは、最終的なサムネイルが表すバイト数だけを読み取ることで常にサイズを縮小できるわけではありません。デコーダーは画像や対象のビデオフレームを説明するヘッダーや圧縮データを必要とします。フォーマットやシーク構造によっては、有用なフレームに到達するために、最終プレビューに現れない素材の読み取りやデコードが必要になることがあります。

ビデオの選択は特にコストがかかることがあります。FFmpegのサムネイルフレームフィルターは連続したフレームのバッチを解析し、代表的なフレームを選択します。ドキュメントには、バッチが大きいほどメモリを多く必要とすることも記載されています。例では選択されたフレームをスケーリングし、別の画像として書き出します。

ライブラリが埋め込みプレビューや縮小読み込みをサポートするデコーダを使う場合、画像は安価になることがありますが、それは最適化であり普遍的な挙動ではありません。RAW写真、非常に大きな画像、特殊なコーデック、破損ファイル、埋め込みプレビューの欠如は、より多くのデコードを強い、ソース読み取り量がプレビュー出力よりはるかに大きくなることがあります。

ライブラリスキャンはどのように作業量を増やすのか？

通常、1つのサムネイルは些細なものです。スキャンはそれをバッチシステムに変えます：すべてのソースが検出、読み取り、変換、出力、インデックス作成を通過します。並列ワーカーは実時間を短縮しますが、同時にCPU需要と保留中のストレージ要求も増加させます。

この表は、プレビューサイズがシステムの作業量の良い指標でない理由を示しています。ほとんどのバイトはソースから読み取られ、ほとんどのCPU時間はデコードに費やされ、多くの書き込みはサムネイルファイル自体ではなくカタログに属しています。

正確な割合はアプリケーション、ソースフォーマット、ワーカー数、キャッシュ状態、サムネイルの有無によって異なります。これはベンチマークの約束ではなくワークロードモデルです。同じ容量の2つのライブラリでも、一方が短い動画を含み、もう一方が大きなRAW写真を含む場合、挙動は異なります。

なぜ小さな書き込みとカタログの更新が重要なのか？

生成される各プレビューは新しいファイルを作成し、ファイルシステムのメタデータを割り当て、タイムスタンプを更新し、カタログレコードを変更することがあります。したがって、数千の小さな出力は、合計容量が控えめでも多くの操作を生み出します。HDDアレイでは、これらの書き込みがソースの読み取りを妨げ、連続性の局所性を低下させる可能性があります。

メディアカタログは、スキャンを一貫して再開でき、クライアントが結果を照会できるように、トランザクション型データベースを使用することがよくあります。SQLiteの先行書き込みログモデルは、変更をWALファイルに追記し、後でチェックポイントとしてメインデータベースに反映させます。これにより、読み取りと書き込みに加えてチェックポイント処理が独立した操作として追加されます。

そのデータベースの挙動は、すべてのメディアサービスがSQLiteやWALを使っていることを意味しません。インデックスの更新が一見した行の変更よりも多くのストレージ活動を伴う理由を示しています。アプリケーションはコミットをバッチ処理したり、複数のインデックスを維持したり、別のデータベースエンジンを使っている可能性があるため、実際の書き込みパターンはサムネイル数だけから推測せずに測定する必要があります。

CPUとストレージが他のNAS作業と競合するのはいつか？

大規模なスキャン中、デコーダースレッドはファイル共有、ソフトウェアRAID、チェックサム、暗号化、メディアストリーミングも処理するCPUコアを消費することがあります。同時に、ソースの読み取りやプレビューの書き込みはバックアップ、ダウンロード、クライアント要求と競合します。サムネイルジョブ自体は失敗していなくても、閲覧や再生が遅くなるという目に見える症状が現れることがあります。

ワーカーの同時実行数を増やすことで、CPU、メモリ、ストレージに余裕がある間はキューを早く終わらせることができます。それを超えると、ワーカーが増えることで競合が発生し、I/Oキューが深くなり、メモリプレッシャーが高まります。バックグラウンド作業を積極的にスケジュールするメディアアプリケーションは、対話的な遅延を犠牲にしてバッチスループットを最大化することがあります。熱制限により長時間のスキャン中に持続的なCPU周波数が低下し、後半のジョブが前半より遅く完了することもあります。

トランスコーディングとサムネイル作成は関連していますが異なるものです。より広範なハードウェアトランスコーディングの判断はハードウェア計画の補助になりますが、特定のサムネイルパイプラインが同じアクセラレーション経路を使用している証明としては使うべきではありません。

生成中にメディアNASは何を測定すべきか？

アプリケーションが理解できる単位でキューを追跡します：検出されたメディアアイテム、完了したサムネイル、失敗、再試行、残りのジョブ。これにプロセスごとのCPU使用率、メモリプレッシャー、ソース読み取りスループット、プレビュー書き込み操作、データベース活動、ストレージ遅延を組み合わせます。生の使用率よりも1分あたりの進捗の方が有用なことが多く、追加のリソース使用がより多くのライブラリ作業を完了しているかを示します。

高いディスク使用率や容量グラフだけに頼らないでください。LinuxのディスクI/Oカウンターは、完了した読み取りと書き込み、マージされた操作、費やした時間、現在のリクエストを示します。これらはプロセスごとの監視と組み合わせることで、デコーダーに依存する作業とストレージのバックログを区別するのに役立ちます。

初回スキャンと定常状態の動作を別々に測定してください。完全な再構築は意図的にコストがかかりますが、通常の動作では新規または変更されたメディアのみを処理するはずです。キューが繰り返し再構築する場合は、アプリケーションログ、キャッシュの永続性、権限、ライブラリパスを確認してください。NASアプリケーションのパフォーマンスチェックが補助的な運用引き継ぎを提供します。

よくある質問

サムネイルファイルが非常に小さいのにCPU使用率が高いのはなぜですか？

ファイルサイズはエンコードされた出力を示し、作成に必要な作業量を示すものではありません。NASははるかに大きなソースをデコードし、ピクセルを回転またはカラーマネジメントし、リサイズしてから小さなファイルを書き込みます。

ビデオのサムネイルは写真のサムネイルより重いですか？

アプリケーションがシークし、1フレーム以上をデコードし、代表的な画像を選ぶ必要があるため、しばしばそうです。ただし、大きなRAW写真やサポートされていない画像の高速パスもコストがかかるため、メディアラベルだけでなくソースフォーマットがより重要です。

サムネイルキャッシュをSSDに置くと作業負荷は解決しますか？

多くの小さな書き込みや後のプレビュー読み取りのレイテンシを減らせますが、ソースのデコードやデータベース作業は除去しません。CPUが制限要因の場合、キャッシュだけを移動してもディスク活動は変わるかもしれませんが、全スキャン時間が比例して短縮されるわけではありません。

ハードウェアビデオデコードはサムネイル作成を高速化できますか？

アプリケーション、コーデック、ドライバー、サムネイルパイプラインが同じハードウェアパスをサポートしている場合に起こり得ます。ハードウェアの能力だけでは不十分で、サポートされていないフォーマットやソフトウェアのみのフィルターは依然としてCPUを使用する可能性があります。

なぜ再起動後にサムネイル生成が再開されるのですか？

アプリケーションがキャッシュ状態を失った、プレビュー形式を変更した、変更されたソースを検出した、カタログレコードのコミットに失敗した、またはライブラリを異なるパスにマウントした可能性があります。ログとジョブ状態の永続化は、ストレージ容量だけよりも有益です。

最終的な結論

サムネイル生成はメディア処理およびインデックス作成のパイプラインであり、小さなファイルのコピーではありません。ソースの読み取り、デコードコスト、小さな書き込みとデータベースの活動、キューの進行状況で評価してください。小さな最終プレビューはメディアNASに課される全作業を表すものではありません。