1台のホストでJellyfinライブラリはどこまで大きくできる？

エヴァ・ウォン

IceWhale author

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

How Large Can a Jellyfin Library Grow on a Single Host? - Zima Store Online

1台のホストが「限界」に達したことを示す、Jellyfinの項目数に関する普遍的で実用的な上限はありません。実際の限界は、データベース、メモリ、ストレージ、スケジュール済みジョブ、同時再生のいずれかが、目標とする応答時間を維持できなくなった時点です。

映画の本数が同じ2つのライブラリでも、メタデータの密度、チャプター画像、トリックプレイデータ、ネットワークストレージ、クライアントの種類、トランスコードの需要が異なるため、サーバーへの負荷は大きく変わります。実際のワークロードでホストを測定し、ライブラリを大幅に拡張するたびに再現できる境界値を定めてください。

メディアファイル数ではなく、まずデータベースの容量を確認する

Jellyfinはライブラリの状態をデータベースに保存し、メディアファイル自体はファイルシステムに残します。カタログが増えるにつれて、最初に確認すべき指標は、映画ファイル全体のテラバイト数ではなく、Jellyfinのデータセットのサイズと動作です。

Jellyfinのストレージに関するドキュメントでは、中規模のライブラリのデータベースが約10～100 GBに達する場合があると説明されており、データベースはネットワーク共有ではなくローカルストレージに保存することを推奨しています。データベースストレージのガイダンス

データベースのサイズ、データボリュームの空き容量、キャッシュが温まった後に大規模なライブラリ画面を開いたり検索したりするのにかかる時間を記録してください。メディア容量が増えてもこれらが安定しているなら、メディアの総容量だけでアプリケーションが1台のホストの限界を超えたわけではありません。

データベースが温まった後のメモリ余力を測定する

現在のJellyfinでは、ディスク読み取りを減らすために大量のデータベースデータをメモリに保持できるため、メモリの動作がより重要になります。そのため、ライブラリが小さいときは余裕があったホストでも、ライブラリの拡大後には定常状態のRAM使用量が増えることがあります。

Jellyfin 10.11のリリースノートでは、データベースエンジンがメタデータをメモリに積極的にキャッシュし、ライブラリデータベースのサイズに相当する量までメモリを使用する場合がある一方、他のプロセスが必要とするとメモリを解放すると説明されています。メモリ上のデータベースキャッシュ

通常のブラウジングでキャッシュが温まった後、利用可能なメモリとスワップの動作を確認してください。警告すべきなのは、キャッシュ使用量が多いこと自体ではありません。持続的なメモリ圧迫、スワップの発生、またはJellyfinが他のコンテナと競合したときに現れ、競合を取り除くと消える遅延が問題です。

ライブラリの増加に伴って長くなるバックグラウンド処理の時間を測定する

ライブラリのスキャン、メタデータの更新、画像の抽出、字幕処理、その他のスケジュール済みジョブは、再生がスムーズな場合でも最初のスケール上限になることがあります。これらのジョブにかかる時間と、実際にサーバーを利用する時間帯と重なっているかを測定してください。

チャプター画像の抽出は、Jellyfinが直接的なスケーリングコストを説明している例の1つです。ライブラリスキャン中に抽出を有効にすると、特に大規模なライブラリではスキャンが大幅に遅くなることがあります。チャプター画像スキャンのコスト

フルスキャンがメンテナンス時間の大部分を占めるようになった場合は、まず不要な処理を減らすか、高負荷のタスクをピーク時間外に移してください。スキャン時間が長くなったからといって、必ずしもホストの性能が不足しているとは限りません。メンテナンスがインタラクティブな利用と繰り返し衝突する場合や、安定して完了しなくなった場合に、容量の問題になります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

ライブラリの規模とトランスコードの規模を分けて考える

非常に大きなカタログでも、ダイレクト再生のストリームには必ずしも大きな負荷がかかるとは限りません。一方で、小規模なカタログでも、互換性のないクライアントが複数同時にビデオのトランスコードを要求すると、CPUに過大な負荷がかかることがあります。カタログの規模と再生変換は、別々の容量テストとして扱ってください。

実際に使用するクライアント構成で、再現可能な再生ベンチマークを実施してください。ダイレクト再生を1本、通常利用するトランスコードを1本、その後に想定する同時再生のピークを測定します。カタログが増えてもこれらの再生テストの結果が変わらないなら、ライブラリの規模が原因でトランスコードの上限に達したわけではありません。

CPUの飽和がトランスコード中にだけ発生する場合は、データベースを疑う前に、コーデック、ハードウェアアクセラレーション、クライアントの互換性を調整してください。健全なメタデータデータベースを2台目のサーバーへ移すよりも、ハードウェアアクセラレーションガイドを次に確認する方が適切です。

スキャン負荷の下でストレージの遅延とメディアの可用性を確認する

大規模なライブラリは複数のディスクやNASにまたがることが多く、メディアまでの経路がボトルネックになる場合があります。ライブラリスキャンの実行中と停止中で、インタラクティブなブラウジングと再生を比較し、メディア経路上のディスクキューやネットワーク共有の遅延を確認してください。

Jellyfinは、SambaまたはNFSストレージをOSに直接マウントすることを推奨しています。また、スケジュール済みのメンテナンス実行時にストレージが利用できないと、ライブラリ項目が削除される可能性があると警告しています。ネットワークストレージとメンテナンスに関する注意

データベースが高速でも、メディアディレクトリが断続的に消えたり、メタデータスキャンが遅い共有先で停止したりする場合、CPUを追加しても本当のボトルネックは解消しません。まずマウントの信頼性、ストレージの遅延、ジョブの実行時間を改善し、その後に同じベンチマークを再度実施してください。

再現可能なベンチマークで自分の1台構成の限界を定める

次にライブラリを拡張する前に、測定項目をまとめた簡単なスコアカードを作成してください。キャッシュが温まった状態での検索遅延、大規模なコレクションを開くまでの時間、フルスキャンの所要時間、データベースサイズ、利用可能なRAM、ストレージ遅延のピーク値、代表的な同時再生テストを記録します。毎回同じ測定を行ってください。

実用的なホームメディアセンターのワークフローでは、メディアストレージとJellyfinのアプリケーション層をすでに分離しています。ベンチマークでもこの分離を維持し、遅延の原因がホスト、ストレージ経路、クライアントのどれにあるのかを把握できるようにしてください。

低リスクの調整を行った後も測定した目標を繰り返し達成できない場合にのみ、1台のホストが限界を超えたと判断してください。具体的には、インタラクティブなリクエストが遅いまま、スキャンがメンテナンス時間内に完了しない、メモリ圧迫によってスワップが発生する、ストレージ遅延を切り分けられない、または必要なトランスコードが利用可能な計算能力を超える場合です。その時点で、証拠に基づいて拡張すべきリソースが分かるため、任意の項目数上限を無理に設定する必要はありません。