Coût de performance du profilage d'une application Web en production

Question

Je tente de résoudre les problèmes de performances avec une application Web tomcat Java volumineuse et complexe. Le plus gros problème pour le moment est que, de temps en temps, l'utilisation de la mémoire augmente et l'application ne répond plus. J'ai corrigé tout ce que je pouvais corriger avec les profileurs de journal et l'analyse bayésienne des fichiers de journal. J'envisage de lancer un profileur sur le serveur tomcat de production.

Note au lecteur avec une sensibilité faible:

Je comprends que certains puissent trouver la notion même de profiler une application de production offensante. Soyez assuré que j'ai épuisé la plupart des autres options. La raison pour laquelle je réfléchis est que je ne dispose pas des ressources nécessaires pour dupliquer complètement notre configuration de production sur mon serveur de test et que je n’ai pas pu provoquer les défaillances qui nous intéressent sur mon serveur de test.

Questions:

Je cherche des réponses qui fonctionnent soit pour une application Web Java s'exécutant sur tomcat, soit pour répondre à cette question de manière agnostique.

• Quels sont les coûts de performance du profilage?
• Y a-t-il d'autres raisons pour lesquelles c'est une mauvaise idée de connecter et de profiler à distance une application Web en production (modes de défaillance étranges, problèmes de sécurité, etc.)?
• Dans quelle mesure le profilage affecte-t-il la mémoire?
• Existe-t-il des outils de profilage java présentant des coûts de performances très bas?
• Des outils de profilage Java conçus pour profiler des applications Web?
• Quelqu'un at-il des points de repère sur les coûts de performance du profilage avec visualVM?
• Quelle est la taille des applications et des jeux de données auxquels visualVM peut s’adapter?

Answer 1

OProfile et son ancêtre DPCI ont été développés pour le profilage des systèmes de production. La surcharge pour ceux-ci est très faible et ils profilent votre système complet , y compris le noyau, afin que vous puissiez détecter les problèmes de performances de la machine virtuelle et dans le noyau et les bibliothèques.

Pour répondre à vos questions:

1. Frais généraux: il s’agit de échantillonneurs , c’est-à-dire qu’ils génèrent un temporisateur ou compteur de performance s’interrompt à intervalles réguliers et examine le code en cours d’exécution. Ils l'utilisent pour créer un histogramme où vous passez votre temps et les frais généraux sont très faibles (1-8% correspond à ce que ils prétendent ) pour des intervalles d'échantillonnage raisonnables.

   Jetez un coup d'œil à la graphique de la fréquence de la fréquence d'échantillonnage et du temps système pour OProfile. Vous pouvez régler la fréquence d’échantillonnage pour réduire le temps système si les valeurs par défaut ne vous conviennent pas.

2. Utilisation en production: Le seul inconvénient de l'utilisation d'OProfile est que vous devez l'installer sur votre machine de production. Je pense que Red Hat prend en charge le noyau depuis RHEL3, et je suis pratiquement sûr que d’autres distributions le prennent en charge.

3. Mémoire: je ne sais pas quelle est exactement l'empreinte mémoire d'OProfile, mais je pense qu'il conserve des tampons relativement petits et les dépose de temps en temps dans les fichiers journaux.

4. Java: OProfile inclut les agents de profilage prenant en charge Java et tenant compte du code exécuté dans les JIT. Ainsi, vous pourrez voir les appels Java, pas seulement les appels C dans l'interpréteur et JIT.

5. Applications Web: OProfile est un profileur au niveau du système. Il n'est donc pas au courant des éléments tels que les sessions, les transactions, etc. qu'aurait une application Web.

   Cela dit, il s’agit d’un profileur Système complet . Par conséquent, si votre problème de performances est causé par de mauvaises interactions entre le système d’exploitation et le JIT, ou s’il se trouve dans une bibliothèque tierce, Vous pourrez le voir, car OProfile profile le noyau et les bibliothèques. C’est un avantage pour les systèmes de production, car vous pouvez détecter les problèmes dus à une mauvaise configuration ou à des particularités de l’environnement de production qui pourraient ne pas exister dans votre environnement de test.

6. VisualVM: Je ne suis pas sûr de celui-ci car je n'ai aucune expérience de VisualVM

Voici un didacticiel sur l'utilisation de OProfile pour rechercher les goulots d'étranglement des performances .

Answer 2

J’ai utilisé YourKit pour établir le profil d’applications dans un environnement de production très chargé, et même s’il y avait eu un impact, il était facilement acceptable. Votre kit accorde une grande importance à ce que vous puissiez le faire de manière non de manière non invasive, telle que l’arrêt sélectif de certaines fonctions de profilage plus coûteuses (c’est vraiment une échelle mobile).

Mon aspect préféré est que vous pouvez exécuter la machine virtuelle avec l'agent YourKit en cours d'exécution, sans impact sur les performances. c'est uniquement lorsque vous connectez l'interface graphique et démarrez le profilage qu'elle a un effet.

Answer 3

Il n’ya rien de mal à profiler des applications de production. Si vous travaillez sur des applications distribuées, il peut arriver qu’une exception de mémoire excessive se produise selon un scénario de probabilité très unique et très difficile à reproduire dans un environnement dev / stage / uat.

Vous pouvez essayer d’utiliser des profileurs personnalisés, mais si vous êtes pressé et qu’il vous faudra du temps pour brancher / configurer un profileur sur un boîtier de production, vous pouvez également utiliser jvm pour effectuer un vidage de la mémoire (le vidage de la mémoire jvms vous donne également le fil dump)

1. Vous pouvez activer la génération automatique sur la ligne de commande de la machine virtuelle Java, en utilisant l'option suivante: -XX: + HeapDumpOnOutOfMemoryError

2. Le projet Eclipse Memory Analyzer possède une fonctionnalité très puissante appelée «groupe par valeur», qui permet de créer une requête d'objet et de regrouper les instances en fonction d'une valeur de champ. Cela est utile dans le cas où de nombreuses instances contiennent un ensemble plus petit de valeurs possibles et que vous pouvez voir quelles valeurs sont les plus utilisées. Cela m’a vraiment aidé à comprendre certaines dépressions de mémoire complexes, je vous recommande donc de l’essayer.

Answer 4

Vous pouvez également envisager d’utiliser l’un des modernes HotSpot JVM - Java Flight Recorder et Contrôle de mission Java . C’est un ensemble d’outils qui vous permettent de collecter des informations d’exécution de bas niveau avec une surcharge de temps d’environ 5% (je ne peux pas prouver la dernière déclaration, c’est la déclaration de l’ingénieur Oracle qui a présenté la fonctionnalité et la démonstration en direct).

Vous pouvez utiliser cet outil tant que votre application exécute la JVM 1_7u40 ou une version ultérieure. Pour activer la collecte d'informations d'exécution, vous devez démarrer JVM avec des indicateurs particuliers:

  

Par défaut, JFR est désactivé dans la machine virtuelle. Pour activer JFR, vous devez lancer votre application Java avec l'option -XX: + FlightRecorder . JFR étant une fonctionnalité commerciale, disponible uniquement dans les packages commerciaux basés sur Java Platform, Standard Edition (Oracle Java SE Advanced et Oracle Java SE Suite), vous devez également activer les fonctionnalités commerciales à l'aide de -XX: + UnlockCommercialFeatures options.

(Cité http: // docs. oracle.com/javase/8/docs/technotes/guides/jfr/about.html#sthref7 )

J'ai ajouté cette réponse car il s'agit d'une option viable pour le profilage dans l'OMI de production.

Il existe également un plug-in Eclipse qui prend en charge JFR et JMC et capable d’afficher des informations conviviales.

Answer 5

Les outils se sont considérablement améliorés au fil des ans. De nos jours, la plupart des gens qui en ont besoin utilisent un outil qui se connecte à l'API d'instrumentation de Java au lieu de l'API de profilage. Il existe sûrement d'autres exemples, mais NewRelic et AppDynamics me vient à l’esprit. Les solutions basées sur l'instrumentation s'exécutent généralement en tant qu'agent dans la machine virtuelle et collectent en permanence des données. Ils rapportent les données à un niveau supérieur (transaction commerciale, transaction Web, transaction de base de données) par rapport à l'ancienne approche de profilage et vous permettent de creuser plus en profondeur (jusqu'à la méthode ou la ligne) si nécessaire. Vous pouvez même configurer la surveillance et les alertes afin de pouvoir suivre / alerter sur des métriques telles que les temps de chargement des pages et les performances par rapport aux SLA. Avec ces excellents outils, vous ne devriez plus avoir aucune raison de faire fonctionner un profileur en production. Le coût de leur fonctionnement est négligeable.