問題タブ [context-switch]

AzureでServiceBusを実行しており、1秒あたり約10〜100のメッセージを送信しています。

最近、私は.net 4.5に切り替え、すべてのコードをリファクタリングして、各行で「async」と「await 」を少なくとも2回実行し、「正しく」行われたことを確認しました:)

今、私はそれが実際に良いのか悪いのか疑問に思っています。コードスニペットを見て、あなたの考えを教えてください。私は特に、スレッドコンテキストの切り替えが、すべての非同期性から、利益よりも悲しみを与えていないかどうかを心配していました...（！dumpheapを見ると、それは間違いなく要因です）

少し説明します-2つのメソッドを投稿します-1つはConcurrentQueueでwhileループを実行し、新しいメッセージを待機し、もう1つは一度に1つのメッセージを送信します。また、Azure博士が規定したとおりに、一時的な障害処理ブロックを使用しています。

送信ループ（最初から開始し、新しいメッセージを待機しています）：

メッセージの送信：

上記のコードは、1メッセージ/秒を送信する「Sender」クラスからのものです。常に約50〜100のインスタンスが実行されているため、かなりの数のスレッドになる可能性があります。

ところで、EnsureMessageSender、RecreateMessageFactory、EnsureTopicExistsについてはあまり心配しないでください。これらは、それほど頻繁には呼び出されません。

必要なのは一度に1つのメッセージを送信するだけで、非同期のものを気にせず、それに伴うオーバーヘッドを回避することを条件として、メッセージキューを介して1つのバックグラウンドスレッドを処理し、メッセージを同期的に送信する方がよいのではないでしょうか。

通常、1つのメッセージをAzure Service Busに送信するのは数ミリ秒であり、それほど高価ではないことに注意してください。（低速、タイムアウト、またはService Busバックエンドに問題がある場合を除いて、送信しようとしてしばらくハングする可能性があります）。

長い投稿をありがとう、ごめんなさい、

ステボ

提案された解決策

この例は私の状況の解決策になりますか？

したがって、あるプロセスが別のプロセスに切り替わるとき、カーネルがプロセスの現在の状態を保存し、OSスケジューラアルゴリズムがスワップインする次のプロセスを選択することを私が理解している方法です。このアルゴリズム自体をロードする必要はありませんか?それはプロセスなので？カーネル自体は、スイッチを実行するときに CPU 時間を使用しますか? そうであれば、カーネルはコンテキスト スイッチの中で CPU サイクルにどのようにアクセスしますか?

前もって感謝します。

thisの回答では、次のように述べています。

また、X が「ネットワーク」を使用していると聞いて、これがパフォーマンスのボトルネックになると考えています。ここでの「ネットワーク」はローカルの UNIX ドメイン ソケットを意味し、最新の Linux ではオーバーヘッドはごくわずかです。ネットワーク上でボトルネックになるものは、高速化するための X 拡張機能 (共有メモリ ピックスマップ、DRI など) があります。ボトルネックは、ローカル ソケットの最小限のオーバーヘッドよりも、同じハードウェアにアクセスする複数のスレッドまたはプロセスを調整するという固有の問題に関係しているため、プロセス内のスレッドは必ずしも X ソケットよりも高速ではありません。

理解できません。複数のプロセスが Unix ドメイン ソケットで通信するよりも、複数のスレッドが共有変数で通信する方が高速であると常に考えています。それで...私は間違っていますか？複数のスレッドを調整するのは、それほど時間のかかる仕事ですか? また、プロセスがスケジュールされる順序は、Unix ドメイン ソケットのパフォーマンスにまったく影響しませんか?

何か案が？お願いします...

申し訳ありませんが、私は質問を明確にしませんでした。私が聞きたかったのは、X Window/Wayland システムではなく、IPC の効率についてです。

UNIXドメインソケットが共有メモリよりも高速である理由を知りたいだけですか? 私の知る限り、共有メモリはプロセスとスレッド間で通信するための最も原始的な方法ですよね? したがって、UNIX ドメイン ソケットは、共有メモリ メカニズムの上に構築する必要があります (適切なロックを伴う)。生徒 (つまり Unix ドメインソケット) が教師 (つまり共有メモリ) よりも優れているのはなぜですか?

マルチコア プロセッサ マシンの複数のコアで並行して必要な場合、Linux カーネルは複数のコンテキスト スイッチを同時に実行しますか? 参照はありますか？

マルチスレッド アプリケーションがあり、コードの特定のセクションで を使用しStopwatchて操作の時間を測定しています。

問題は、ストップウォッチが開始されている間にプログラムが別のスレッドに制御を切り替えると、時間の経過が正しくないことです。コンテキストがこのセクションに切り替わる前に、他のスレッドが何らかの作業を行った可能性があります。

ロックについて質問しているわけではないことに注意してください。これらはすべてローカル変数であるため、その必要はありません。時限セクションを継続的に実行したいだけです。

編集：別の解決策は、コンテキスト切り替え時間を差し引いて、時間指定セクションで作業を行った実際の時間を取得することです。それが可能かどうかはわかりません。

タイトなループで単一の配列を更新する複数のスレッドがあります。(デュアルコア プロセッサで 10 スレッド @ 毎秒約 100000 更新)。配列がミューテックス (WaitForSingleObject / ReleaseMutex) の保護下で更新されるたびに。私は、スレッドが配列に対して 2 つの連続した更新を行うことはないことに気付きました。つまり、同期に関連する何らかの収量が必要です。これは、毎秒約 100000 のコンテキスト スイッチが発生していることを意味し、最適とは言えません。なぜこれが起こるのですか？

OS コンテキスト スイッチに関する次の質問に答えるように求められましたが、この質問はかなりトリッキーで、教科書には答えが見つかりません。

1. 特定の時点でシステム内に存在する PCB の数は?
2. Context Switch が発生する可能性のある状況を 2 つ挙げてください。（プロセスの中断と終了だと思いますが、よくわかりません）
3. ハードウェアのサポートによって、切り替えにかかる時間が異なります。2 つの異なるアプローチとは何ですか?
4. コンテキスト スイッチの管理には、OS のどの部分が関係していますか?

やや大きなマシン (32 コア、256 GB RAM) で作成したマルチスレッド プログラムのプロファイルを作成しようとしています。実行ごとに、プログラムのパフォーマンスが大幅に (70 ～ 80%) 変わる可能性があることに気付きました。プログラムのパフォーマンスにおけるこの巨大な差異の原因を見つけることはできないようですが、多数の実行で「時間」ユーティリティの結果を分析することによって、非自発的なコンテキスト スイッチの数が、プログラムのパフォーマンス (明らかに、コンテキスト スイッチが少ないほどパフォーマンスが向上し、その逆も同様です)。

このコンテキスト切り替えの原因を特定する良い方法はありますか? 犯人を発見できれば、問題を解決できるかもしれません。ただし、使用できるツールにはいくつかの特定の制限があります。まず、マシンのルート権限を持っていないため、そのような権限を必要とするツールはありません。第 2 に、これはかなり古いカーネル (RHEL5、カーネル 2.6.18) であるため、標準的な perf-event の一部が存在しない可能性があります。とにかく、このコンテキスト切り替えの原因をより深く掘り下げる方法についての提案は大歓迎です。

アップデート：私は自分のプログラムを別の (そして小さい) マシンでテストすることにしました。もう一方のマシンは、8Gb の RAM を搭載した 4 コア (ハイパースヘディング付き) の Linux ボックスで、カーネルははるかに新しいものです --- 他のマシンでは 3.2.0 対 2.6.18 です。新しいマシンでは、バイモーダル パフォーマンス プロファイルを再現できません。これは、問題がハードウェアの問題 (コメントで示唆されているように) によるものか、カーネルレベルでの特に病理学的なケースが原因であり、その後修正されたものであると私に信じさせます。私の現在の最良の仮説は、新しいマシンには完全に公平なスケジューラ (CFS) を備えたカーネルがあり、古いマシンには含まれていないという事実の結果である可能性があるというものです。新しいマシン用に古いカーネル バージョンを再コンパイルすることなく、この仮説をテストする (新しいマシンに別の/古いスケジューラを使用するように指示する) 方法はありますか?

MediaRecorder.start() には時間がかかります。メソッド プロファイリングによると、「コンテキスト スイッチ」 - 包括的リアルタイムは 100% で、約 1510 ミリ秒かかります。どうにかして減らすことはできないでしょうか？できるだけ速くする必要があります。