Jellyfinが現在のホームサーバーでは手狭になったサイン

エヴァ・ウォン

IceWhale author

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

Signs That Jellyfin Has Outgrown Its Current Home Server - Zima Store Online

通常のワークロードでパフォーマンス目標を繰り返し達成できず、クライアント、ストレージパス、設定の問題を切り分けた後もボトルネックがサーバーに残るなら、Jellyfinはホームサーバーの処理能力を超えています。

CPUスパイクが1回発生した、スキャンが遅かった、再生中に一度バッファリングした、といった事象だけで新しいハードウェアが必要だと判断しないでください。ライブラリの閲覧、スケジュールされたメンテナンス、ダイレクトプレイ、代表的なトランスコードなど、毎回同じ負荷を発生させてください。そのうえで、どのリソースが飽和しているか、また低リスクな設定変更で症状が解消するかを確認します。

通常の負荷で再現性のある障害を探す

最も強い兆候は再発です。Jellyfinが遅く感じるのが、異常に大規模なフルスキャン中や再起動直後だけなら、ホストの処理能力はまだ十分かもしれません。同じストリーム数で毎晩同じ遅延が発生する場合や、スケジュールされたタスクの時間帯になるたびにUIが停止する場合は、容量の限界が運用上無視できないものになっています。

Jellyfinのトラブルシューティングでは、ログを使ってサーバー側の再生・トランスコード障害と、サーバーに到達する前に発生している問題を区別することが推奨されています。そのため、ハードウェアを購入する前の最初の切り分け手段としてログが役立ちます。Jellyfinのトラブルシューティングログ

2～3回繰り返し実行し、発生条件、経過時間、CPU使用率、メモリ負荷、ディスクレイテンシ、再生モードを記録してください。発生条件を変えると症状も変わるなら、ワークロード固有の限界です。どの操作でも症状が発生するなら、まずストレージまたはデータベースの状態を確認します。

トランスコードの限界と、サーバー全体の遅さを切り分ける

再生に失敗しているストリーム中にJellyfinのダッシュボードを開き、クライアントがダイレクトプレイ、ダイレクトストリーミング、リマックス、トランスコードのどれを使用しているか確認します。ダイレクトプレイの計算負荷は動画のトランスコードに比べて非常に小さいため、再生モードによって「処理能力を超えた」の意味は変わります。

Jellyfinの説明では、ダイレクトプレイは最も負荷が低い経路で、動画のトランスコードは最も負荷が高い経路です。また、トランスコードが要求されるタイミングはクライアントの対応能力によって決まります。再生モードとトランスコードの動作

1つ以上のトランスコードを開始したときだけホストが使用不能になるなら、サーバーを交換する前にハードウェアアクセラレーションとクライアントの互換性を確認してください。ハードウェアトランスコードの確認により、既存のGPUまたはiGPUに未使用の余力があるかどうかを確認できます。

メタデータとデータベース処理が余裕を消費していないか確認する

メディアをスムーズに再生できても、検索、大規模なコレクションの表示、メタデータの更新時に次第に動作が重くなることがあります。これは純粋なトランスコードの限界ではなく、データ層、ストレージレイテンシ、またはメモリ競合の問題である可能性があります。

現在のJellyfinリリースでは、ライブラリデータベースの大部分をメモリにキャッシュできます。10.11のリリースノートでは、このキャッシュがデータベースのサイズまで増加する可能性があり、大規模なライブラリではRAM使用量が多く見える場合があると説明されています。データベースのメモリキャッシュ

障害の兆候は継続的な負荷です。スワップが発生する、キャッシュが十分に温まった後も検索が遅い、通常の利用中に他のコンテナがメモリ不足で追い出される、といった状態です。遅延を伴わない高いキャッシュ使用量だけでは、アップグレードの理由にはなりません。

-15% OFF

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

Single board computer zimaboard2

ストレージのキューイングとネットワークマウントの遅延を切り分ける

スキャン中にUIが停止する、再生開始まで時間がかかる、ディスクが飽和したままになる、といった場合は、メディアストレージがアイドル状態のときとスキャン実行中でJellyfinを比較してください。ライブラリがローカルとネットワーク共有の両方にまたがっている場合は、ローカルのテスト項目とネットワーク共有上の項目も比較します。

Jellyfinでは、データベースをローカルストレージに置き、SambaまたはNFS共有をオペレーティングシステムに直接マウントすることが推奨されています。Jellyfinのストレージガイダンスネットワークマウントが遅い、または断続的に利用できない場合、ホストのCPUやRAMを増設しても、その経路の遅延は解消しません。

メディアパスをより高速または安定したマウントへ移すとボトルネックが消えるなら、サーバー自体の処理能力を超えていたわけではありません。ローカルストレージも通常のライブラリ処理で飽和するなら、拡張が必要なリソースはストレージ構成またはIOPSである可能性があります。

サーバーの限界と判断する前にクライアントまたはネットワークの問題を除外する

同じメディアのテストをLAN上の別のクライアントから繰り返してください。一方のデバイスではバッファリングが発生し、別のデバイスでは同じファイルをダイレクトプレイできるなら、サーバーは正常で、最初のクライアントが異なるコーデック経路、ビットレート、またはネットワーク経路を要求している可能性があります。

Jellyfinはクライアントごとのコーデック動作を管理しており、対応していないコーデックや字幕によって変換が強制される場合があります。クライアントのコーデック対応したがって、1台のクライアントで発生した障害をホスト全体の処理能力の結論に一般化すべきではありません。

ネットワークスループットをサーバーの限界とみなすのは、複数のクライアントでサーバーのNICまたはアップリンクが飽和していることを確認してからにしてください。Wi-Fiの混雑、遠隔ISP経路、または性能の低いエンドポイント1台の問題は別のものであり、その層で解決すべきです。

調整、拡張、ワークロード分割のどれを行うか決める

症状の原因が1つの設定またはワークロードに絞れるなら、まず調整します。検証済みのハードウェアアクセラレーションを有効にする、負荷の高いスキャンをピーク時間帯から移動する、不要なメタデータ処理を減らす、遅いストレージマウントを分離する、といった方法があります。変更するたびに、まったく同じ発生条件でテストを再実行してください。

同じ目標を引き続き達成できず、飽和しているリソースが明確なら、ハードウェアを拡張します。必要なソフトウェアトランスコードにはCPU、継続的なメモリ負荷にはRAM、データベースの遅延にはより高速なローカルストレージ、確認済みのスループット限界にはより優れたネットワーク経路が必要です。ベンチマークで複数の独立した限界が示されない限り、複数のリソースを同時にアップグレードするのは避けてください。

単一ホストで複合的なサービス需要を安定して満たせない場合に限り、ワークロードを分割します。再起動後に元のピーク負荷でベンチマークを通過できた時点で終了してください。その結果は、Jellyfinサーバーが「本来どれほど高性能であるべきか」という一般論よりも、はるかに強い根拠になります。