.NET 4.0 Les pauses d'exécution du processus pendant plusieurs secondes, concèdent avec GC complète, causée par l'activité du fichier d'échange?

Question

J'ai un certain nombre de serveurs Core Windows 2008 R2 24 qui exécutent le même processus, mais chaque instance du processus a un ensemble de données différent. Habituellement, 2 à 4 instances du processus s'exécutent sur chaque serveur. Les processus sont compilés pour x64, ont une interface graphique et utilisent le poste de travail GC.

Chaque seconde, le processus sortira le GC compte sur un fichier journal sur le disque local. Le journal est également utilisé pour beaucoup d'autres choses. De temps en temps, je trouve que l'un de ces processus fait une pause exécution pendant 5 secondes ou plus. Je vois que rien n'est écrit dans le journal pour cette durée. Chaque fois que cela se produit, il concède avec le nombre de GC2 GC augmentant de 1.

C'est un événement rare. Cela se produit peut-être une fois tous les 10000 GC Gen2 sur tous les processus.

Chaque machine a plus qu'assez RAM pour conserver tous les processus dans RAM.

Ce matin, j'ai eu une pause de 9 secondes dans l'un des processus et cette fois, j'ai capturé des compteurs de performances pour le processus affecté et toute la machine. Aucun des autres processus exécutés à l'époque n'a été affecté. L'analyse des compteurs de performances montre les éléments suivants:

Comparaison après la pause avec la pause avant:

• Octets virtuels, octets de fichiers de page, octets virtuels, ensemble de travail et jeu de travail pour le processus supprimé d'environ le même montant - 1 Go. Pour vous donner une idée de la taille du processus, les octets privés sont passés de 3,1 Go à 2,1 Go.
• Le nombre de manches pour le processus est passé de 8835 à 8705
• Les octets disponibles pour toute la machine ont augmenté d'environ 1 Go
• Les défauts de la page / SEC n'ont pas augmenté
• L'utilisation du processeur était stable pendant la pause

Quelqu'un peut-il confirmer que cette activité peut être attribuée à l'échange? Étant donné que les machines ont plus qu'assez de RAM, y a-t-il des suggestions pour réparer ces pauses?

Mise à jour n ° 1 (3/5/2012):

A connu une pause de 6,5 secondes dans l'un des processus aujourd'hui. Les compteurs de performances de mémoire CLR .NET montrent que la taille du LOH n'a pas changé, mais la taille du tas de Gen 2 et la taille de tous les tas et des octets totaux engagés ont chuté de 700 Mo. Les octets réservés totaux ont chuté de 250 Mo. Il semble donc que beaucoup de déchets dans Gen2 ont été récupérés sur ce GC particulier.

Mise à jour n ° 2 (3/6/2012):

A connu une pause de 7 secondes dans l'un des processus aujourd'hui. Le suivant a été abandonné: Gen 2 TIAP TAILLE (.NET CLR Memory) par 900 Mo Num octets dans tous les tas (mémoire CLR .NET) par 900 Mo Num Total Commited octets (.NET CLR Memory) par 800 Mo Num Num Reserved octets (. Mémoire CLR nette) par 540 Mo d'octets virtuels (processus) par 550 Mo de travail (processus) par 800 Mo de travail - ensemble de fonctions privées (processus) octets de fichier (processus) par 800 Mo octets privés (processus) par 800 Mo

Loh est resté le même

Answer 1

Il semble qu'un Gen2 GC de bonne foi prend quelques secondes sur un processus de plusieurs concerts.

Alors pourquoi certains GC2 GCS prennent-ils 5 secondes et d'autres ne prennent pas presque de temps? Parce que j'ai activé GC simultané / en arrière-plan et il semble que lorsqu'un GC simultané se termine, le compteur Gen2 GC est incrémenté. Je pense que c'est trompeur.

Avec GC handicapé simultané, le nombre Gen2 GC baisse considérablement et chaque GC2 GCS prend quelques secondes.

Answer 2

Il semble que le comportement de votre application soit tel que de nombreux segments dans le tas d'objets grand peuvent devenir "morts" dans le même cycle GC 2 (voir Ce lien dans MSDN). Lorsqu'un segment du LOH est mort après un GC 2, il est renvoyé au système d'exploitation, qui peut être coûteux lorsque vous en retournez beaucoup simultanément.

Votre application peut tomber en dehors de l'enveloppe pour laquelle les modes CLR GC sont réglés. Si votre application alloue de grands objets tels que de grands tableaux à plusieurs reprises, vous pouvez voir si vous obtenez un comportement GC plus prévisible en les regroupant et en les réutilisant vous-même, plutôt que de compter sur le GC.