W3WP.EXE utilisant 100% CPU-par où commencer?
An ASP.NET l'application Web fonctionnant sur IIS6 tire périodiquement le processeur jusqu'à 100%. C'est le W3WP qui est responsable de presque toute l'utilisation du processeur au cours de ces épisodes. Le CPU reste épinglé à 100% de quelques minutes à plus d'une heure.
C'est sur un serveur intermédiaire et le site ne reçoit que du trafic très léger de la part des testeurs à ce stade.
Nous avons lancé ANTS profiler sur le serveur, mais cela n'a pas été éclairant.
Où pouvons-nous commencer à découvrir ce qui cause ces épisodes et quel code garde le CPU occupé pendant tout ce temps?
9 réponses
- compteurs de performances Windows Standard (recherchez d'autres activités corrélées, telles que de nombreuses requêtes GET, des E/S réseau ou disque excessives, etc.); vous pouvez les lire à partir du code ainsi que de perfmon (pour déclencher la collecte de données si L'utilisation du processeur dépasse un seuil, par exemple)
- compteurs de performances personnalisés (en particulier pour les requêtes hors boîte et autres appels où le temps d'exécution est incertain)
- test de charge, à l'aide d'outils tels que Visual Studio Team Test ou WCAT
- Si vous pouvez tester ou mettre à 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 requêtes sont arrivées au moment du pic CPU
- révisions de Code / walk-through (en particulier, recherchez les boucles qui peuvent ne pas se terminer correctement, par exemple si une erreur se produit, ainsi que les verrous et les problèmes de threading potentiels, tels que l'utilisation de la statique)
- profilage CPU et mémoire (peut être difficile sur un système de production)
- Explorateur De Processus
- Moniteur De Ressources Windows
- journalisation détaillée des erreurs
- journalisation de trace personnalisée, y compris les détails du temps d'exécution (peut-être conditionnel, basé sur le compteur CPU-use perf)
- les erreurs se produisent-elles lorsque AppPool recycle? Si oui, cela pourrait être un indice.
Ce n'est pas vraiment une réponse, mais vous devrez peut-être aller à l'ancienne et capturer un instantané d'image du processus IIS et le déboguer. Vous pouvez également consulter le blog de Tess Ferrandez - elle est un coup de pied un ingénieur * * Microsoft escalation 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 ASP.NET tag (qui est ce que j'ai lié à) alors vous verrez plusieurs éléments qui sont similaires.
Si votre CPU monte à 100% et reste là, 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 blocages sont cependant beaucoup plus difficiles à traquer.
Process Explorer est un excellent outil de dépannage. Vous pouvez l'essayer pour trouver le problème de l'utilisation élevée de CPU . Il vous donne un aperçu de la façon dont votre application fonctionne.
Vous pouvez également essayer Procdump pour vider le processus et analyser ce qui s'est réellement passé sur le CPU.
Regardez aussi vos compteurs perfmon. Ils peuvent vous dire où beaucoup de temps cpu est passé. Voici un lien vers les compteurs les plus courants à utiliser:
Nous avons eu ceci sur une requête récursive qui déversait des tonnes de données à la sortie - avez-vous vérifié tout ce qui sort et aucune boucle infinie n'existe?
Pourrait essayer de le réduire avec une seule page - nous avons trouvé des fourmis pour ne pas être beaucoup d'aide dans ce même cas non plus-ce que nous avons fini par faire était en cours d'exécution du site frapper une page regarder le CPU-frapper la page suivante regarder CPU - très méthodique et prend du temps mais si vous ne -
Nous avons pu utiliser les fichiers journaux IIS pour le suivre vers un ensemble de pages suspectes -
J'espère que ça aide !
C'est une supposition au mieux, mais peut-être que votre équipe de développement construit et déploie l'application en mode débogage, au lieu du mode release. Ce sera la cause de l'apparition de .fichiers pdb. Cela implique que votre application prendra des ressources supplémentaires pour collecter l'état du système et les informations de débogage pendant 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 déploient dans mode de diffusion.
C'est un très vieux post, je sais, mais c'est également un problème commun. Toutes les méthodes suggérées sont très agréables, mais elles indiqueront toujours un processus, et il y a beaucoup de chances que nous sachions déjà que notre site pose des problèmes, mais nous voulons juste savoir quelle page spécifique passe trop de temps dans le traitement. L'outil le plus précis et le plus simple à mon avis est IIS lui-même.
- Cliquez simplement sur votre serveur dans le volet gauche D'IIS.
- Cliquez sur 'Processus de travail' dans le volet principal. vous voyez déjà quel pool d'applications prend trop de CPU.
- double-cliquez sur cette ligne (éventuellement rafraîchir en cliquant sur "Afficher tout") pour voir quelles pages consomment trop de temps CPU ("temps écoulé" colonne) dans ce pool
Si vous identifiez une page qui prend du temps à charger, utilisez Developer Dashboard de SharePoint pour voir quel composant prend du temps.