Problème
Lorsque l'agent .NET est attaché à une application .NET Framework à haut débit, quelques clients ont signalé une forte contention de threads. Après avoir examiné les vidages de processus et les traces d'appels, de nombreux threads peuvent être bloqués par des appels à AppDomain.GetData()
.
Solution possible
Dans la version 9.7 de l'agent .NET, une nouvelle variable d'environnement a été introduite qui désactive l'utilisation du stockage AppDomain
par l'agent .NET :
NEW_RELIC_DISABLE_APPDOMAIN_CACHING=true
Prudence
Bien que cette variable d’environnement élimine les conflits de verrouillage des appels d’agent à AppDomain.GetData()
, la surcharge totale de l’agent .NET est augmentée lorsque cette variable d’environnement est activée. Lors de nos tests, cela a entraîné moins de verrouillage, mais un débit d'application maximal inférieur avec l'agent .NET attaché à une application de test.
Nous sommes extrêmement intéressés par tout retour d'expérience de clients ayant testé cette nouvelle option configuration . Si vous essayez cette option de configuration, veuillez créer un problème dans notre référentiel GitHub pour .NET décrivant votre expérience.
Cause
L'agent .NET a besoin d'accéder aux informations de signature de méthode pour instrumenter les méthodes. Par défaut pour l'application .NET Framework, l'agent charge ces informations de méthode via la réflexion et les met en cache dans AppDomain
pour une utilisation ultérieure. Il s'agit d'une optimisation générale, mais plusieurs clients ont rencontré une forte contention de verrouillage de thread autour de ce comportement et pensent que c'est la cause principale du ralentissement ou de la non-réactivité des services.
Après avoir inspecté le code source de Microsoft, les appels à AppDomain.GetData()
entraînent en fait un verrou global.
Étant donné que l'agent .NET n'utilise aucun schéma de mise en cache des informations de méthode pour l'application .NET Core et qu'aucun client n'a signalé de problèmes de contention de verrouillage de thread similaires, nous avons décidé d'exposer une variable d'environnement pour que l'agent fonctionne de la même manière dans l'application .NET Framework.