次の方法で共有

サーバー プロセス内の競合の追跡

  • [アーティクル]

受信要求に対応するために、RPC は一連のワーカー スレッドを保持します。 スレッド数が少ないのが理想的です。 ただし、この理想的な状況は、サーバー マネージャー ルーチンが入念に調整されたラボ環境でのみ見られます。 実際の状況では、スレッド数はサーバー ワークロードによって異なりますが、1 から 50 の範囲内になります。

ワーカー スレッドの数が 50 を超えている場合、サーバー プロセスで過剰な競合が発生している可能性があります。 この一般的な原因として、ヒープの乱用、メモリ負荷、1 つのクリティカル セクションを使用したサーバー内のほとんどのアクティビティのシリアル化が挙げられます。

特定のサーバー プロセスのスレッド数を確認するには、!rpcexts.getthreadinfo 拡張機能を使用するか、-t スイッチを指定して DbgRpc を使用します。 プロセス ID (次の例では 0xC4) を指定します。

D:\wmsg>dbgrpc -t -P c4
Searching for thread info ...
## PID  CELL ID   ST TID      LASTTIME
-----------------------------------
00c4 0000.0004 03 0000011c 000f164f
00c4 0000.0007 03 00000120 008a6290
00c4 0000.0015 03 0000018c 008a6236
00c4 0000.0026 03 00000264 0005c443
00c4 0000.002d 03 00000268 000265bb
00c4 0000.0030 03 0000026c 000f1d32
00c4 0000.0034 03 00000388 007251e9

この例では、ワーカー スレッドは 7 つしかなく、これは妥当です。

100 スレッドを超えている場合は、デバッガーをこのプロセスにアタッチし、原因を調査する必要があります。

メモdbgrpc -t などのクエリをリモートで実行すると、サーバーとネットワークにコストがかかります。 このクエリをスクリプトで使用する場合は、このコマンドが頻繁に実行されないようにする必要があります。