W3WP.EXE utilisant 100% de l’UC - par où commencer?
Une application Web ASP.NET exécutée sur IIS6 envoie périodiquement le processeur à 100%. C'est le W3WP qui est responsable de presque toute l'utilisation du processeur au cours de ces épisodes. Le processeur reste bloqué à 100% de quelques minutes à plus d’une heure.
C'est sur un serveur de transfert et le site ne reçoit qu'un trafic très faible des testeurs à ce stade.
Nous avons exécuté le profileur ANTS sur le serveur, mais cela n’a pas été très éclairant.
Où pouvons-nous commencer à découvrir la cause de ces épisodes et quel code maintient le processeur occupé pendant tout ce temps?
- Compteurs de performance Windows standard (recherchez d'autres activités corrélées, telles que de nombreuses requêtes GET, un nombre excessif d'E/S réseau ou disque, etc.); vous pouvez les lire aussi bien dans le code que dans perfmon (pour déclencher la collecte de données si l'utilisation du processeur dépasse un seuil, par exemple)
- Compteurs de performance personnalisés (en particulier pour le temps pour les demandes hors boîte et autres appels lorsque le temps d'exécution est incertain)
- Tests de charge, à l'aide d'outils tels que Visual Studio Team Test ou WCAT
- Si vous pouvez effectuer un test ou une mise à niveau vers IIS 7, vous pouvez configurer le suivi des demandes ayant échoué pour générer une trace si les demandes prennent plus de temps.
- Utilisez logparser pour voir quelles demandes sont arrivées au moment du pic du processeur.
- Révisions de code/visites guidées (en particulier, recherchez les boucles qui peuvent ne pas se terminer correctement, par exemple en cas d'erreur, ainsi que les verrous et les problèmes de threads potentiels, tels que l'utilisation de la statique)
- Profilage de la CPU et de la mémoire (peut être difficile sur un système de production)
- Explorateur de processus
- Moniteur de ressources Windows
- Enregistrement d'erreur détaillé
- Enregistrement de trace personnalisé, y compris les détails du temps d'exécution (éventuellement conditionnel, basé sur le compteur de performances d'utilisation du processeur)
- Les erreurs se produisent-elles lors du recyclage de l'AppPool? Si oui, cela pourrait être un indice.
Ce n'est pas vraiment une réponse, mais vous devrez peut-être aller à l'ancienne école et capturer un instantané d'image du processus IIS et le déboguer. Vous pouvez également vouloir vérifier Tess Ferrandez 's blog - elle est un coup de pied ** ingénieur d'escalade Microsoft et son blog se concentre sur le débogage de Windows ASP.NET, mais le blog est pertinent pour le débogage de Windows en général. Si vous sélectionnez la balise ASP.NET (qui est ce à quoi je suis lié), vous verrez alors plusieurs éléments similaires.
Si votre processeur augmente à 100% et y reste, il est fort probable que vous ayez un scénario de blocage ou une boucle infinie. Un profileur semble être un bon choix pour trouver une boucle infinie. Les impasses sont toutefois beaucoup plus difficiles à localiser.
Process Explorer est un excellent outil de dépannage. Vous pouvez l'essayer pour trouver le problème d'utilisation élevée CPU . Cela vous donne un aperçu du fonctionnement de votre application.
Vous pouvez également essayer Procdump de vider le processus et d’analyser ce qui s’est réellement passé sur le processeur.
Regardez aussi vos compteurs de performances. Ils peuvent vous dire où est dépensé une grande partie de ce temps CPU. Voici un lien vers les compteurs les plus courants à utiliser:
Nous avions ceci sur une requête récursive qui déversait des tonnes de données dans la sortie - avez-vous vérifié deux fois que tout se termine et qu'aucune boucle infinie n'existe?
Peut-être pourriez-vous essayer de le réduire avec une seule page - nous avons trouvé ANTS pas beaucoup d'aide dans le même cas non plus - ce que nous avons fini par faire était de faire tourner le site jusqu'à une page pour regarder le processeur - pour passer à la page suivante regarder le processeur - très méthodique et prend beaucoup de temps, mais si vous ne pouvez pas le trouver avec un traçage de code, vous risquez de ne pas avoir de chance
Nous avons pu utiliser les fichiers journaux IIS) pour les suivre sur un ensemble de pages suspectes -
J'espère que ça t'as aidé !
C'est au mieux une hypothèse, mais votre équipe de développement est peut-être en train de créer et de déployer l'application en mode débogage, au lieu du mode de publication. Cela entraînera l'occurrence de fichiers .pdb. Cela implique que votre application utilisera des ressources supplémentaires pour collecter l'état du système et les informations de débogage lors de l'exécution de votre système, ce qui entraînera une utilisation accrue du processeur.
Donc, il serait assez simple de s’assurer qu’ils construisent et se déploient en mode release.