8

3 枚のビデオ カードからビデオをキャプチャして表示するプログラムを作成しました。フレームごとに、フレームを Jpeg に圧縮し、ディスクに書き込むためにキューに入れるスレッドを生成します。これらのファイルから読み取り、独自のスレッドでデコードする他のスレッドもあります。通常、これは問題なく動作します。これは、6 つの CPU コアすべての約 70 ～ 80% を使用する、かなり CPU を集中的に使用するプログラムです。しかし、しばらくすると、エンコーディングが突然遅くなり、プログラムはビデオを十分に速く処理できなくなり、フレームを落とし始めます。CPU 使用率を確認すると、1 つのコア (通常はコア 5) があまり機能していないことがわかります。

これが発生した場合、プログラムを終了して再起動しても問題ありません。CPU 5 の使用率は依然として低く、プログラムはすぐにフレームのドロップを開始します。保存したビデオをすべて削除しても効果はありません。コンピューターを再起動することが唯一の解決策です。ああ、プログラムのアフィニティをセミアイドリングコア以外のすべてを使用するように設定すると、別のコアで同じことが起こるまで機能します。これが私のセットアップです：

  • AMD X6 1055T (クール & 静音 OFF)
  • GA-790FX-UD5 マザーボード
  • 4Gig RAM アンギャングド 1333Mhz'
  • Blackmagic Decklink DUO キャプチャー カード (x2)
  • Linux - カーネル 2.6.32.29 を搭載した Ubuntu x64 10.10

私のアプリは以下を使用します：

  • libjpeg-ターボ
  • posix スレッド
  • デッキリンク API
  • Qt
  • C/C++ で書かれています
  • 動的にリンクされたすべてのライブラリ

Linux がコア上でスレッドをスケジュールする方法に何らかの問題があるように思えます。または、私のプログラムがひどく混乱して、プログラムを再起動するのに役立たない方法はありますか?

読んでくれてありがとう、どんな入力でも大歓迎です。私は立ち往生しています:)

4

2 に答える 2

4

まず第一に、それがあなたのプログラムではないことを確認してください。おそらく、複雑な同時実行バグに遭遇している可能性があります.プログラムのアーキテクチャとカーネルの再起動が役立つという事実では、それほど可能性は高くありません. 通常、良い方法は事後分析のデバッグであることがわかりました。デバッグ シンボルを使用してコンパイルし、動作がおかしい場合は -SEGV でプログラムを強制終了し、gdb でコア ダンプを調べます。

于 2011-10-02T13:11:50.677 に答える
2

新しいフレーム処理スレッドが生成されたときにコア ラウンド ロビン a を選択し、スレッドをこのコアに固定しようとします。スレッドの実行にかかる時間に関する統計を保持します。これが実際に Linux スケジューラのバグである場合、スレッドはどのコアでも実行するのにほぼ同じ時間がかかります。コアが実際に他の何かでビジーである場合、このコアに固定されたスレッドの CPU 時間は少なくなります。

于 2011-10-02T18:24:58.853 に答える