別のコンテナを起動すると、なぜJellyfinのパフォーマンスが変化するのですか？

別のコンテナが起動するとJellyfinのパフォーマンスが変化することがあります。これは、コンテナの分離によってCPU、メモリ、ストレージ、ネットワーク、アクセラレーターの容量まで別々になるわけではないためです。

ホームサーバーでは、バックアップ、ダウンローダー、写真インデクサー、データベース、AIコンテナが通常の処理を始めるまで、Jellyfinが快適に動作することがあります。重要なのは「Dockerが遅い」と考えることではなく、共有リソースのどれが十分な余裕を失い、Jellyfinのレイテンシーやスループットを変化させたのかを特定することです。処理の重複を再現し、制約されているリソースを特定してから、ハードウェアを追加する前に、その境界だけを変更します。

根本原因はコンテナ数ではなく、共有ホスト容量

コンテナはプロセスと設定を分離しますが、リソースを意図的に分離しない限り、同じ物理ホスト上で実行されます。そのため、新たにアクティブになったワークロードは、アプリケーションレベルの依存関係がない場合でも、Jellyfinとスケジューラー時間、メモリ帯域幅、ページキャッシュ、ストレージキュー、NIC容量、アクセラレーターを奪い合う可能性があります。

Dockerのリソース制限に関するガイダンスでは、デフォルトの動作が明確に示されています。無制限のコンテナは、カーネルやその他の制御機構によって抑制されるまで、ホストのCPUとメモリを使用できます。そのため、無制限のリソース使用が、問題のないバックグラウンドタスクを他のワークロードに悪影響を与える処理へと変えてしまうことがあります。

障害の境界は、アーキテクチャではなく測定によって判断できます。2つ目のコンテナが起動してもJellyfinに十分なリソース余裕があるなら、再生は安定しているはずです。一方、特定のリソースが飽和し、そのワークロードを停止するとJellyfinが回復するなら、競合が有力な説明になります。コンテナ数だけでは何も証明できません。

速度低下を引き起こす4つの原因

同一ホストへの配置によって繰り返し発生する速度低下の大半は、CPUスケジューリング、メモリ圧迫、ストレージ競合、ネットワークまたはアクセラレーターの共有という4つに分類できます。制限を調整する前に症状を分類してください。分類ごとに現れる兆候も、安全な対処方法も異なるためです。

実用的なDockerリソースガイドでは、CPU、メモリ、GPU、ディスクI/O、監視を、1つの汎用的な「コンテナパフォーマンス」設定ではなく、個別の制御項目として扱っています。この分離は有用です。サブシステムごとのリソース制限によって、他の要因を隠すことなく、疑わしいボトルネックを検証できるからです。

以下の兆候は、断定ではなく仮説として利用してください。競合するコンテナがアクティブな状態でJellyfinの劣化を再現し、同時に対応するホスト指標が変化することを観測して、原因を1つずつ確認します。

原因1：CPUスケジューリングと共有キャッシュへの負荷

• 仕組み：競合するワークロードが実行可能なCPU時間を消費するか、コンテキストスイッチやキャッシュ圧迫を十分に発生させ、Jellyfinの処理を遅延させます。
• 症状の特徴：CPUの飽和やスロットリングが上昇する一方で、初回フレームまでの時間、ソフトウェアトランスコード速度、メタデータ応答、字幕処理が悪化します。
• IF–THEN：競合するCPUワークロードを制限または再スケジュールすることでJellyfinが回復し、ストレージとネットワークが正常なままなら、CPU競合が確認されたと判断します。

原因2：メモリ回収またはスワップ

• 仕組み：2つ目のコンテナがワーキングセットを拡大させ、ホストがキャッシュを回収したり、スワップを使用したり、OOM状態に近づいたりします。
• 症状の特徴：Jellyfinが断続的に遅くなり、データベースやメタデータの読み取りで、ウォームキャッシュによる高速化が失われます。速度低下の前にメモリ圧迫が上昇します。
• IF–THEN：競合するサービスにメモリ上限を設定することで、メモリ回収やスワップの圧力がなくなり、Jellyfinのレイテンシーが正常化するなら、メモリが制御すべき境界です。

原因3：ストレージキューの競合

• 仕組み：バックアップ、ダウンロード、展開、インデックス作成、データベース書き込みが、Jellyfinの状態データやメディア読み取りと同じデバイスまたはファイルシステムのキューを共有します。
• 症状の特徴：CPUが部分的にアイドル状態でも、I/O待ち時間とストレージレイテンシーが上昇します。I/O待ちによってストレージ競合が明らかになるため、1つの負荷の大きいコンテナだけでホスト全体が遅く感じられることがあります。
• IF–THEN：競合するI/Oを制限または移動することで、シーク、参照、データベースのレイテンシーが解消するなら、CPUを増設するのではなく、ストレージキューを改善します。

原因4：ネットワークまたはアクセラレーターの共有

• 仕組み：別のサービスが、Jellyfinに必要な同じアップリンク、ブリッジ経路、GPU、メディアエンジン、デバイス帯域幅を消費します。
• 症状の特徴：一般的なCPUやディスクの指標が許容範囲でも、リモート転送速度、トランスコード速度、ハードウェアアクセラレーションを利用するセッションが悪化します。
• IF–THEN：ネットワーク転送またはアクセラレーターを使用するワークロードを分離することでJellyfinが回復し、他の指標に変化がないなら、その共有境界に制御を設けます。

障害の境界：競合とJellyfin固有の不具合を区別する

起動時刻の相関だけでは、根拠として弱いものです。2つ目のコンテナが起動したのと同時に、Jellyfinがライブラリースキャンを開始したり、クライアントが互換性のないトランスコードを要求したり、メディアマウントが停止したり、データベース処理が実行されたりする可能性もあります。競合するワークロードを停止でき、再現性が確認できるまでは、そのワークロードを原因と判断すべきではありません。

ホストレベルのリソースガイダンスでは、ノイジーネイバー問題を、あるワークロードがCPU、メモリ、PID、I/Oを通じて別のワークロードを圧迫する問題として説明しています。つまり、影響を受けたリソースを観測できる必要があります。他のコンテナを停止して疑わしい指標が正常に戻った後もJellyfinが遅いままなら、調査対象をJellyfin本体、クライアント、メディアパス、コーデックの挙動に戻します。

また、ダイレクトプレイとトランスコード、ローカル再生とリモート再生を比較してください。特定のメディア経路でのみ速度低下が発生する場合は、一般的なホスト競合よりも、Jellyfin固有のデコード、字幕、クライアント、配信の問題である可能性が高くなります。障害の境界を越えたと判断できるのは、同じ競合ワークロードが、同じリソースと同じJellyfinの症状を予測可能な形で変化させた場合だけです。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ホストを変更する前に、1変数の競合テストを実行する

まず、代表的なJellyfinセッションを1つだけ実行した静かな状態を基準として記録します。次に、疑わしい隣接ワークロードだけを起動し、CPU、メモリ圧迫、ストレージレイテンシーまたはI/O待ち時間、ネットワークスループット、アクセラレーター使用率、Jellyfinの症状を記録します。そのワークロードを停止し、指標とユーザーに見える挙動の両方が回復することを確認します。結果を受け入れる前に、もう一度繰り返してください。

ZimaSpaceによる最初に限界へ達するリソースの分析は、次の手順を示しています。すべてのコンポーネントをアップグレードするのではなく、まず継続的な余裕を失ったリソースを改善します。CPUまたはメモリ制限を適用し、I/Oのスケジュールを変更し、ストレージパスを分離し、転送を制御し、またはアクセラレーター負荷の高いタスクを移動してから、同じテストを再実行します。

1つの制御された変更によって、別のボトルネックを生じさせずに、再現性のある速度低下が解消されれば、診断は完了です。症状に合わせて変化するリソースがない場合は、競合の仮説を退け、Jellyfin自体を調査します。この停止ルールにより、通常のコンテナ起動が、無関係な再生問題すべての説明になってしまうのを防げます。

1. Jellyfin単体の基準値を記録する。
2. 疑わしいコンテナのワークロードを1つ起動する。
3. 症状を1つのリソース指標と照合する。
4. ワークロードを停止し、回復を確認する。
5. 1つの制限、スケジュール、または配置境界を変更する。
6. ハードウェアを購入する前に、同じJellyfinテストを繰り返す。