1台のPlexホストに安全な同時実行数の上限を設定する方法
Plexホストは、普遍的なストリーム数ではなく、測定した同時実行予算に収まるユーザー数とバックグラウンドジョブ数を支えられる構成にすべきです。
ダイレクト再生、ハードウェアトランスコード、ソフトウェアトランスコード、スキャン、バックアップ、コンパニオンコンテナは、それぞれ異なるリソースに負荷をかけます。自宅で実際に重なる組み合わせを基に予算を組み、いずれかのリソースがユーザーに見える障害のしきい値へ繰り返し達した時点で、処理の追加を止めます。
ユーザー数を数える前にセッションの種類を分ける
ダイレクト再生のユーザー1人と、4Kソフトウェアトランスコードのユーザー1人は、サーバーへの負荷が同じではありません。クライアントの互換性や字幕の挙動によって、同じメディアでも軽いネットワーク・ストレージ処理から重い演算処理へ変わることがあります。
特定のテスト環境では、N100は比較的低いCPU負荷で複数のハードウェアトランスコードを同時に処理できました。ただし、この結果を一般的なユーザー上限として扱うべきではありません。
想定される最も忙しいセッションを、ダイレクト再生、ハードウェアトランスコード、ソフトウェアトランスコードに分類します。セッションが実際にどのリソース経路を消費するのかを把握してから、ユーザー数を数えてください。
バックグラウンドジョブも同じピークテストに加える
ライブラリのスキャン、ダウンロード、バックアップ、その他のコンテナによって、再生テストに合格したホストでもリソース競合が発生することがあります。そのため、同時実行予算には視聴者とジョブの両方を含める必要があります。
ホームラボ向けのリソース制御が存在するのは、そうしなければ1つのコンテナが利用可能なCPU、メモリ、またはブロックI/Oを消費し、他のサービスの応答性も維持する必要があるためです。
通常のバックグラウンドタスクを1つ実行しながら、想定する視聴者構成でテストします。その後、そのタスクを一時停止して再度テストしてください。その差から、単にCPUコアを増やすよりも、スケジューリングや分離のほうが有効かどうかが分かります。
メンテナンスと復旧のための余裕を確保する
再生のピークをかろうじて処理できるだけのホストには、アップデート、データベースのメンテナンス、バックアップ、一時的なソフトウェアトランスコードへのフォールバックに対応する余裕がありません。これは、ストリームが途切れ始める前から存在する運用上の限界です。
リソースごとの飽和度チェックによって、予算に測定可能な停止条件を設定できます。必要な処理が重なる間、CPU、メモリ、ストレージ、ネットワークでキューの滞留やエラーが継続する場合を基準にします。
再生の安定性、タスクの完了、復旧時間について合格条件を定義します。通常のメンテナンスジョブを1つ実行しただけで、サーバーがその境界を超えないよう十分な余裕を残してください。
予算がきれいに拡張できなくなったら役割を分ける
1台のホストにユーザーを追加し続けることが、常に最善の次の一手とは限りません。ストレージ、バックアップ、または負荷の高いコンパニオンサービスが繰り返し制約になる場合は、マシン全体を交換するよりも、その役割を分離するほうが効果的です。
したがって、Plexのハードウェア要件には、単一の「最大ユーザー数」ではなく、ストリーム構成、アプリデータの経路、ネットワーク、コンパニオンワークロードを含めるべきです。
統合テストが合意した範囲内に収まっている間は、1台のホストを使い続けます。同じ測定上のボトルネックが続き、両方のワークロードを同時に実行する必要がある場合は、コンピュートまたはストレージを分離してください。
おすすめ商品
NAS＆サーバー設定
もっと読む
AIに似た分析と自動化がJellyfinのストレージおよびコンピューティング要件をどう変えるか
自動化と関連するAI分析では、通常のJellyfin再生に加えて、スキャン、派生データ、CPU/GPU処理、キャッシュ、作業用領域、バックグラウンドスケジューリングが追加されます。
小さなアパートや賃貸住宅のネットワークにJellyfinを統合する方法
安定したローカルアドレス、最小限の配線、静音ハードウェア、CGNATを考慮したリモートアクセス、そして元に戻せる変更を軸に、賃貸住宅に適したJellyfinネットワークを構築しましょう。
1台のJellyfinホストでサポートできるユーザー数とバックグラウンドジョブ数はどれくらいですか？
Jellyfinユーザーとバックグラウンドジョブを1つの共有ワークロード予算として扱い、再生遅延、キュー、またはリソース圧迫が繰り返し発生した時点で容量の限界とします。
