-
Sprint 0
- 0.1. criar formulário base de autoeficácia;
- 0.2. criar/copiar atividades no Google ClassRoom (conversar com o Alefh);
- 0.3. criar repositório no Github com as atividades em markdown;
- 0.4. seguir pipeline de entrega de vídeos no ClubHouse (sugerido pelo Alefh);
- 0.5. encontrar modelo/método formal de troubleshooting
- 0.6. criar formulários extras de multipla-escolha (conversar com Geraldo);
-
Introdução a JVM e modelo de memoria
- 1.1. gravar video: introdução a JVM, memoria e GC
- 1.2. gravar video: monitorando a JVM
- 1.3. gravar video: setando parametros de memoria da JVM
- 1.4. gravar video: introdução a jMeter: criando testes de carga para sua aplicação
- 1.5. criar formulário auto-percepção: criar formulário que exercite a teoria vista nos vídeos acima;
- 1.6. criar formulário caminho cognitivo: criar formulário que exercite a teoria vista nos vídeos acima;
- 1.7. criar atividade: troubleshooting para problema de OutOfMemoryError
- cenário: aplicação começou pequena e funcionou bem no primeiro ano, mas com o passar do tempo ela cresceu (novas features, adotação de novas libs, mais usuários, mais dados etc) sem qualquer ajuste nos recursos da máquina ou aplicação (CPU, RAM e disco), dessa forma 1x por dia ocorre um OutOfMemoryError e os devs são obrigados a reiniciar a aplicação por não terem tempo para analisar a causa raiz e resolver;
- culpado: o problema é que os parâmetros da JVM nunca foram revisitados desde o primeiro deploy em produção; a aplicação cresceu e sua Heap que antes era suficiente não é mais;
- solução: estressar a aplicação e avaliar o momento em que o erro ocorre olhando logs (ou erros na API REST); monitorar a Heap da JVM para encontrar o tamanho da Heap ideal para nosso workload para suportar a evolução da aplicação; a solução de fato aqui é encontrar e setar os parâmetros da JVM (algo como
-Xms512M -Xmx1024M
);
- 1.8. gravar video: solução do especialista para atividade
-
Detectando vazamentos de memoria
- 2.1. gravar video: entendendo vazamento de memoria numa aplicação Java
- 2.2. gravar video: gerando e analisando dump de memoria (heap dump)
- 2.3. gravar video: gerando dump de memoria (heap dump) em produção (uso de
-XX:+HeapDumpOnOutOfMemoryError
) - 2.4. criar formulário auto-percepção: criar formulário que exercite a teoria vista nos vídeos acima;
- 2.5. criar formulário caminho cognitivo: criar formulário que exercite a teoria vista nos vídeos acima;
- 2.6. criar atividade: troubleshooting para memory leak na aplicação
- cenário: aplicação funciona muito bem porém após algumas semanas de uso ela começa a ficar muito lenta e ocorre um OutOfMemoryError; a equipe de devs já aumentou o tamanho da Heap 3x mas não resolveu o problema de fato, apenas postergou seu acontecimento; eles não tem mais budget para investir numa máquina melhor nesse momento do projeto;
- culpado: o problema é que existe um cache mal implementado usando
ConcurrentHashMap
num objeto singleton do Spring criado por nós em vez de uma lib de cache como Guava ou Spring Cache com politica de invalidação; - solução: estressar a aplicação até ver um alto uso de Heap (old) com objetos que nunca são removidos da memoria; em seguida gerar um Heap Dump e analisar quais objetos estão consumindo maior parte da memoria, para então encontrar qual a classe responsável pelo vazamento; por fim, substituir a
ConcurrentHashMap
por uma lib que permite politicas de invalidação;
- 2.7. gravar video: solução do especialista para atividade
-
Cuidados ao containerizar aplicações Java
- 3.1. gravar video: containerizando sua aplicação Java com Docker
- 3.2. gravar video: monitorando aplicações rodando em containers
- 3.3. gravar video: conhecendo os diferentes tipos de Garbage Collectors (GC)
- 3.4. gravar video: ajustando memoria e CPU no seu container
- 3.5. criar formulário auto-percepção: criar formulário que exercite a teoria vista nos vídeos acima;
- 3.6. criar formulário caminho cognitivo: criar formulário que exercite a teoria vista nos vídeos acima;
- 3.7. criar atividade: troubleshooting para baixo throughput da aplicação
- cenário: aplicação funciona muito bem numa máquina dedicada ou localmente, mas ela não escala adequadamente dentro de um container quando o throughput aumenta (PS: definir o throughput aqui): o uso de CPU aumenta e o tempo de resposta cai demais; no fim a equipe de devs não entende o motivo e está escalando a aplicação horizontalmente para resolver o problema, o que tem aumentado os custos nas nuvens;
- culpado: o container está usando somente 1 CPU (core) e a Heap está setada incorretamente, o que força a JVM a usar Serial GC além de aumentar a frequencia de coleta de lixo (pouca memoria), que por sua vez impacta no processamento das requisições quando o throughput aumenta;
- solução: estressar aplicação localmente para ver ela funcionando e ver seu throughput (o esperado); habilitar monitoramento remoto JMX (app e container) e em seguida estressar a aplicação num container Docker para vê-la engargalar; analisar a CPU via comando
top/htop
, e também perceber que a GC está executando a coleta de lixo várias vezes e congelando a aplicação; por fim, ajustar os parâmetros do container para usar 2 ou mais cores de CPU de tal forma que a JVM consiga selecionar outro tipo de GC;
- 3.8. gravar video: solução do especialista para atividade
-
-
Save rafaelpontezup/613669843a22a5105bf736233e2eb4be to your computer and use it in GitHub Desktop.
Treinamento Troubleshooting: cronograma e atividades
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment