Nachverfolgen von Konflikten im Serverprozess

Um eingehende Anforderungen zu verarbeiten, verwaltet RPC eine Reihe von Workerthreads. Im Idealfall ist die Anzahl der Threads gering. Diese ideale Situation wurde jedoch nur in Labumgebungen beobachtet, in denen die Server-Manager-Routinen sorgfältig abgestimmt sind. In einer realen Situation variiert die Anzahl der Threads je nach Serverworkload, aber sie kann zwischen 1 und 50 sein.

Wenn die Anzahl der Arbeitsthreads über 50 liegt, kann es zu übermäßigen Konflikten im Serverprozess gekommen sein. Häufige Ursachen hierfür sind die verwendung des Heaps, die Arbeitsspeicherauslastung oder das Serialisieren der meisten Aktivitäten auf einem Server über einen einzelnen kritischen Abschnitt.

Um die Anzahl der Threads in einem bestimmten Serverprozess anzuzeigen, verwenden Sie die Erweiterung !rpcexts.getthreadinfo , oder verwenden Sie DbgRpc mit dem Schalter -t . Geben Sie die Prozess-ID an (im folgenden Beispiel 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

In diesem Fall gibt es nur sieben Workerthreads, was sinnvoll ist.

Wenn mehr als 100 Threads vorhanden sind, sollte ein Debugger an diesen Prozess angefügt und die Ursache untersucht werden.

Hinweis Die Remoteausführung von Abfragen wie dbgrpc -t ist für den Server und das Netzwerk teuer. Wenn Sie diese Abfrage in einem Skript verwenden, sollten Sie sicherstellen, dass dieser Befehl nicht zu häufig ausgeführt wird.