web-dev-qa-db-fra.com

Outil de ligne de commande permettant de trouver Java Taille du segment de mémoire et mémoire utilisée (Linux)?

Existe-t-il un outil de ligne de commande (Linux) permettant de vérifier la taille de segment de mémoire (et la mémoire utilisée) d'une application Java?

J'ai essayé jmap. Mais ça donne des infos. sur les zones de mémoire interne comme Eden/PermGen, etc., qui ne m’est pas utile.

Je cherche quelque chose comme:
Mémoire Max: 1Go
Mémoire minimale: 256 Mo
Mémoire de tas: 700 Mo
Mémoire utilisée: 460 Mo

C'est tout. Je sais que je peux voir cela dans JConsole etc., mais j'ai besoin d'un outil en ligne de commande (impossible d'activer JMX, etc.)

Un tel outil/commande?

javalinuxmemoryheap
141
Jasper

Chaque processus Java a une pid, que vous devez d'abord trouver avec la commande jps.

Une fois que vous avez le pid, vous pouvez utiliser jstat -gc [insert-pid-here] pour trouver des statistiques sur le comportement du segment de mémoire récupéré.

  • jstat -gccapacity [insert-pid-here] présentera des informations sur la génération de pools de mémoire et les capacités d'espace.

  • jstat -gcutil [insert-pid-here] présentera l'utilisation de chaque génération sous forme de pourcentage de sa capacité. Utile pour avoir un aperçu de l'utilisation.

Voir jstat docs sur le site d'Oracle.

134
farmer1992

jvmtop est un outil de ligne de commande qui fournit une vue en direct de plusieurs mesures, y compris de tas.

Exemple de sortie du mode de vue d'ensemble VM:

 JvmTop 0.3 alpha (expect bugs)  AMD64  8 cpus, Linux 2.6.32-27, load avg 0.12
 http://code.google.com/p/jvmtop

  PID MAIN-CLASS      HPCUR HPMAX NHCUR NHMAX    CPU     GC    VM USERNAME   #T DL
 3370 rapperSimpleApp  165m  455m  109m  176m  0.12%  0.00% S6U37 web        21
11272 ver.resin.Resin [ERROR: Could not attach to VM]
27338 WatchdogManager   11m   28m   23m  130m  0.00%  0.00% S6U37 web        31
19187 m.jvmtop.JvmTop   20m 3544m   13m  130m  0.93%  0.47% S6U37 web        20
16733 artup.Bootstrap  159m  455m  166m  304m  0.12%  0.00% S6U37 web        46
60
MRalwasser

Cette commande affiche les tailles de segment configurées en octets.

Java -XX:+PrintFlagsFinal -version | grep HeapSize

Cela fonctionne également sur Amazon AMI sur EC2.

52
Atma

Essayez ceci a fonctionné dans Ubuntu et RedHat:

Java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize|PermSize|ThreadStackSize'

Pour les fenêtres:

Java -XX:+PrintFlagsFinal -version | findstr /i "HeapSize PermSize ThreadStackSize"

Pour Mac

Java -XX:+PrintFlagsFinal -version | grep -iE 'heapsize|permsize|threadstacksize'

La sortie de toutes ces commandes ressemble à la sortie ci-dessous:

uintx InitialHeapSize                          := 20655360        {product}
uintx MaxHeapSize                              := 331350016       {product}
uintx PermSize                                  = 21757952        {pd product}
uintx MaxPermSize                               = 85983232        {pd product}
intx ThreadStackSize                           = 1024            {pd product}
Java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)

Pour trouver la taille en Mo, divisez la valeur par (1024 * 1024).

33
padippist

Sans utiliser JMX, comme le font la plupart des outils, vous ne pouvez utiliser que

jps -lvm

et en déduire que les paramètres proviendront des options de la ligne de commande.

Vous ne pouvez pas obtenir d'informations dynamiques sans JMX par défaut, mais vous pouvez écrire votre propre service pour le faire.

BTW: Je préfère utiliser VisualVM plutôt que JConsole.

24
Peter Lawrey

Il existe un outil en ligne de commande avec un aspect visuel - jvm-mon . C'est un outil de surveillance de la machine virtuelle Java pour la ligne de commande qui désinitialise:

  • utilisation du tas, taille et max
  • processus jvm
  • utilisation du processeur et du GC
  • fils supérieurs

Les métriques et les graphiques sont mis à jour lorsque l'outil est ouvert.

Échantillon: jvm-mon

18
Andrejs

Tard à la fête, mais une solution très simple consiste à utiliser le script jpsstat.sh. Il fournit un simple live mémoire courante , mémoire maximum et cpu utilise les détails.

  • Allez à projet GitHub et téléchargez le fichier jpsstat.sh
  • Faites un clic droit sur les autorisations jpsstat.sh et goto et rendez-le exécutable.
  • Maintenant, lancez le script en utilisant la commande suivante ./ jpsstat.sh

Voici l'exemple de sortie du script -

=====  ======  =======  =======  =====
 PID    Name   CurHeap  MaxHeap  %_CPU
=====  ======  =======  =======  =====
2777   Test3      1.26     1.26    5.8
2582   Test1      2.52     2.52    8.3
2562   Test2      2.52     2.52    6.4
7
amarjeetAnand

Toute approche devrait vous donner à peu près le même nombre. C'est toujours une bonne idée d'allouer le tas en utilisant -X..m-X..x pour toutes les générations. Vous pouvez ensuite garantir et également consulter les ps pour voir quels paramètres ont été transmis et donc utilisés.

Pour les utilisations de mémoire réelles, vous pouvez comparer approximativement les valeurs de VIRT (alloué et partagé) et de RES (utilisation réelle) aux valeurs de jstat:

Pour Java 8, voir jstat pour ces valeurs signifient réellement. En supposant que vous exécutiez une classe simple sans mmap ni traitement de fichier.

$ jstat -gccapacity 32277
 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC       MCMN     MCMX      MC     CCSMN    CCSMX     CCSC    YGC    FGC
215040.0 3433472.0  73728.0  512.0  512.0  67072.0   430080.0  6867968.0   392704.0   392704.0      0.0 1083392.0  39680.0      0.0 1048576.0   4864.0   7225     2

$ jstat -gcutil 32277
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  6.25   0.00   7.96  18.21  98.01  95.29   7228   30.859     2    0.173   31.032

Max :

     NGCMX + S0C + S1C + EC    + OGCMX   + MCMX    + CCSMX
   3433472 + 512 + 512 + 67072 + 6867968 + 1083392 + 1048576 = 12 GB

(à peu près proche et en dessous de la mémoire VIRT)

Max (Min, Utilisé): 

215040 + 512 + 512 + 67072 + 430080  + 39680    +  4864  = ~ 1GB

(à peu près proche de la mémoire RES)

"Ne me citez pas sur ce point" mais le meme VIRT est plus ou moins proche de Max que la memoire allouee, mais tant que la memoire utilisee est libre/disponible dans la mémoire physique, JVM ne lève pas d'exception de mémoire. En fait, la mémoire maximale n'est même pas vérifiée par rapport à la mémoire physique au démarrage de la machine virtuelle, même avec le remplacement du système d'exploitation. Une meilleure explication de ce que la mémoire virtuelle réellement utilisée par un processus Java est discutée ici .

5
kisna

A partir de Java8 et supérieur , vous pouvez utiliser la commande ci-dessous:

jcmd Java_PROCESS_ID GC.heap_info

Vous pouvez vous référer à la somme de, la mémoire totale et utilisée de la sortie.

Sample Command And Output: jcmd 9758 GC.heap_info

PSYoungGen  total 1579520K, used 487543K [0x0000000751d80000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 1354240K, 36% used [0x0000000751d80000,0x000000076f99dc40,0x00000007a4800000)
  from space 225280K, 0% used [0x00000007b2400000,0x00000007b2400000,0x00000007c0000000)
  to   space 225280K, 0% used [0x00000007a4800000,0x00000007a4800000,0x00000007b2400000)
ParOldGen       total 3610112K, used 0K [0x0000000675800000, 0x0000000751d80000, 0x0000000751d80000)
  object space 3610112K, 0% used [0x0000000675800000,0x0000000675800000,0x0000000751d80000)
Metaspace       used 16292K, capacity 16582K, committed 16896K, reserved 1064960K
  class space    used 1823K, capacity 1936K, committed 2048K, reserved 1048576K

Pour plus de détails sur la commande jcmd, visitez le lien: https://docs.Oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html

3
vaibhav gupta

Commencez par obtenir l'identifiant du processus, le premier numéro du processus répertorié, parmi les suivants: (ou utilisez simplement ps aux | grep Java, si vous préférez cela)

jps -lvm

Ensuite, utilisez l'ID de processus ici:

jmap -heap $MY_PID 2>/dev/null | sed -ne '/Heap Configuration/,$p';
jmap -permstat $MY_PID
2
sjas

L'utilisation de la commande top est le moyen le plus simple de vérifier l'utilisation de la mémoire du programme. La colonne RES indique la mémoire physique réelle occupée par un processus.

Pour mon cas, j'avais un fichier 10g lu dans Java et à chaque fois, j'ai une exception outOfMemory. Cela s'est produit lorsque la valeur de la colonne RES a atteint la valeur définie dans l'option -Xmx. Ensuite, en augmentant la mémoire avec l'option -Xmx, tout s'est bien passé.

1
M. Mashaye
jstat -gccapacity javapid  (ex. stat -gccapacity 28745)
jstat -gccapacity javapid gaps frames (ex.  stat -gccapacity 28745 550 10 )

Échantillon O/P de la commande ci-dessus

NGCMN    NGCMX     NGC     S0C  
87040.0 1397760.0 1327616.0 107520.0 

NGCMN   Minimum new generation capacity (KB).
NGCMX   Maximum new generation capacity (KB).
NGC Current new generation capacity (KB).

Obtenez plus de détails à ce sujet sur http://docs.Oracle.com/javase/1.5.0/docs/tooldocs/share/jstat.html

1
Pravin

En termes de Java taille du segment de mémoire, sous Linux, vous pouvez utiliser

ps aux | grep Java

ou

ps -ef | grep Java

et recherchez -Xms, -Xmx pour connaître les tailles de tas initiale et maximale spécifiées.

Cependant, si -Xms ou -Xmx est absent du processus Java qui vous intéresse, cela signifie que votre processus Java utilise les tailles de segment par défaut. Vous pouvez utiliser la commande suivante pour connaître les tailles par défaut.

Java -XX:+PrintFlagsFinal -version | grep HeapSize

ou un JVM particulier, par exemple,

/path/to/jdk1.8.0_102/bin/Java -XX:+PrintFlagsFinal -version | grep HeapSize

et recherchez InitialHeapSize et MaxHeapSize, qui est en octets.

1
Yuci

Si vous utilisez jrockit, essayez l’outil de ligne de commande jrcmd. Par exemple:

$ jrcmd 5127 print_memusage
5127:
Total mapped                  1074596KB           (reserved=3728KB)
-              Java heap       786432KB           (reserved=0KB)
-              GC tables        26316KB          
-          Thread stacks        13452KB           (#threads=34)
-          Compiled code         9856KB           (used=9761KB)
-               Internal          840KB          
-                     OS        15036KB          
-                  Other       146632KB          
-        Java class data        75008KB           (malloced=74861KB #103221 in 18709 classes)
- Native memory tracking         1024KB           (malloced=102KB #8)

Pour plus de commandes, comme heap_diagnostics, utilisez "jrcmd help" pour les lister.

https://blogs.Oracle.com/jrockit/entry/why_is_my_jvm_process_larger_t

1
guest

Il n’existait pas d’outil jusqu’à présent pour imprimer la mémoire de tas dans le format que vous aviez demandé Le seul et unique moyen d’imprimer est d’écrire une Java programme avec l'aide de Runtime Class ,

public class TestMemory {

public static void main(String [] args) {

    int MB = 1024*1024;

    //Getting the runtime reference from system
    Runtime runtime = Runtime.getRuntime();

    //Print used memory
    System.out.println("Used Memory:" 
        + (runtime.totalMemory() - runtime.freeMemory()) / MB);

    //Print free memory
    System.out.println("Free Memory:" 
        + runtime.freeMemory() / mb);

    //Print total available memory
    System.out.println("Total Memory:" + runtime.totalMemory() / MB);

    //Print Maximum available memory
    System.out.println("Max Memory:" + runtime.maxMemory() / MB);
}

}

référence: https://viralpatel.net/blogs/getting-jvm-heap-size-used-memory-total-memory-using-Java-runtime/

0
Gowtham Prasath