W3WP.exe en utilisant 100% du CPU - où commencer?

StackOverflow https://stackoverflow.com/questions/2052633

Question

Une application Web ASP.NET en cours d'exécution sur IIS6 tire périodiquement la CPU jusqu'à 100%. Il est le W3WP qui est responsable de la quasi-totalité l'utilisation du processeur au cours de ces épisodes. La CPU reste épinglé à 100% allant de quelques minutes à plus d'une heure.

est sur un serveur de mise en scène et le site ne reçoit que le trafic très léger de testeurs à ce stade.

Nous avons en cours d'exécution ANTS profileur sur le serveur, mais il a été unenlightening.

Où peut-on commencer à trouver ce qui cause ces épisodes et ce code est maintenant la CPU occupé pendant tout ce temps?

Était-ce utile?

La solution

  1. compteurs de performance Windows standard (chercher d'autres activités corrélées, comme de nombreuses requêtes GET, réseau ou E / S disque excessive, 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)
  2. compteurs de performance sur mesure (en particulier en temps pour les demandes hors zone et d'autres appels où le temps d'exécution est incertaine)
  3. test de charge, en utilisant des outils tels que Visual Studio Team test ou WCAT
  4. Si vous pouvez tester ou mettre à niveau vers IIS 7, vous pouvez configurer Échec pour générer suivi des demandes d'une trace si les demandes prennent plus d'une certaine quantité de temps
  5. Utilisez logparser pour voir quelles demandes est arrivé au moment de la pointe CPU
  6. Revues de code / walk-through (en particulier, chercher des boucles qui peuvent ne pas terminiez, comme si une erreur se produit, ainsi que des serrures et des problèmes de filetage potentiels, tels que l'utilisation de la statique)
  7. CPU et le profilage de la mémoire (peut être difficile sur un système de production)
  8. Process Explorer
  9. Moniteur de ressources Windows
  10. Consignation erreur détaillée
  11. enregistrement de trace sur mesure, y compris les détails de temps d'exécution (peut-être conditionnelle, en fonction de la consommation de CPU perf compteur)
  12. Les erreurs qui se produisent lorsque le AppPool recycle? Dans ce cas, il pourrait être un indice.

Autres conseils

Il n'y a pas beaucoup d'une réponse, mais vous pourriez avoir besoin d'aller vieille école et de capturer un instantané de l'image du processus IIS et le déboguer. Vous pouvez également consulter Tess Ferrandez 's blog - elle est un coup de pied un ingénieur d'escalade Microsoft ** et son blog se concentre sur les fenêtres de débogage ASP.NET, mais le blog est pertinent pour les fenêtres de débogage en général. Si vous sélectionnez la balise ASP.NET (qui est ce que je suis lié à), vous verrez plusieurs éléments qui sont semblables.

Si votre CPU est Smasher à 100% et de rester là-bas, il est fort probable que vous avez soit un scénario de blocage ou une boucle infinie. Un profileur semble être un bon choix pour trouver une boucle infinie. Sont beaucoup plus blocages difficiles à traquer, cependant.

Process Explorer est un excellent outil pour le dépannage. Vous pouvez essayer de trouver le problème de href="http://en.wikipedia.org/wiki/Central_processing_unit" haute . Il vous donne un aperçu de la façon dont fonctionne votre application.

Vous pouvez également essayer Procdump pour vider le processus et d'analyser ce qui est arrivé sur la CPU.

Nous avons eu ce sur une requête récursive qui déversait des tonnes de données à la sortie - avez-vous vérifié tout à double sortie et ne pas les boucles infinies existent

peut essayer de les limiter à une seule page - nous avons trouvé ANTS de ne pas être beaucoup d'aide dans ce même cas, soit - ce que nous avons fini par faire était en cours d'exécution sur le site a frappé une page montre la CPU - a frappé la page suivante CPU montre - très méthodique et du temps, mais si vous ne trouvez pas avec un code que vous tracer peut-être pas de chance -

Nous avons pu utiliser les fichiers IIS journaux pour suivre à un ensemble de pages qui étaient suspects -

L'espoir qui aide!

Ceci est une estimation au mieux, mais peut-être votre équipe de développement est de construire et de déployer l'application en mode débogage, au lieu du mode de libération. Cela entraînera l'apparition de fichiers pdb. L'implication est que votre application prendra des ressources supplémentaires pour recueillir l'état du système et des informations de débogage lors de l'exécution de votre système, ce qui provoque plus l'utilisation du processeur.

Alors, il serait assez simple pour veiller à ce qu'ils construisent et le déploiement en mode de libération.

Ceci est un poste très vieux, je sais, mais cela est aussi un problème commun. Toutes les méthodes proposées sont très gentils, mais ils seront toujours pointer vers un processus, et il y a beaucoup de chances que nous savons déjà que notre site fait des problèmes, mais nous voulons juste savoir quelle page spécifique dépense trop de temps dans le traitement. L'outil simple et la plus précise à mon avis, est IIS lui-même.

  1. Cliquez sur votre serveur dans le volet gauche de IIS.
  2. Cliquez sur « des processus de travail » dans le volet principal. vous voyez déjà ce pool d'applications prend trop de CPU.
  3. Double-cliquez sur cette ligne (éventuellement rafraîchir en cliquant sur « Afficher tous ») pour voir ce que les pages consomment trop de temps CPU ( « Temps écoulé » colonne) dans ce pool

Si vous identifiez une page qui prend du temps à charger, utiliser de SharePoint Tableau de bord développeur pour voir quel composant prend du temps.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top