なぜメディアサーバーが遅いのか?ストレージ、ネットワーク、またはCPUのボトルネックの見つけ方

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

遅いメディアサーバーが必ずしもCPUの問題とは限りません。セッションがDirect Play、Direct Stream、またはTranscodingのどれを使用しているかをまず確認してください。各モードは再生経路の異なる部分を活性化します。

実際の経路は、ソースファイルからストレージ、サーバー処理、ネットワーク配信、クライアントのデコードへと進みます。ボトルネックは、現在のセッションが必要とする余裕よりも少ないリソースしか利用できないアクティブな段階で発生します。

メディアサーバーのボトルネックが実際に意味すること

メディアサーバーのボトルネックとは、現在の再生要求に追いつけない段階のことです。その段階はストレージ、ネットワーク、CPU、GPU、クライアントデバイス、またはバックグラウンドタスクの組み合わせかもしれません。

同じサーバーでも2つのファイルで異なる動作をします。互換性のあるファイルはほとんどサーバー処理なしで直接再生されますが、別のファイルはビデオ変換、オーディオ変換、字幕レンダリング、または解像度スケーリングを引き起こすことがあります。

そのため、アクティブな再生経路を特定する前にコンポーネントをアップグレードしても、ほとんど改善が見られないことがよくあります。目に見える症状はバッファリングかもしれませんが、根本原因は互換性のないクライアント、リモートアップロード制限、混雑したストレージプール、またはソフトウェアトランスコードかもしれません。

再生モードから始めましょう

CPUの確認やハードドライブの交換を行う前に、メディアサーバーのダッシュボードで現在のセッションを確認してください。最も重要な違いは、サーバーが元のファイルをそのまま通すか、クライアント用に変換しているかです。

基本的なDirect Play、Direct Stream、Transcodingの定義は、サーバーの関与レベルの違いを説明しています。

  • ダイレクトプレイ:クライアントがファイルをサポートし、サーバーはほとんど処理せずに送信します。
  • ダイレクトストリーム:ビデオとオーディオは変更されず、コンテナのみが再パッケージされます。
  • トランスコーディング:サーバーが互換性のないビデオ、オーディオ、字幕、または解像度設定を変換します。

同じファイルがクライアントごとに異なる動作をする場合、Direct Playとハードウェアトランスコーディングのトレードオフがより重要になります。

ストレージがボトルネックの場合

複数のストリーム、ライブラリスキャン、サムネイル生成、バックアップ、またはディスクアクセスを競合する他のタスク中に再生が遅くなる場合、ストレージがより強い疑いの対象となります。

メディアファイルとトランスコードディレクトリはパスの別の部分です。高速なソースドライブでも、一時セグメントが遅いまたは競合の激しい場所に書き込まれている場合は高速なトランスコーディングは保証されません。

問題を再現しながらディスクのアクティビティ、レイテンシ、キューの挙動を監視してください。連続スループットテストは有用ですが、複数のユーザー、コンテナ、バックグラウンドジョブが同時にアクセスする際のストレージプールの挙動は示しません。

バックグラウンドサービスはディスクの競合を増やす可能性があるため、NASアプリのパフォーマンスへの影響をハードウェアを変更する前に確認する価値があります。

ネットワークがボトルネックの場合

ネットワークの問題は、サーバーとクライアント間の完全な経路に依存します。サーバーの高速ネットワークポートは、クライアントが弱いWi-Fi、制限されたインターフェース、または混雑した経路で接続されている場合には役に立ちません。

ローカル再生の場合は、有線クライアントと同じクライアントのWi-Fi接続を比較してください。リモート再生の場合は、サーバーがストリームを送信してからリモートクライアントが受信できるため、サーバーの実際のアップロード速度を測定してください。

平均ビデオビットレートだけでは計画に十分でないことがあります。可変ビットレートのビデオは平均の数倍に達する短いピークを生み出すことがあり、異なるクライアントは異なるバッファの余裕を必要とする場合があります。文書化された実際のアップロード速度とビットレート制限は、平均ビットレートだけでは誤解を招く理由を説明しています。

より高速なネットワークリンクでも遅く感じる場合は、10GbE NASのボトルネックパスが、ネットワークリンクとその背後にあるストレージ、クライアント、プロトコル層を分離するのに役立ちます。

CPUまたはハードウェアトランスコーディングがボトルネックの場合

ソフトウェアトランスコーディングは、特にサーバーが解像度を変更したり、あるフォーマットをデコードして別のフォーマットをエンコードしたり、複数のストリームを同時に処理したりする場合に、かなりのCPU容量を消費することがあります。

ハードウェアアクセラレーションは一部の作業を統合または専用GPUに移すことができるが、すべての段階が加速される保証はない。デコード、スケーリング、HDRトーンマッピング、字幕の焼き込み、エンコードは異なる経路を使う場合がある。

サーバーダッシュボードとログを確認し、ハードウェアアクセラレーションが実際に有効かを確かめる。文書化されたハードウェアアクセラレーション段階は、部分的なアクセラレーションでもCPU負荷が高いままになる理由を示している。

プロセッサ自体が弱すぎると決めつける前に、ドライバーの問題、コンテナの権限、非対応フォーマット、HDR変換、字幕レンダリングを確認する。新しいCPUが役立つ場合もあるが、アクティブなソフトウェアパスが検証された後に限る。

クライアントがサーバーのボトルネックを作ることがある

クライアントデバイスはDirect Playセッションをトランスコーディングセッションに変えることがある。トリガーは、対応していないビデオコーデック、オーディオ形式、コンテナ、字幕タイプ、解像度、またはビットレートかもしれない。

これが、同じファイルがあるテレビ、ストリーミングボックス、ブラウザ、またはスマホではスムーズに再生されるのに、別のデバイスではバッファリングする理由である。その場合、クライアントがローカルで処理できない作業をサーバーが行っているため、サーバーが問題のように見えることがある。

同じファイルを2台目のクライアントでテストし、再生モードを比較する。1台だけが失敗する場合は、そのデバイスのネットワーク接続、アプリ設定、対応フォーマット、オーディオ経路、字幕の挙動を調べてからサーバーのアップグレードを検討する。

実用的な分離シーケンス

最も信頼できる診断は、一度に1つの変数を変更すること。ファイル、サーバー、再生位置を一定に保ちつつ、クライアント、接続、字幕、トランスコーディングモードをテストする。

  1. ファイルの解像度、コーデック、オーディオ形式、字幕形式、およびおおよそのビットレートを記録する。
  2. セッションがDirect Play、Direct Stream、またはトランスコーディングかを確認する。
  3. 字幕を無効にして同じファイルを再生する。
  4. 2台目のクライアントデバイスまたはアプリケーションをテストする。
  5. 有線再生とWi-Fi再生を比較する。
  6. 障害発生時にCPU、GPU、ディスクの活動、遅延、ネットワークスループットを監視する。
  7. 共有リソースの制限を明らかにするために、ストリームを1つ追加するかバックグラウンドタスクを増やしてテストを繰り返す。
再生の症状 最初のテスト ボトルネックの可能性が高い 信号を確認中
クライアントが1台のみ、またはファイルがバッファリングされる クライアントを切り替えるか字幕を無効にする クライアントの互換性または強制トランスコーディング 再生モードが変わるか、2台目のクライアントがスムーズになる
ローカルの有線再生は動作するがWi-Fiは失敗する 2つのネットワーク経路を比較する 無線のスループット、干渉、または遅延 同じファイルとサーバー負荷で有線再生は安定している
Direct Playはスムーズだがトランスコーディングはバッファリングする CPU、GPU、およびトランスコード用ストレージを確認する ソフトウェアトランスコーディング、エンコーダー容量、または一時的なI/O ハードウェアアクセラレーションまたはより単純なストリームでリアルタイム再生が回復する
複数のユーザーが同時に失敗する 単一ストリームとマルチストリームの挙動を比較する 共有ネットワーク、ストレージ、または計算余裕 問題は同時接続数が増えた後にのみ発生する

これらのテストで制限段階が特定された後にのみ、メディアサーバーのハードウェア要件を比較してください。

よくある質問

CPUより先にネットワークを疑うのはどんな時ですか?

Direct Playがバッファリングし、有線再生がWi-Fiよりスムーズで、リモート再生が失敗しローカル再生が成功し、ストリームのビットレートを下げるとすぐに再生が改善する場合はネットワークを疑ってください。

Direct Playでもバッファリングする場合はどうすればいいですか?

クライアント接続、ストレージ読み取り経路、ディスク遅延、ファイルのビットレートピーク、バックグラウンドタスクを確認してください。Direct Playはほとんどのサーバー変換作業を除去しますが、ネットワークやストレージの負荷は除去しません。

字幕は完全なトランスコードを引き起こすことがありますか?

はい。互換性のない字幕形式は動画に焼き付ける必要があり、元の音声と映像が互換性があっても完全なビデオトランスコーディング経路を起動することがあります。

SSDは常にトランスコーディングを解決しますか?

いいえ。SSDは一時的なトランスコードセグメントやメタデータアクセスがディスクI/Oによって制限されている場合に役立ちますが、サポートされていないコーデック、CPUやGPUの容量不足、ネットワーク経路の不足は解決しません。

どのようにしてクライアントが問題かどうかを判断できますか?

同じネットワーク上の別のクライアントで同じファイルを再生してください。2台目のデバイスがDirect Playを使用してスムーズに再生される場合は、元のクライアントのコーデックサポート、アプリ設定、オーディオ経路、字幕、ネットワーク接続を確認してください。

最終的な結論

再生モードから始めて、アクティブな経路を追跡し、1層ずつ測定します。ストレージ、ネットワーク、CPU、GPU、クライアントのいずれもボトルネックになる可能性がありますが、現在のセッションの需要を下回る余裕がある段階だけが次のアップグレードを決定します。

製品比較

もっと読む

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.