Comment expliquer l'utilisation de la mémoire sur Windows Server en dehors de la liste des processus en cours d'exécution

J'ai un serveur Windows 2003 fonctionnant un peu lentement où les frais de validation et l'utilisation du fichier d'échange remontent et remontent jusqu'à ce que je redémarre finalement. Pour résoudre ce problème, je dois découvrir ce qui consomme toute la mémoire, et c'est là que réside le grand mystère.

Statistiques actuelles du Gestionnaire des tâches:

Physical Memory (K): 2096400
Commit Charge (K):   5364848
Page file usage:     5.11 GB

Très bien, nous allons donc tirer SysInternals Process Explorer et vérifier la taille du jeu de travail de tout ce qui fonctionne. Le plus grand coupable est une instance de Tomcat utilisant 121 980 Ko WS, 481 284 Ko VM Size. Rien là-dedans ne permet d'expliquer la charge de validation de 5 Go.

Étape suivante: Sysinternals pslist : pslist -m, divisé par la sortie sommes des colonnes et des colonnes de 61 pour calculer les processus qui sont rapportés.

SUM (Working Set)  : 681,484 K
SUM (Private Bytes): 593,424 K

Suis-je fondamentalement incompris de ce que les outils rapportent? J'ai toujours eu l'impression qu'un système d'exploitation engagerait en réalité beaucoup moins de mémoire que la quantité totale de mémoire virtuelle mappée par un processus, en supposant qu'il n'utilisera jamais vraiment autant, et que regarder VM ici est un hareng rouge.

JP, je crois que votre commentaire selon lequel il s'agit d'un serveur de test de build / unité automatisé qui exécute moins que du code stable en dit long. Je suppose que ce serveur doit être redémarré fréquemment car le code instable qui s'exécute dessus a probablement des fuites de mémoire qui vous donnent les symptômes que vous voyez. Les fuites de mémoire ne seront répertoriées dans aucune des arborescences de processus en cours d'exécution, car il s'agit de mémoire récupérée par des processus qui n'existent plus et sont toujours allouées, même si le processus qui leur est associé a disparu depuis longtemps.

Obtenez une fenêtre de maintenance fréquente pour vous permettre de redémarrer automatiquement cette machine, peut-être tous les soirs, quelques fois par semaine ou chaque semaine, selon la vitesse à laquelle ce comportement commence à présenter des problèmes de performances.

Nous avons des serveurs Oracle Application Servers sur Windoze il y a quelque temps qui devaient être redémarrés deux fois par jour. Nous avons expulsé les utilisateurs à l'heure du déjeuner et au milieu de la nuit tous les jours. C'était il y a quelques années, avec un code de production supposé stable d'Oracle.

Désolé de simplement coller quelques liens - mais nous avons utilisé certaines techniques pour trouver des fuites de mémoire, en utilisant logparser et powershell, donc je vais partager.

http://blogs.msdn.com/debuggingtoolbox/archive/2008/08/22/powershell-script-chart-and-statistics-from-top-20-objects-leaking.aspx

(Le site Never Doubt Thy Debugger est excellent): http://blogs.msdn.com/carloc/archive/2007/09/14/something-you-need-to-know-before-start-debugging.aspx

Je fournirai également un lien vers l'excellent aperçu de Mark Russinovich sur l'utilisation de la mémoire sous Windows:

http://blogs.technet.com/markrussinovich/search.aspx?q=memory&p=1

À moins d'ouvrir des cas Microsoft réels, le site de l'équipe de performance contient également de nombreuses bonnes informations: http://blogs.technet.com/askperf/Default.aspx?p=2

L'outil principal pour aider à diagnostiquer cela est perfmon. Les compteurs que je regarderais (pour commencer) sont:

Mémoire, octets validés Ceci est une mesure de la demande de mémoire virtuelle
Processus, ensemble de travail, _Total de mémoire virtuelle en utilisation "active"
Fichier de pagination,% fichier d'échange utilisé
Mémoire, Pages / Sec (ce n'est pas nécessairement un indicateur de mémoire insuffisante , bien que tout le monde semble supposer que c'est le cas)
Mémoire, pages de sortie / s combien de pages de mémoire virtuelle ont été écrites dans le fichier d'échange pour libérer des cadres de page RAM à d'autres fins chaque seconde

Mémoire, mémoire cache des octets,
mémoire des octets non paginés du pool, mémoire des octets
paginés du pool
, code système
Mémoire totale des octets , octets du pilote système

lorsque cette somme se rapproche de 2 Go, vous aurez des problèmes de performances généralement dus à l'architecture 32 bits

Mémoire, Mo disponibles - cela mesure la quantité de RAM disponible pour satisfaire les demandes de mémoire virtuelle (soit de nouvelles allocations, soit pour restaurer une page à partir du fichier d'échange).

Voir aussi http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm

Depuis combien de temps ce serveur fonctionne-t-il depuis le dernier redémarrage? Il est regrettable que Windows ait des fuites de mémoire. c'est-à-dire que la mémoire allouée n'est pas toujours libérée sur le système. Les symptômes sont exactement ce que vous voyez. Si vous ne le faites pas déjà, je vous suggère de redémarrer au moins une fois par semaine. De nombreux centres de données redémarrent Windows chaque jour, ce qui réduit considérablement les appels d'assistance. Bien sûr, c'est beaucoup plus facile à faire lorsque vous utilisez des clusters car il n'y a pas de temps d'arrêt.

On dit qu'il y a un administrateur système quelque part qui comprend vraiment les statistiques de la mémoire Windows, mais je ne les ai jamais rencontrées.

Cependant, il n'est généralement pas trop difficile de trouver un processus qui se comporte mal. Essayez d'utiliser Perfmon pour examiner les différents compteurs de processus comme les poignées ou les défauts de page / s.

JR

Réflexions complémentaires: êtes-vous sûr de manquer de mémoire. L'essentiel est de savoir si vous obtenez une radiomessagerie. S'il n'y a pas de pagination, vous ne manquez pas de mémoire. En utilisant PerfMon, jetez un œil au compteur Mémoire - Pages / sec.

N'oubliez pas que l'ensemble de travail est le bit de mémoire qui est réellement représenté par la VRAIE mémoire physique. vous avez également votre charge de mémoire virtuelle, et Windows fait le partage de page de code, certains morceaux de MFC vont être partagés entre beaucoup, beaucoup de processus sans dupliquer l'utilisation de la mémoire. De plus, vous avez le désir incessant de Windows de garder le cache du système de fichiers aussi grand que possible (je l'ai déjà vu monter à 800 Mo sur un ordinateur portable de 2,5 Go).

La gestion de la mémoire Windows est très robuste. Cependant, une fois que Windows a commencé la pagination, les choses deviennent laides et vous devez TOUJOURS laisser de la place pour le cache du système de fichiers - toujours toujours toujours. Je dois régulièrement arrêter et redémarrer Firefox lorsque mes 80+ onglets entraînent sa consommation de mémoire jusqu'à 1,2 Go / 1,2 + Go.

Windows brouille également un peu la ligne, entre les pages qui sont dans le cache et les pages qui sont répertoriées comme mémoire / jeu de travail.