ライブラリが大きくなると、クエリ処理やワーキングセットが効率的なインデックスやキャッシュの再利用範囲を超え、Jellyfinの検索が遅くなることがあります。
増加したことだけで、データベースに問題があるとは限りません。カタログが大きくなると、レコード数、関連付け、アートワークの検索回数が変わるほか、スキャンやバックグラウンドの書き込みによって競合が増えることもあります。クエリとクライアントを一定に保ち、データベースの処理時間と画像の読み込み、インターフェースの描画を分けて考えましょう。
増加によってクエリ処理量が変わる
ライブラリが増えると、検索で調査または結合するタイトル、人物、ジャンル、パス、プロバイダーID、関連付けが増加します。コストを決めるのはメディアのバイト数だけではなく、クエリの形状とインデックスとの適合性です。
永続データの役割モデルを使い、「ライブラリサイズ」という単一の数値ではなく、レコードと関連付けという観点で考えてみてください。
インデックス化されたオブジェクト数が少なければ、大量の映画ファイルを収集していても快適に動作する場合があります。一方、多数の小さなアイテムがあると、クエリ処理量は急速に増えることがあります。
インデックスとクエリの形状を一致させる
インデックスは、そのキーの順序と選択性が、使用するフィルターやソート順と一致するときに効果を発揮します。広範囲のテキスト検索を行ったり、複数の関連付けを結合したり、大量の結果をソートしたりするクエリでは、限定的な検索よりも多くのデータをスキャンすることがあります。
ストレージのレイテンシーとアクセスパターンの違いについては、一般的なストレージのレイテンシーとスループットの解説とクエリを比較してみてください。ただし、Jellyfinでの正確な結果は、データベースとクライアントの経路によって異なります。
有用な測定は、異なる検索パターンのベンチマークではなく、ライブラリの増加前後で同じクエリを実行して比較することです。
キャッシュとストレージがクエリのコストに見えることがある
データベースページ、アートワークファイル、ファイルシステムのメタデータがキャッシュにない場合、クエリプランが変わっていなくても検索が遅く感じられることがあります。バックグラウンドのスキャンやバックアップによって、キュー待ちが発生し、実行間に有用なページがキャッシュから追い出されることもあります。
カタログの増加を原因と決めつける前に、コールドおよびウォームベンチマークの方法を使って、コールド状態とウォーム状態を分けて測定してください。
2回目の検索は速いのに1回目が遅い場合、キャッシュまたはストレージが体感速度に影響しています。両方とも遅い場合は、クエリ処理量やデータベースの競合をより重視すべきです。
原因と見当違いを切り分ける
クエリ時間、結果の描画、画像の読み込み、ストレージのレイテンシー、バックグラウンドの書き込みを、それぞれ別のイベントとして測定します。その後、競合するジョブを1つ停止するか、リクエストの変数を1つ変更して再測定してください。
短いJellyfinクライアントの挙動確認手順を使えば、その症状がデータベース処理、画像の経路、クライアントUIのどこに属するのかを判断できます。
別の原因を取り除くことでベースラインに戻るなら、遅延をライブラリの増加だけに結び付けるのはやめましょう。増加は条件であり、制限要因については依然として証拠が必要です。
テック&AIハブ
もっと読む

Home AssistantはLAN接続とリモート接続でなぜパフォーマンスが異なるのですか?
LAN接続とリモート接続のHome Assistantセッションではネットワーク経路が異なります。リモート接続では、DNS、暗号化、WAN、プロキシやVPN、再接続処理による遅延が加わります。

Home AssistantはCGNATや二重NAT環境でも安定して動作しますか?
CGNATと二重NATは通常、ローカルでのHome Assistantの制御には影響しません。主に、リモートクライアントがホームネットワークへのインバウンド経路を確立する方法が変わります。

インターネット障害中、ネットワーク遅延はHome Assistantにどのような影響を与えるか?
インターネット接続の喪失とネットワーク遅延は異なる障害です。DNS、クラウド連携、ゲートウェイ、リモートクライアントが待機している間も、ローカルデバイスへの経路は高速なまま維持されることがあります。

