Olá a todos – estamos com o quinto post da nossa série sobre Quarkus! (A propósito, assista ao nosso webinar . Vamos mostrar como começar "do zero" ou migrar soluções existentes)
Em discutimos a modernização de aplicações Java usando tecnologias suportadas pelo Quarkus (CDI e Servlet 3) com base no exemplo do programa helloworld do repositório . Hoje vamos continuar o tema da modernização e discutir a questão do consumo de memória.
Medição de desempenho é a base fundamental de praticamente qualquer modernização, e relatórios de uso de memória são uma parte importante do processo de análise de desempenho. Hoje vamos explorar as ferramentas de medição adequadas que permitem avaliar quantitativamente as melhorias obtidas com a modernização de aplicações Java.
Mais detalhes sobre a medição do uso de memória podem ser encontrados no guia Quarkus intitulado
E abaixo, vamos mostrar como comparar os dados de uso de memória entre três tipos diferentes de aplicações (JBoss EAP, pacote JAR e arquivo executável), coletando esses dados no Linux usando as utilitários pmap e ps.
JBoss EAP
Executamos uma instância da aplicação JBoss EAP (veja a seção "Implantando helloworld" em ) e em seguida verificamos seu identificador de processo PID (neste exemplo, é 7268) com o seguinte comando:
$ pgrep -lf jboss
7268 java
Observação. A opção –a permite extrair a linha de comando completa (ou seja: $ pgrep -af jboss).
Agora, usamos o PID 7268 nos comandos ps e pmap.
Assim:
$ 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
E é assim:
$ 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
Endereço Kbytes RSS Sujo Modo Mapeamento
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
Observamos o valor do RSS e vemos que o JBoss EAP consome cerca de 650 MB de memória.
Pacote JAR
Executamos o aplicativo JAR (veja a seção "Executando helloworld empacotado em JAR" em ):
$ java -jar ./target/helloworld-<version>-runner.jar
Novamente, observamos o PID usando o comando pgrep (desta vez usamos a opção -a mencionada acima):
$ pgrep -af helloworld
6408 java -jar ./target/helloworld-<version>-runner.jar
Executamos ps e pmap para medir o uso de memória, mas agora para o processo 6408.
Assim:
$ ps -o pid,rss,command -p 6408
PID RSS COMANDO
6408 125732 java -jar ./target/helloworld-quarkus-runner.jar
E é assim:
$ pmap -x 6408
6408: java -jar ./target/helloworld-quarkus-runner.jar
Endereço Kbytes RSS Sujo Modo Mapeamento
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
Novamente, observamos o RSS e vemos que o pacote JAR consome cerca de 130 MB.
Arquivo executável
Executamos o executável nativo (veja a seção "Executando o arquivo executável nativo helloworld" em ):
$ ./target/helloworld-<version>-runner
Novamente, verificamos seu PID:
$ pgrep -af helloworld
6948 ./target/helloworld-<version>-runner
E então usamos o identificador de processo obtido (6948) nos comandos ps e pmap.
Assim:
$ ps -o pid,rss,command -p 6948
PID RSS COMMAND
6948 19084 .\/target\/helloworld-quarkus-runner
E assim:
$ pmap -x 6948
6948: .\/target\/helloworld-quarkus-runner
Endereço Kbytes RSS Dirty Modo Mapeamento
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
Verificamos o RSS e vemos que o arquivo executável ocupa cerca de 20 MB de memória.
Comparando o consumo de memória
Assim, obtivemos os seguintes números sobre o uso de memória:
- JBoss EAP – 650 MB.
- Pacote JAR – 130 MB.
- Arquivo executável – 20 MB.
É evidente que o arquivo executável ocupa muito menos memória.
Sumarizando os posts 4 e 5
Neste post e no anterior, discutimos a modernização de aplicativos Java usando tecnologias suportadas pelo Quarkus (CDI e Servlet 3), além de diferentes maneiras de desenvolver, compilar e executar tais aplicativos. Demonstramos como coletar dados sobre o uso de memória para avaliar as melhorias alcançadas como resultado dessa modernização. Esses artigos ajudam a entender como funciona o Quarkus e qual é seu benefício – independentemente de estarmos falando do simples programa helloworld de nossos exemplos ou de aplicativos muito mais complexos da vida real.
Voltaremos em duas semanas com o post final sobre Quarkus – até lá!
No nosso post final, mostraremos como unir o AMQ Online e o Quarkus para construir um sistema moderno de troca de mensagens baseado em OpenShift usando duas novas tecnologias relacionadas ao processamento de mensagens. Leia em .
Fonte: habr.com
