L'agent .NET de New Relic collecte des métriques à partir de l'environnement d'exécution .NET sur les performances de votre application. Ces métriques peuvent fournir des informations détaillées sur la quantité de CPU et de mémoire consommée par une application , ainsi que sur la manière dont les performances d'une application peuvent être affectées par la collecte des déchets et la contention des ressources du pool de threads.
Vous pouvez voir ces métriques sur one.newrelic.com > All capabilities > APM & services. Sélectionnez une application et accédez à More views > Dotnet VMs.
Vous pouvez également visualiser ces métriques en :
- Créer un dashboard personnalisé.
- En utilisant le Metric explorer dans one.newrelic.com > All capabilities > APM & services > sélectionnez une application et accédez à More views.
Mesures du processeur
Les métriques CPU suivantes sont collectées :
| Le pourcentage de CPU consommé par ce processus. |
| La quantité de temps que le processus a passé à exécuter le code de l'application. |
mémoires métriques
Les mémoires métriques suivantes sont collectées :
| La quantité de mémoire privée (physique), en Mo, allouée au processus. |
| Quantité de mémoire physique allouée au processus. |
Mesures de collecte des déchets
Le récupérateur de mémoire .NET s'exécute en arrière-plan et est chargé d'identifier et de récupérer la mémoire liée aux objets qui ne sont plus référencés par une application. Les mesures suivantes peuvent être utiles pour identifier les modèles d’allocation d’objets et les scénarios potentiels de surallocation. Cet article explique plus en détail les principes fondamentaux du garbage collection dans .NET.
Important
Pour les applications .NET Framework, l'utilisateur Windows sous lequel votre application s'exécute doit avoir accès aux données du compteur de performances Windows. Habituellement, cela se fait en ajoutant l'utilisateur aux groupes Performance Monitor Users et Performance Log Users . Des autorisations insuffisantes entraîneront l'impossibilité pour l'agent de collecter les métriques de récupération de place.
Mesures globales
De plus, les métriques de collecte des déchets suivantes sont collectées :
| Le nombre de références aux objets. |
| Normalement, le runtime effectue automatiquement le garbage collection. Cette métrique identifie le nombre de fois où le garbage collection a été appelé manuellement par un appel explicite à |
| Pourcentage du temps écoulé pendant lequel l'environnement d'exécution .NET a effectué le nettoyage de la mémoire depuis le dernier cycle de nettoyage de la mémoire. |
Génération - 0 tas
Les métriques de récupération de place Gen0 suivantes sont collectées :
| La quantité de mémoire (en Mo) pouvant être allouée dans la génération 0. Cela n'indique pas la quantité de mémoire utilisée par la génération 0, mais le maximum pouvant être alloué. |
| La quantité de mémoire (en Mo) qui a survécu au ramasse-miettes et a été promue de Gen0 à Gen1. La mémoire survit au ramasse-miettes lorsqu'il existe une référence active à celle-ci. |
| Nombre de fois que le garbage collection de génération 0 a été exécuté par le garbage collection. |
Génération - 1 tas
Les métriques de récupération de place Gen1 suivantes sont collectées :
| La quantité de mémoire (en Mo) utilisée dans le tas de génération 1. Cela diffère de |
| La quantité de mémoire (en Mo) qui a survécu au ramasse-miettes et a été promue de Gen1 à Gen2. La mémoire survit au ramasse-miettes lorsqu'il existe une référence active à celle-ci. |
| Nombre de fois que la collecte des déchets de génération 1 a été exécutée par le récupérateur de déchets. |
Génération - 2 tas
Les métriques de récupération de place Gen2 suivantes sont collectées :
| La quantité de mémoire (en Mo) utilisée par le tas Gen2. |
| La quantité de mémoire (en Mo) qui a survécu au ramasse-miettes. La mémoire survit au ramasse-miettes lorsqu'il existe une référence active à celle-ci. Contrairement à Gen0 et Gen1, la mémoire qui survit au ramasse-miettes n'est pas promue. |
| Nombre de fois que le garbage collection de génération 2 a été exécuté par le récupérateur de place. |
Tas d'objets volumineux (LOH)
Les métriques LOH de récupération de place suivantes sont collectées :
| La quantité de mémoire (en Mo) utilisée par le tas d'objets volumineux (LOH). Dans .NET Core, le tas d’objets volumineux est parfois appelé Gen3. |
| La quantité de mémoire (en Mo) qui a survécu au ramasse-miettes. La mémoire survit au ramasse-miettes lorsqu'il existe une référence active à celle-ci. Contrairement à Gen0 et Gen1, la mémoire qui survit au ramasse-miettes n'est pas promue. |
Paramètres du pool de threads gérés
L'environnement d'exécution .NET gère un pool de threads. Les mesures suivantes offrent une visibilité sur les performances d'une application en termes de pool de threads et peuvent aider à identifier les zones de pénurie de pool de threads. La famine/conflit du pool de threads se produit lorsqu'il n'y a pas suffisamment de threads disponibles pour traiter les requests effectuées par une application. L'article suivant décrit les différentes fonctionnalités du pool de threads gérés. Veuillez noter que ces métriques n'incluent pas d'informations sur les threads qui ne sont pas gérés par le pool de threads.
Fils de travail
Les threads de travail sont des threads liés au processeur qui sont utilisés pour effectuer un travail au nom d'un processus.
| Identifie le nombre de threads gérés disponibles pour le processus. Des chiffres constamment bas indiquent un scénario potentiel de famine. |
| Identifie le nombre de threads de travail actuellement utilisés par le processus. |
Fils de discussion de fin de projet
Les threads d'achèvement, parfois appelés threads I/O , sont utilisés pour monitorer l'achèvement des opérations I/O .
| Cette métrique identifie le nombre de threads actuellement disponibles pour le processus. Des chiffres constamment bas indiquent un scénario potentiel de famine. |
| Cette métrique identifie le nombre de threads d'achèvement actuellement utilisés par le processus. |
débit
Les débits métriques mesurent la quantité de travail qui a été demandée pour être effectuée sur un thread différent, la quantité de travail qui a été démarrée et la quantité de travail qui attend qu'une ressource de pool de threads soit disponible.
| Identifie le nombre de fois où le travail a été demandé pour être exécuté sur un thread géré par un pool de threads différent. |
| Identifie le nombre d'éléments de travail dont l'exécution est demandée sur un thread distinct et qui ont commencé. |
| Identifie le nombre d'éléments de travail qui ont été demandés, mais qui attendent de démarrer. Des nombres qui augmentent constamment indiquent une situation potentielle de manque de pool de threads. L' article suivant décrit comment modifier le nombre de threads disponibles pour une application. |