Suivi de la contention dans le processus serveur

Pour traiter les demandes entrantes, RPC conserve un ensemble de threads de travail. Dans l’idéal, le nombre de threads sera faible. Toutefois, cette situation idéale n’a été observée que dans les environnements de laboratoire, où les routines du gestionnaire de serveur sont soigneusement réglées. Dans une situation réelle, le nombre de threads varie en fonction de la charge de travail du serveur, mais il peut être compris entre 1 et 50.

Si le nombre de threads de travail est supérieur à 50, vous pouvez avoir une contention excessive dans le processus serveur. Les causes courantes de ce problème sont l’utilisation icriminé du tas, la pression de la mémoire ou la sérialisation de la plupart des activités d’un serveur via une seule section critique.

Pour voir le nombre de threads dans un processus serveur donné, utilisez l’extension !rpcexts.getthreadinfo ou utilisez DbgRpc avec le commutateur -t . Fournissez l’ID de processus (dans l’exemple suivant, 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

Dans ce cas, il n’y a que sept threads de travail, ce qui est raisonnable.

S’il existe plus de 100 threads, un débogueur doit être attaché à ce processus et la cause doit être examinée.

Note L’exécution de requêtes telles que dbgrpc -t à distance est coûteuse pour le serveur et le réseau. Si vous utilisez cette requête dans un script, vous devez vous assurer que cette commande n’est pas exécutée trop souvent.