Witam wszystkich – to już piąty post z naszej serii Quarkus! (Przy okazji obejrzyj nasz webinar
В
Pomiar wydajności jest podstawą niemal każdej aktualizacji, a raportowanie wykorzystania pamięci jest ważną częścią procesu analizy wydajności. Dzisiaj przyjrzymy się odpowiednim narzędziom pomiarowym, które można wykorzystać do ilościowego określenia ulepszeń osiągniętych dzięki modernizacji aplikacji Java.
Więcej informacji na temat pomiaru zużycia pamięci można znaleźć w samouczku Quarkus zatytułowanym
Poniżej po prostu pokażemy, jak porównać dane dotyczące wykorzystania pamięci dla trzech różnych typów aplikacji (JBoss EAP, pakiet JAR i plik wykonywalny), zbierając dane w systemie Linux za pomocą narzędzi pmap i ps.
JBoss EAP
Uruchamiamy instancję aplikacji JBoss EAP (patrz rozdział „Wdrażanie helloworld” w
$ pgrep -lf jboss
7268 java
Uwaga. Opcja –a pozwala wyodrębnić całą linię poleceń (tj. $ pgrep -af jboss).
Teraz używamy PID 7268 w poleceniach ps i pmap.
Oto tak:
$ ps -o pid,rss,command -p 7268
PID RSS COMMAND
7268 665348 java -D[Standalone] -server -verbose:gc -Xloggc:/home/mrizzi/Tools/jboss-eap-7.2.0/jboss-eap-7.2/standalone/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferI
I tak:
$ pmap -x 7268
7268: java -D[Standalone] -server -verbose:gc -Xloggc:/home/mrizzi/Tools/jboss-eap-7.2.0/jboss-eap-7.2/standalone/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/home/mrizzi/Tools/jboss-eap-7.2.0/jboss-eap-7.2/standa
Address Kbytes RSS Dirty Mode Mapping
00000000ae800000 1348608 435704 435704 rw--- [ anon ]
0000000100d00000 1035264 0 0 ----- [ anon ]
000055e4d2c2f000 4 4 0 r---- java
000055e4d2c30000 4 4 0 r-x-- java
000055e4d2c31000 4 0 0 r---- java
000055e4d2c32000 4 4 4 r---- java
000055e4d2c33000 4 4 4 rw--- java
[...]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------- ------- -------
total kB 3263224 672772 643024
Patrzymy na wartość RSS i widzimy, że JBoss EAP zużywa około 650 MB pamięci.
Pakiet JAR
Uruchamiamy aplikację JAR (patrz rozdział „Uruchamianie helloworld spakowanego w JAR” w
$ java -jar ./target/helloworld-<version>-runner.jar
Ponownie sprawdzamy PID za pomocą polecenia pgrep (tym razem używamy opcji -a opisanej powyżej):
$ pgrep -af helloworld
6408 java -jar ./target/helloworld-<version>-runner.jar
Uruchamiamy ps i pmap, aby zmierzyć użycie pamięci, ale teraz dla procesu 6408.
Oto tak:
$ ps -o pid,rss,command -p 6408
PID RSS COMMAND
6408 125732 java -jar ./target/helloworld-quarkus-runner.jar
I tak:
$ pmap -x 6408
6408: java -jar ./target/helloworld-quarkus-runner.jar
Address Kbytes RSS Dirty Mode Mapping
00000005d3200000 337408 0 0 rw--- [ anon ]
00000005e7b80000 5046272 0 0 ----- [ anon ]
000000071bb80000 168448 57576 57576 rw--- [ anon ]
0000000726000000 2523136 0 0 ----- [ anon ]
00000007c0000000 2176 2088 2088 rw--- [ anon ]
00000007c0220000 1046400 0 0 ----- [ anon ]
00005645b85d6000 4 4 0 r---- java
00005645b85d7000 4 4 0 r-x-- java
00005645b85d8000 4 0 0 r---- java
00005645b85d9000 4 4 4 r---- java
00005645b85da000 4 4 4 rw--- java
[...]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------- ------- -------
total kB 12421844 133784 115692
Ponownie przeglądamy kanał RSS i widzimy, że pakiet JAR zajmuje około 130 MB.
Plik wykonywalny
Uruchamiamy natywny (patrz sekcja „Uruchamianie natywnego pliku wykonywalnego helloworld” w
$ ./target/helloworld-<version>-runner
Spójrzmy jeszcze raz na jego PID:
$ pgrep -af helloworld
6948 ./target/helloworld-<version>-runner
Następnie używamy otrzymanego identyfikatora procesu (6948) w poleceniach ps i pmap.
Oto tak:
$ ps -o pid,rss,command -p 6948
PID RSS COMMAND
6948 19084 ./target/helloworld-quarkus-runner
И вот так:
$ pmap -x 6948
6948: ./target/helloworld-quarkus-runner
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 12 12 0 r---- helloworld-quarkus-runner
0000000000403000 10736 8368 0 r-x-- helloworld-quarkus-runner
0000000000e7f000 7812 6144 0 r---- helloworld-quarkus-runner
0000000001620000 2024 1448 308 rw--- helloworld-quarkus-runner
000000000181a000 4 4 4 r---- helloworld-quarkus-runner
000000000181b000 16 16 12 rw--- helloworld-quarkus-runner
0000000001e10000 1740 156 156 rw--- [ anon ]
[...]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------- ------- -------
total kB 1456800 20592 2684
Patrzymy na RSS i widzimy, że plik wykonywalny zajmuje około 20 MB pamięci.
Porównanie zużycia pamięci
Otrzymaliśmy więc następujące liczby dotyczące wykorzystania pamięci:
- JBoss EAP — 650 MB.
- Pakiet JAR – 130 MB.
- Plik wykonywalny – 20 MB.
Oczywiście plik wykonywalny zajmuje znacznie mniej pamięci.
Podsumujmy posty 4 i 5
W tym i poprzednich postach przyglądaliśmy się modernizacji aplikacji Java przy użyciu technologii obsługiwanych przez Quarkus (CDI i Servlet 3), a także różnym sposobom tworzenia, budowania i uruchamiania takich aplikacji. Pokazaliśmy, jak zbierać dane dotyczące wykorzystania pamięci, aby ocenić ulepszenia osiągnięte dzięki takiej aktualizacji. Artykuły te pomogą Ci zrozumieć, jak działa Quarkus i dlaczego jest przydatny — niezależnie od tego, czy mówisz o prostym programie helloworld z naszych przykładów, czy o znacznie bardziej złożonych, rzeczywistych aplikacjach.
Za dwa tygodnie wrócimy z ostatnim postem o Quarkusie – do zobaczenia!
W naszym ostatnim poście pokażemy, jak połączyć AMQ Online i Quarkus, aby zbudować nowoczesny system przesyłania wiadomości oparty na OpenShift, wykorzystując dwie nowe technologie przesyłania wiadomości. Czytaj
Źródło: www.habr.com