O'Reilly Japan \ -Java Performance Résumé du chapitre 3 de ce livre
Chapitre 1 Introduction \ -Qiita Approche des tests de performances du chapitre 2 \ -Qiita ← Article précédent Chapitre 3 Boîte à outils Java Performance - Qiita ← Cet article Chapitre 4 Mécanisme du compilateur JIT \ -Qiita ← Article suivant Chapitre 5 Principes de base du nettoyage de la mémoire \ -Qiita
L'outil pour commencer est un outil qui n'a rien à voir avec Java.
Sur les systèmes Unix, commande sar, vmstat, iostat //qiita.com/pyon_kiti_jp/items/a44ac6e9229ba7b90c6b), il y a prstat, Sous Windows, il existe un type perf.
L'utilisation du processeur peut être classée dans les deux types suivants.
--User time: l'heure à laquelle la CPU exécute l'application
L'objectif est de maximiser l'utilisation du processeur et de raccourcir le temps d'exécution.
La cause de l'inactivité du processeur
Inversement, vous souhaiterez peut-être limiter l'utilisation du processeur par programme. Dans un tel cas, le cycle du processeur peut être inactif de force pendant une certaine période de temps, ou la priorité peut être abaissée.
Les systèmes Windows et Unix ont tous deux un mécanisme pour surveiller les threads exécutables (sans attendre les E / S ou en veille). Ce mécanisme s'appelle file d'attente d'exécution. Sous Windows, elle s'appelle la file d'attente du processeur et peut être visualisée avec typeperf.
C:> typeperf -si 1 "\System\Processor Queue Length"
"05/11/2013 19:09:42.678","0.000000"
"05/11/2013 19:09:43.678","0.000000"
Étant donné que la file d'attente d'exécution inclut celle qui est en cours d'exécution, elle doit être ** 1 ou plus **. En revanche, la file d'attente du processeur de Windows n'inclut pas celle en cours d'exécution, elle est donc ** 0 ou plus **.
Les performances souffrent lors de l'exécution de plus de threads qu'il n'y a de processeurs. Sous Unix, le nombre de files d'attente d'exécution == le nombre de processeurs doit être défini, et sous Windows, la longueur de la file d'attente du processeur doit être de 0. Cependant, ce n'est pas un principe absolu. Si la longueur de la file d'attente d'exécution augmente de temps en temps, il n'y a pas de problème. En revanche, si la file d'attente continue d'être trop longue, la charge sur la machine augmentera. Vous devez distribuer le processus sur une autre machine ou optimiser votre code.
C'est un indice pour confirmer que quelque chose ne va pas. Par exemple, si wMB / s (nombre d'octets écrits par seconde) de ʻiostat -x` est faible mais que w / s (nombre d'écritures par seconde) est grand, il peut être préférable de combiner le traitement d'écriture. Au contraire, s'il y a trop d'écritures, on constate qu'il y a un goulot d'étranglement.
Vous pouvez voir si le système échange. Peut affecter les performances. Dans vmstat, vous pouvez voir si (swap in) et so (swap out).
Les outils système standard sont insuffisants pour surveiller le trafic réseau. Netstat est utilisé sur les systèmes basés sur Unix. Tapez perf sous Windows.
Pour la bande passante réseau, nicstat est utilisé pour les systèmes Unix.
--jcmd: obtenir des informations sur le processus spécifié --jconsole: vous pouvez voir le comportement de la JVM dans l'interface graphique. --jhat: vous pouvez parcourir les vidages de tas avec un navigateur Web. --jmap: Vous pouvez obtenir des informations de vidage de tas et de mémoire. --jinfo: peut afficher les propriétés du système JVM --jstack: vidage de la pile de processus Java. --jstat: affiche des informations sur le GC et le chargement des classes. --jvisualvm: surveillance JVM. Peut analyser les vidages de tas.
jcmd ${ID de processus} VM.uptime
Vous pouvez voir la même valeur que System.getProperties () (celle que vous spécifiez -Dhogehoge au démarrage).
jcmd ${ID de processus} VM.system_properties
jinfo -sysprops ${ID de processus}
jcmd ${ID de processus} VM.version
jcmd ${ID de processus} VM.command_line
jcmd ${ID de processus} VM.flags -all
Si vous supprimez -all, sera-ce uniquement celui spécifié?
java -XX:+PrintFlagsFinal -version
Une valeur autre que la valeur par défaut est spécifiée pour ceux avec: =.
Tout d'abord, vous pouvez voir toutes les valeurs définies dans ↓.
jinfo -flags ${ID de processus}
Si vous voulez voir chaque élément de réglage
jinfo -flag PrintGCDetails ${ID de processus}
Lors de la modification de la valeur de réglage
jinfo -flag -PrintGCDetails ${ID de processus}
jinfo -flag PrintGCDetails ${ID de processus}
Vous pouvez vérifier le nombre de threads en cours d'exécution sur l'interface graphique avec jconsole ou jvisualvm.
Comment afficher la pile de fils
jstack ${ID de processus}
jcmd ${ID de processus} Thread.print
Utilisez jconsole ou jstat. jstat vous donne également des informations sur la compilation.
Dans jconsole, l'utilisation du tas peut être affichée graphiquement. Vous pouvez exécuter GC avec jcmd (comme vous le feriez avec jconsole?) jmap donne un aperçu du tas. jstat fournit diverses vues qui montrent ce que fait le GC.
Peut être obtenu avec jvisualvm (outil GUI) ou jcmd ou jmap Peut être analysé avec jvisualvm ou jhat s'il s'agit d'un outil standard Il existe également un outil tiers appelé Eclipse Memory Analyzer Tool.
Il existe un mode d'échantillonnage et un mode instrumenté Le mode d'échantillonnage ayant le moins de frais généraux, il est possible de minimiser le changement des caractéristiques de performance dû à l'intervention du profileur.
Cependant, de nombreux profileurs d'échantillonnage ne sont pas précis. Par exemple, un événement qui est appelé périodiquement par un minuteur et qui détecte uniquement le thread qui a été exécuté lorsque le minuteur s'est produit.
Dans la plupart des cas, la méthode qui apparaît au début du résultat du profilage ne représente que 2 à 3%, donc si vous faites de votre mieux pour la rendre deux fois plus rapide, elle ne sera peut-être que 1% plus rapide.
Contrairement au type d'échantillonnage, vous pouvez également voir le nombre de fois où chaque méthode est appelée et le nombre moyen de fois que chaque méthode est appelée par seconde. A partir de là, par exemple, on peut comprendre si la mise en œuvre doit être accélérée ou améliorée afin de réduire le nombre d'exécutions.
Le profileur en mode instrumenté peut être inexact en termes de performances car le code qui compte le nombre d'appels est réécrit et facturé dans l'octet code. Par exemple, la taille du code de méthode peut augmenter et il peut être déterminé que l'inlining n'est pas nécessaire (détaillé au chapitre 4).
Les profileurs d'échantillonnage ne peuvent profiler que les threads qui se trouvent à un point de restauration (la mémoire est allouée), contrairement aux profileurs en mode instrumenté.
Les méthodes de blocage (les méthodes d'attente telles que LockSupport # park et Object # wait ()) ne consomment pas de temps processeur (n'augmentent pas l'utilisation du processeur), donc même si elles apparaissent en haut des résultats du profilage, elles ne peuvent pas être optimisées. .. Par conséquent, la plupart des profileurs n'affichent pas les méthodes bloquées par défaut.
Pour la méthode de blocage, vous pouvez voir le comportement en regardant l'état d'exécution du thread. Pour VisualVM, l'onglet Threads.
Avec un profileur natif, vous pouvez profiler la JVM elle-même.
Il existe un profileur natif appelé Oracle Solaris Studio. Il s'appelle Solaris, mais il fonctionne également sous Linux.
Lorsqu'il est exécuté sur Solaris, vous pouvez profiter de la structure interne du noyau Solaris pour obtenir plus d'informations.
Il y avait une description comme ça. Je n'ai pas de machine Solaris donc je ne peux pas l'essayer.
Les données qui ne peuvent être obtenues qu'avec des outils natifs incluent le temps passé sur GC.
3.4 Java Mission Control Il est inclus dans la version commerciale de Java sous le nom jmc, pas dans la version open source. Une licence commerciale est requise pour l'utiliser.
JFR
Une fonction appelée JFR (Java Flight Recorder) est une fonction clé de jmc. Vous pouvez voir l'événement, tel que le blocage de thread.
Vous pouvez voir les événements liés au garbage collection dans la vue Mémoire JFR. Dans les chapitres 5 et 6, vous devriez lire tout en sachant comment cet outil est utile.
Dans l'onglet Vue d'ensemble de la vue Code JFR, vous pouvez voir les valeurs agrégées pour chaque package. Il est inhabituel d'avoir cette fonctionnalité.
Vous pouvez également obtenir des informations précises sur le gonflage des verrous. De plus, vous pouvez obtenir des informations qui ne peuvent pas être obtenues par jcmd ou jconsole.
Pour l'activer, sur la ligne de commande qui lance l'application
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder
Reçoit un drapeau.
JFR peut prendre deux méthodes d'enregistrement. Il y a un enregistrement continu pendant une certaine période de temps et un tampon en anneau est utilisé pour l'enregistrement continu.
Vous pouvez spécifier comment enregistrer avec des paramètres tels que -XX: + FlightRecorderOptions = $ {chaîne de paramètres}.
Les options sont décrites dans ici.
Vous pouvez également définir la JVM en cours d'exécution avec la commande suivante (bien que l'option -XX: + FlightRecorder doive être spécifiée à l'avance).
jcmd ${ID de processus} JFR.start [option]
Pour un enregistrement continu, les données du tampon en anneau peuvent être sorties dans un fichier avec la commande suivante.
jcmd ${ID de processus} JFR.dump [option]
Les informations sur l'enregistrement en cours d'exécution peuvent être sorties avec la commande suivante (Au fait, il semble que plusieurs enregistrements puissent être effectués en un seul processus, je me demande donc si elle est souvent utilisée lorsque plusieurs enregistrements sont effectués).
jcmd ${ID de processus} JFR.check [verbose]
À ↓, arrêtez l'enregistrement.
jcmd ${ID de processus} JFR.stop [option]
JFR peut être étendu. Il semble que vous puissiez créer votre propre événement. La collecte d'événements implique inévitablement des frais généraux. Cependant, il y a certains événements que vous souhaitez obtenir même en cas de surcharge. Par exemple, surveillez les événements TLAB (Thread Local Area Buffer) et voyez si les objets sont alloués directement à l'ancienne zone.
Recommended Posts