ライブラリが大きくなるほど Jellyfin の検索が遅くなる理由

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

ライブラリが大きくなると、クエリ処理やワーキングセットが効率的なインデックスやキャッシュの再利用範囲を超え、Jellyfinの検索が遅くなることがあります。

増加したことだけで、データベースに問題があるとは限りません。カタログが大きくなると、レコード数、関連付け、アートワークの検索回数が変わるほか、スキャンやバックグラウンドの書き込みによって競合が増えることもあります。クエリとクライアントを一定に保ち、データベースの処理時間と画像の読み込み、インターフェースの描画を分けて考えましょう。

増加によってクエリ処理量が変わる

ライブラリが増えると、検索で調査または結合するタイトル、人物、ジャンル、パス、プロバイダーID、関連付けが増加します。コストを決めるのはメディアのバイト数だけではなく、クエリの形状とインデックスとの適合性です。

永続データの役割モデルを使い、「ライブラリサイズ」という単一の数値ではなく、レコードと関連付けという観点で考えてみてください。

インデックス化されたオブジェクト数が少なければ、大量の映画ファイルを収集していても快適に動作する場合があります。一方、多数の小さなアイテムがあると、クエリ処理量は急速に増えることがあります。

インデックスとクエリの形状を一致させる

インデックスは、そのキーの順序と選択性が、使用するフィルターやソート順と一致するときに効果を発揮します。広範囲のテキスト検索を行ったり、複数の関連付けを結合したり、大量の結果をソートしたりするクエリでは、限定的な検索よりも多くのデータをスキャンすることがあります。

ストレージのレイテンシーとアクセスパターンの違いについては、一般的なストレージのレイテンシーとスループットの解説とクエリを比較してみてください。ただし、Jellyfinでの正確な結果は、データベースとクライアントの経路によって異なります。

有用な測定は、異なる検索パターンのベンチマークではなく、ライブラリの増加前後で同じクエリを実行して比較することです。

キャッシュとストレージがクエリのコストに見えることがある

データベースページ、アートワークファイル、ファイルシステムのメタデータがキャッシュにない場合、クエリプランが変わっていなくても検索が遅く感じられることがあります。バックグラウンドのスキャンやバックアップによって、キュー待ちが発生し、実行間に有用なページがキャッシュから追い出されることもあります。

カタログの増加を原因と決めつける前に、コールドおよびウォームベンチマークの方法を使って、コールド状態とウォーム状態を分けて測定してください。

2回目の検索は速いのに1回目が遅い場合、キャッシュまたはストレージが体感速度に影響しています。両方とも遅い場合は、クエリ処理量やデータベースの競合をより重視すべきです。

原因と見当違いを切り分ける

クエリ時間、結果の描画、画像の読み込み、ストレージのレイテンシー、バックグラウンドの書き込みを、それぞれ別のイベントとして測定します。その後、競合するジョブを1つ停止するか、リクエストの変数を1つ変更して再測定してください。

短いJellyfinクライアントの挙動確認手順を使えば、その症状がデータベース処理、画像の経路、クライアントUIのどこに属するのかを判断できます。

別の原因を取り除くことでベースラインに戻るなら、遅延をライブラリの増加だけに結び付けるのはやめましょう。増加は条件であり、制限要因については依然として証拠が必要です。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.