Narzędzie wiersza polecenia do znajdowania rozmiaru sterty Java i używanej pamięci (Linux)?

Czy istnieje narzędzie wiersza polecenia (Linux) do sprawdzania rozmiaru sterty (i używanej pamięci) aplikacji Java?

Próbowałem przez jmap. Ale daje informacje. o obszarach pamięci wewnętrznej, takich jak Eden / PermGen itp., co nie jest dla mnie przydatne.

Szukam czegoś takiego:

• Maksymalna pamięć: 1 GB
• Minimalna pamięć: 256 MB
• Pamięć sterty: 700 MB
• Używana pamięć: 460 MB

To wszystko. Wiem, że widzę to w JConsole itp., Ale potrzebuję narzędzia wiersza poleceń (nie mogę włączyć JMX itp.)

Czy znasz takie narzędzie / polecenie?

Każdy proces Java ma pidrozszerzenie, które należy najpierw znaleźć za pomocą jpspolecenia.

Gdy już masz pid, możesz go użyć, jstat -gc [insert-pid-here]aby znaleźć statystyki zachowania sterty zebranych śmieci.

• jstat -gccapacity [insert-pid-here] przedstawi informacje o generowaniu puli pamięci i możliwościach przestrzeni.

• jstat -gcutil [insert-pid-here]przedstawi wykorzystanie każdej generacji jako procent jej mocy. Przydatne, aby uzyskać szybki wgląd w użycie.

Zobacz dokumentację jstat w witrynie Oracle.

jvmtop to narzędzie wiersza poleceń, które zapewnia podgląd na żywo kilku wskaźników, w tym sterty.

Przykładowe dane wyjściowe trybu przeglądu 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

To polecenie wyświetla skonfigurowane rozmiary sterty w bajtach.

java -XX:+PrintFlagsFinal -version | grep HeapSize

Działa również na Amazon AMI na EC2.

Wypróbuj to zadziałało w Ubuntu i RedHat:

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

Dla Windowsa:

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

Dla Maca

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

Dane wyjściowe wszystkich tych poleceń przypominają poniższe:

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)

Aby znaleźć rozmiar w MB, podziel wartość przez (1024 * 1024).

Bez używania JMX, którego używa większość narzędzi, jedyne, co możesz zrobić, to użyć

jps -lvm

i wywnioskować, że ustawienia będą pochodzić z opcji wiersza poleceń.

Domyślnie nie możesz uzyskać dynamicznych informacji bez JMX, ale możesz napisać własną usługę, aby to zrobić.

BTW: Wolę używać VisualVM zamiast JConsole.

Istnieje narzędzie wiersza poleceń z aspektem wizualnym - jvm-mon . Jest to narzędzie do monitorowania maszyny JVM dla wiersza poleceń, które źle znosi:

• użycie sterty, rozmiar i maks
• procesy jvm
• użycie procesora i GC
• najpopularniejsze wątki

Metryki i wykresy są aktualizowane, gdy narzędzie jest otwarte.

Próba:

Spóźniona impreza, ale bardzo prostym rozwiązaniem jest użycie skryptu jpsstat.sh. Zapewnia prostą aktualną pamięć , maksymalną pamięć i szczegóły użycia procesora .

• Przejdź do projektu GitHub i pobierz plik jpsstat.sh
• Kliknij prawym przyciskiem myszy jpsstat.sh i przejdź do zakładki uprawnień i ustaw ją jako wykonywalną
• Teraz uruchom skrypt za pomocą następującego polecenia ./jpsstat.sh

Oto przykładowe wyjście skryptu -

=====  ======  =======  =======  =====
 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

W moim przypadku musiałem sprawdzić flagi wewnątrz kontenera docker, który nie miał większości podstawowych narzędzi (ps, pstree ...)

Używając jps, otrzymałem PID uruchomionej maszyny JVM (w moim przypadku 1), a następnie jcmd 1 VM.flagsotrzymałem flagi z uruchomionej maszyny JVM.

To zależy od dostępnych poleceń, ale może to komuś pomóc. :)

Z Java8 i nowszych możesz użyć poniższego polecenia:

jcmd JAVA_PROCESS_IDGC.heap_info

Możesz odwołać się do sumy, całkowitej i używanej pamięci z wyjścia.

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

Aby uzyskać więcej informacji na temat polecenia jcmd, odwiedź link: https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html

Każde podejście powinno dać mniej więcej taką samą liczbę. Zawsze dobrze jest przydzielić stertę -X..m -X..xdla wszystkich pokoleń. Możesz wtedy zagwarantować, a także zrobić ps, aby zobaczyć, jakie parametry zostały przekazane, a zatem są używane.

W przypadku rzeczywistego wykorzystania pamięci można z grubsza porównać VIRT (przydzielone i współdzielone) i RES (faktycznie używane) w porównaniu z wartościami jstat:

W przypadku języka Java 8 zobacz jstat, gdzie te wartości faktycznie oznaczają. Zakładając, że uruchamiasz prostą klasę bez mmap lub przetwarzania plików.

$ 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

Maks . :

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

(mniej więcej blisko i poniżej pamięci VIRT)

Max (min, używane):

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

(z grubsza zbliżone do pamięci RES)

„Nie cytuj mnie w tej sprawie”, ale VIRT mem jest mniej więcej blisko lub więcej niż przydzielona maksymalna ilość pamięci, ale dopóki używana pamięć jest wolna / dostępna w pamięci fizycznej, JVM nie zgłasza wyjątku pamięci. W rzeczywistości maksymalna pamięć nie jest nawet porównywana z pamięcią fizyczną podczas uruchamiania maszyny JVM, nawet przy wyłączonej wymianie w systemie operacyjnym. Lepsze wyjaśnienie tego, jaka pamięć wirtualna naprawdę jest używana przez proces Java, jest omówione tutaj .

Najpierw uzyskaj identyfikator procesu, pierwszą liczbę z wymienionego procesu, z jednego z następujących: (lub po prostu użyj ps aux | grep java, jeśli wolisz)

jps -lvm

Następnie użyj tutaj identyfikatora procesu:

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

Użycie toppolecenia to najprostszy sposób sprawdzenia wykorzystania pamięci programu.RESkolumna pokazuje rzeczywistą pamięć fizyczną zajmowaną przez proces.

W moim przypadku odczytałem plik 10g w Javie i za każdym razem, gdy otrzymałem wyjątek outOfMemory. Stało się tak, gdy wartość w RESkolumnie osiągnęła wartość ustawioną w -Xmxopcji. Następnie poprzez zwiększenie pamięci za pomocą -Xmxopcji wszystko poszło dobrze.

Jeśli chodzi o rozmiar sterty Java, w systemie Linux można użyć

ps aux | grep java

lub

ps -ef | grep java

i poszukaj -Xms, -Xmx, aby dowiedzieć się o początkowej i maksymalnej określonej wielkości sterty.

Jeśli jednak dla interesującego procesu Java nie ma opcji -Xms lub -Xmx, oznacza to, że proces Java używa domyślnych rozmiarów sterty. Możesz użyć następującego polecenia, aby znaleźć domyślne rozmiary.

java -XX:+PrintFlagsFinal -version | grep HeapSize

lub konkretny plik jvm, na przykład

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

i poszukaj InitialHeapSize i MaxHeapSize, które są w bajtach.

Jeśli używasz jrockit, wypróbuj narzędzie wiersza poleceń jrcmd. Na przykład:

$ 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)

Aby uzyskać więcej poleceń, takich jak heap_diagnostics, użyj „jrcmd help”, aby je wyświetlić.

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

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

Przykładowe O / P powyższego polecenia

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).

Więcej informacji na ten temat można znaleźć pod adresem http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstat.html

Do tej pory nie ma takiego narzędzia do drukowania pamięci sterty w formacie, o który prosiłeś Jedynym i jedynym sposobem drukowania jest napisanie programu java przy pomocy 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ódło: https://viralpatel.net/blogs/getting-jvm-heap-size-used-memory-total-memory-using-java-runtime/

Znajdź identyfikator procesu swojego procesu webapp / java od góry. Użyj sterty jmap, aby uzyskać alokację sterty. Przetestowałem to na AWS-Ec2 dla elastycznej łodygi fasoli

Możesz zobaczyć na obrazku poniżej maksymalne sterty 3 GB dla aplikacji