«Processus d'inactivité du système» mange le processeur sur une application de filetage élevé

Question

J'ai une application Web multithread avec environ 1000 à 2000 threads dans l'environnement de production.

Je m'attends à l'utilisation du processeur sur w3wp.exe mais System Idle Process mange le processeur. Pourquoi?

Answer 1

Le processus inactif n'est pas en fait un véritable processus, il ne "mange" pas "votre temps de processeur. Le% CPU que vous voyez à côté est en fait un% CPU inutilisé (plus ou moins).

La raison des mauvaises performances de votre application est probablement due à vos 2000 threads. Windows (ou en fait tout système d'exploitation) n'a jamais été censé exécuter autant de threads à la fois. Vous perdez la plupart du temps, le contexte bascule entre eux, chacun obtenant quelques millisecondes de temps de traitement toutes les ~ 30 secondes (15 ms * 2000 = 30sec !!!!).

Repensez votre application.

Answer 2

Le processus inactif est simplement du temps du processus jusqu'à ce qu'un programme en ait besoin, il ne mange pas du tout de cycles. Vous pouvez considérer le temps d'inactivité du système comme «CPU disponible»

Answer 3

System Idle Process n'est pas un processus réel, il représente le temps de processeur inutilisé.

Cela signifie que votre application n'utilise pas complètement le processeur - elle peut être liée à la mémoire ou liée au processeur; Peut-être que les threads s'attendent ou pour des ressources externes? Le changement de vitesse de contexte pourrait également être un coupable - à moins que vous ayez 2000 cœurs, les threads ne sont pas réellement Exécuter tout en même temps, mais des tranches de temps attribuées par le planificateur de tâches, cela prend également un certain temps.

Answer 4

Vous n'avez pas fourni beaucoup de détails, je ne peux donc spéculer qu'à ce stade. Je dirais qu'il est probable que la plupart de ces fils ne font rien. Ceux qui font quelque chose sont probablement liés à Io, ce qui signifie qu'ils passent la plupart de leur attente que la ressource externe réponde.

Permet maintenant de parler des "1000 ~ 2000 threads". Il y a très peu de cas (peut-être aucun) où avoir autant de threads est une bonne idée. Je pense que votre problème actuel est un parfait exemple de pourquoi. La plupart de ces fils ne font (apparemment de toute façon) que de gaspiller des ressources. Si vous souhaitez traiter plusieurs tâches en parallèle, surtout s'ils sont liés à IO, il est préférable de profiter de ressources groupées comme le ThreadPool ou en utilisant le Bibliothèque parallèle de la tâche.