Raisons de voir "% de temps en gc" à Perfmon

Oui, cela semble excessif. La réduction de la quantité de GC serait probablement la meilleure étape que vous pourriez prendre pour réduire le temps d'exécution de votre application (si c'est votre objectif).

Un "% de temps en GC" est généralement causé par l'alloué puis jeter des milliers ou des millions d'objets. Un bon moyen de savoir ce qui se passe est d'utiliser un outil de profil de mémoire.

Microsoft fournit gratuitement profileur CLR . Cela vous montrera toutes les allocations, mais rendra votre application 10-60 fois plus lente. Vous devrez peut-être peut-être exécuter moins de données d'entrée afin qu'il puisse finir d'analyser dans une quantité de temps raisonnable.

Un excellent outil commercial est la profileur de mémoire .NET . Cela impose beaucoup moins de frais généraux d'exécution et il y a un essai gratuit disponible. En prenant plusieurs instantanés lorsque votre processus est en cours d'exécution, vous pouvez savoir quel type d'objets sont fréquemment alloués (puis détruits).

Une fois que vous avez identifié la source des allocations, vous devez ensuite examiner le code et déterminer comment ces allocations peuvent être réduites. Bien qu'il n'y ait pas de réponse unique - toutes les réponses, certaines choses que j'ai rencontrées dans le passé incluent:

• string.split peut créer des centaines de petites chaînes de courte durée. Si vous faites beaucoup de manipulation de chaîne, cela peut aider à traiter la chaîne en marchant sur le caractère-caractère.
• Créer des tableaux ou des listes de milliers de petites classes (par exemple, sous 24 octets de taille) peut être coûteux; Si ces classes peuvent être traitées comme des types de valeur, il peut (parfois) améliorer considérablement les choses à les modifier en structures.
• Créer des milliers de petits tableaux peut augmenter beaucoup l'utilisation de la mémoire (car chaque matrice a une petite quantité de frais généraux); Parfois, ceux-ci peuvent être remplacés par un grand tableau et index dans une sous-section.
• avoir beaucoup d'objets finalisables (en particulier si elles ne sont pas disposées) peuvent mettre beaucoup de pression sur le collecteur des ordures; Assurez-vous que vous disposez correctement de tous les objets iDisposables et notez que vos propres types devraient (presque) jamais de finaliseurs .
• Microsoft dispose d'un article avec Guidalités de collecte des ordures pour l'amélioration Performance.

Une autre raison pourrait être beaucoup de collections GEN-1 ou GEN-2, chacune d'entre elles prend beaucoup plus de temps et est causée par une suspension à des objets plus longtemps.

J'ai vu cela arriver dans des applications Web lorsque des objets de buggy accrochent sur des objets de page réels - forçant la page à vivre aussi longtemps que les autres objets qui se réfèrent à eux.

rompre le lien entre les objets et les pages (dans ce cas) causé à GC de chuter à des valeurs très basses. Notre site a maintenant plus de 100 hits / seconde et GC Time est typiquement de 1% ou moins.

suis-je raison que cela excessif?

oui, vous êtes correct

Comment puis-je comprendre pourquoi la route provoque des pics de GC?

1.- Jetez un coup d'œil à perfeview

perfview est un outil d'analyse de performance qui aide à isoler la CPU- et Problèmes de performance liés à la mémoire.

Voir aussi: Améliorer les performances de code géré

2.- Voir si GC.Collect ou GC.WAITFORPENDINGSELIALISERS est appelé n'importe où dans votre code ou votre bibliothèque tierce. Ce dernier peut provoquer une utilisation élevée du processeur.