Claudio Miranda

Geração de dumps (thread e memory) no WebSphere 6.x

Mon, 19 Oct 2009 16:49:01 -0200

Segue uma dica de como extrair um dump de threads e memória do WebSphere, funciona tanto em unix como em windows.

Acessar a interface administrativa e configurar os parametros

Navegação

Servers -> Application Servers -> Server1 -> Process Definition -> Java Virtual Machine -> Generic JVM arguments

Parâmetro:

-Xdump:system+heap+java:events=gpf+throw+user,filter=java/lang/OutOfMemoryError,request=exclusive+prepwalk

Navegação:

Servers -> Application Servers -> Server1 -> Process Definition > Environment Entries

Parâmetros:

IBM_HEAPDUMP=true
IBM_HEAPDUMP_OUTOFMEMORY=true
IBM_HEAPDUMPDIR=c:\temp

Agora criar um atalho para facilitar o acesso ao script wsadmin, no diretório WAS_HOME/bin.

Windows

* _wsadmin_comm.bat
wsadmin -conntype SOAP -user admin -password senha_do_admin %*

Unix

* _wsadmin_comm.sh
wsadmin -conntype SOAP -user admin -password senha_do_admin $*

Crie scripts JACL (script baseado em TCL) para invocação dos comandos.

Memory Dump

* heapdump.jacl
set jvm [$AdminControl queryNames type=JVM,*]
$AdminControl invoke $jvm generateHeapDump

Thread dump

* threaddump.jacl
set jvm [$AdminControl queryNames type=JVM,*]
$AdminControl invoke $jvm dumpThreads

Para gerar os dumps basta invocar os comandos

_wsadmin_comm.sh -f heapdump.jacl

Veja no diretório especificado em IBM_HEAPDUMPDIR ou no AppServer01 se os arquivos foram gerados em um deles.

Depois use ferramental adequado para analisar os dumps (Eclipse Memory Analyzer, IBM Thread Dump Analyzer).

Palestra Java vs .Net

Mon, 19 Oct 2009 16:25:35 -0200

Irei participar do evento "Java vs .Net", que irá ocorrer em Brasília no dia 24 de outubro e 07 de novembro.

Veja o site para maiores informações.

Vou fazer uma palestra "Linguagem de programação Java e certificação" e participar de um debate com outro palestrante representante da tecnologia .Net.

Achei um momento oportuno de participar de uma discussão como esta, pois parece ainda existir dúvidas sobre a adoção da tecnologia Java ou .Net. Sem dúvida JAVA !

Não vou repetir o que já existe na internet sobre a discussão sobre Java x .Net. Pesquisem e testem por sí mesmos.

O que é importante é que a tecnologia Java é composto por um forte trio: plataforma, linguagem, bibliotecas. Que catapultaram Java para a linguagem de programação mais usada no mundo.

Já trabalhei com diversos clientes e sistemas de uso massivo, e todos eles usavam Java (óbvio) e Unix no servidor, pelo simples fato da plataforma windows não conseguir escalar (depoimento do próprio cliente e por experiência própria) e por consequência o .net.

Vejo algumas razões para alguém adotar .Net:

Não querer/poder desprender da tecnologia .Net
API para desktop e integração com o windows
Contratos de fornecimento de software combinado em larga escala

Quem tive maior curiosidade participe do evento, confira a programação de palestras.

Outros renomados palestrantes e profissionais do mundo Java irão participar do evento, assim como personalidades do mundo .net.

Conheço alguns dos palestrantes: Daniel de Oliveira (DFJUG), João Paulo Viragine (RedHat), Rafael Benevides (RedHat), Marcelo Ancelmo (Lado Servidor), Paulo Jeronimo (Lado Servidor).

Veja a chamada do evento:

O evento “Plataforma Java x Plataforma .NET - Edição DF 2009” tem como objetivo promover debates técnicos abordando diversos temas. Na edição DF 2009, o evento conta com palestrantes de alto nível técnico para representarem as plataformas Java e .NET. Diversos parceiros estão apoiando o evento, incluindo empresas, grupos de usuários, instituições de educação superior, revistas e Web Sites. O evento é beneficente e todas as inscrições representam doações para um projeto social.

An internal error occurred while showing an internal error

Fri, 2 Oct 2009 01:20:41 -0300

An internal error occurred while showing an internal error.

Tem coisas que só o Eclipse faz para você.

Palestra na Universidade Catolica

Tue, 18 Aug 2009 20:16:54 -0300

Dia 19 de agosto - quarta-feira - vou à Universidade Católica em Taguatinga, para participar do evento "Encontro Regional de Informática do Centro-Oeste I", fui convidado para participar com uma palestra. Irei falar sobre "Gerenciamento de Memória pela Maquina Virtual Java.

Pretendo mostrar como funciona a alocação de memória e a limpeza automática (vulgo Garbage Collector), seus algoritmos e algumas boas práticas para o programador exercer um bom trabalho.

O evento será na Universidade Católica, Campus Taguatinga, Auditório Central do Prédio São João Batista de La Salle. O horário é 21h.

O evento conta com outras palestras sobre os temas: processamento de imagens, Datawarehouse e OLAP, processamento de sinais, Cloud Computing, Gestão de Segurança, Computação de Alto Desempenho, Computação Invisível.

Os minicursos também fazem parte do evento: Data Mining, PlayStation 3 em computação de alto desempenho, Ruby on Rails, Criptografia, Linux.

Update: A palestra está disponível para olhar ou copiar.

Gerenciamento de Memória pela JVM

View more documents from Claudio Miranda.

Como reduzir espaço em disco do JDK em ambiente servidor

Fri, 6 Mar 2009 01:22:02 -0300

No decorrer dos anos, as novas versões do JDK estavam acompanhadas de novas funcionalidades, bibliotecas, etc.

E sempre existiram comentários na comunidade, sobre o tamanho do JDK e o espaço ocupado pelo JDK, após a instalação.

Pois vou dar uma dica de como remover arquivos desnecessários do JDK em ambiente servidor. Na maioria das vezes, isso só será necessário se uma economia de 100MB for importante. Ou instalações em rede com imagem, para poupar tempo de download para outras estações.

A dica é baseada em um ambiente Linux 32 bits, com uma instalação padrão do JDK 6 update 12.

A instalação padrão ocupa um espaço de 239 MB. Veja a ocupação de espaço nas versões anteriores do JDK.

82M     j2sdk1.4.2_18
141M    jdk1.5.0_16
239M    jdk1.6.0_12

Uma boa evolução no espaço ocupado.

Veja os arquivos que podem ser removidos, e o tamanho que será economizado em disco.

7.9M    sample/
20M     demo/
19M     src.zip
4.3M    db/demo/
18M     db/docs/
2.1M    db/javadoc/
96K     db/lib/derbyLocale_cs.jar
100K    db/lib/derbyLocale_de_DE.jar
92K     db/lib/derbyLocale_es.jar
100K    db/lib/derbyLocale_fr.jar
96K     db/lib/derbyLocale_hu.jar
92K     db/lib/derbyLocale_it.jar
108K    db/lib/derbyLocale_ja_JP.jar
104K    db/lib/derbyLocale_ko_KR.jar
96K     db/lib/derbyLocale_pl.jar
92K     db/lib/derbyLocale_pt_BR.jar
120K    db/lib/derbyLocale_ru.jar
96K     db/lib/derbyLocale_zh_CN.jar
96K     db/lib/derbyLocale_zh_TW.jar
23M     lib/visualvm/
94M     total

Uma economia de 94 MB

Estes arquivos não são necessários em ambiente servidor. Com exceção de alguns arquivos do visualvm, que possui as bibliotecas nativas para efetuar profiling remoto, mas isso geralmente não é necessário em ambiente servidor de testes ou produção, ou alguém faz prifiling em produção ?

No caso dos arquivos de i18n do derby, prefiro usar os termos em inglês, pois acho conveniente que os termos técnicos sejam em inglês (meu ponto de vista sobre o caso).

Geração de heap dump no linux 64 bits

Thu, 2 Oct 2008 01:28:59 -0300

Estou em um trabalho para um cliente envolvendo melhorias de performance na aplicação e no ambiente operacional (appserver, sistema operacional, jvm).

O ambiente é Linux 64 bits (RedHat, kernel 2.6.18 SMP), JDK 5 e Glassfish v2 ur2.

Em um dado momento, precisei gerar um heap dump, mas ocorreu um erro sun.jvm.hotspot.debugger.UnmappedAddressException.

# /usr/local/jdk/jdk1.6.0_07/bin/jmap -J-d64 -F -dump:file=java_dump_10791.hprof  10791
Attaching to process ID 10791, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 10.0-b23
Dumping heap to java_dump_10791.hprof ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.tools.jmap.JMap.runTool(JMap.java:178)
        at sun.tools.jmap.JMap.main(JMap.java:110)
Caused by: sun.jvm.hotspot.debugger.UnmappedAddressException
        at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
        at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63)
        at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:205)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:471)
        at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:442)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readOopHandle(LinuxDebuggerLocal.java:431)
        at sun.jvm.hotspot.debugger.linux.LinuxAddress.getOopHandleAt(LinuxAddress.java:115)
        at sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:222)
        at sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:348)
        at sun.jvm.hotspot.utilities.HashtableEntry.literal(HashtableEntry.java:53)
        at sun.jvm.hotspot.memory.SymbolTable.symbolsDo(SymbolTable.java:106)
        at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbols(HeapHprofBinWriter.java:830)
        at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:396)
        at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:56)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
        at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77)

Tentei gerar o dump através de:

-XX:+HeapDumpOnCtrlBreak and kill -3
jmap -heap:format=b
gcore utility

Com isso decidi usar o JDK 6 u7 (changelog), mas ocorreu o mesmo problema.

UPDATE: A stacktrace mostrada acima, mostra a invocação de um comando jmap do JDK 6 u7, para uma VM 6 u7.
UPDATE: Anteriormente, quando estava com JDK 5 u12, tentei rodar o jmap a partir de uma VM 5 u12, mas o mesmo erro ocorreu
UPDATE: A VM não está com a opção -Xrs option.
UPDATE: O usuário que iniciou o processo é o mesmo que usei para invocar o comando jmap, root.

UPDATE: Alan Bateman, explicou sobre o uso da opção -F "A opção -F faz como que a ferramenta se conecte no processo de uma maneira não colaborativa e pode causa a geração de um dump inconsistente. Em outras palavras, não há garantia de que será um bom heap dump ao usar a opção -F", veja este comentário em inglês na seção de comentários abaixo.

Então encontrei um bug corrigido "Throws UnmappedAddressException while reading address from core file in shared area.", entao decidi usar o JDK 6 u10 RC.

Coloquei a opção -Xshare:off

E funcionou muito bem,o processo não foi derrubado e a aplicação funcionou normalmente.

Não esqueça que no momento do heap a JVM paralisa todas as threads e o arquivo gerado será tão grande (ou um pouco menor) como a memória RSS usada pelo processo.

Então, se for gerar heap dump em linux 64 bits, use o JDK 6 u10 RC com a opção -Xshare:off.

Ao final da geração do heap dump, as mensagens abaixo foram impressas

"Finding object size using Printezis bits and skipping over..."

Obrigado Tony, pelo seu trabalho no HotSpot.

Ferramentas de diagnóstico em performance na prática

Tue, 9 Sep 2008 02:57:58 -0300

Tenho efetuado a palestra sobre diagnóstico em problemas de performance, desde 2006 em diversos eventos.

Pelo feedback que recebo, percebo que este é um assunto de interesse para um numeroso grupo de profissionais.

Então, é por isso que você que é interessado em entender mais sobre performance, garbage collector, thread pools, thread dumps e memory dumps, deve comparecer no próximo dia 12 (sexta-feira) as 9h no Senac, onde ocorre o JustJava. Pois irei realizar um workshop na prática sobre este assunto.

O nome é "Diagnóstico e Resolução de Problemas de Performance em Java", é requerido trazer o laptop para máximo aproveitamento.

O workshop (hands-on lab), será um misto de palestra com exercícios sobre o tema. Será seguido (tentativa) o seguinte roteiro:

Explicação sobre um tópico
Demonstração
Fazer com que os atendentes resolvem um exercício

Os tópicos serão

Gerenciamento de memória do Java
Ferramentas para diagnóstico
Thread Dumps
Memory Dumps
Ferramentas para profiling

Para um máximo rendimento para o atendente, é necessário seguir alguns pontos:

Usar sistema operacional Linux (pode ser em uma VM)
Ter interface wireless funcionando
Trazer instalado e funcionando os seguintes sistemas

Sun JDK 6 Update 10 RC (invoque o bin/jvisualvm e instale todos os plugins)
NetBeans 6.1
Glassfish v2 ur 2
IBM Heap Analyzer
IBM Thread Dump Analyzer
Thread Dump Analyzer
Apache JMeter

Configurem as variáveis JAVA_HOME e PATH=$JAVA_HOME/bin

O uso do Linux não é obrigatório, mas facilita muito, e irei basear meus exemplos nele.

Note, que o tempo do workshop não será prejudicado, por aqueles que não possuem os sistemas instalados. Pois o tempo é curto para muito conteúdo de não fácil absorção.

Não posso esperar pela próxima sexta, para divertir com thread dumps, pools estourando e memória escorrendo pelos buracos do laptop.