Diretório de artigos
1. Alta falha no teste de estresse simultâneo
Sempre antes de uma grande venda, precisamos realizar um teste de estresse no serviço. Durante o teste de estresse, um alarme de luz vermelha disparou repentinamente e o volume do pedido foi reduzido diretamente pela metade, o que foi uma falha muito grave no teste de estresse. Primeiro, vamos dar uma olhada em como o teste de estresse é realizado:
① A distribuição normal do tráfego online deve ser que as salas de computadores A e B suportem cada uma metade do tráfego online.
② Antes do teste de estresse, precisamos encaminhar todo o tráfego para uma sala de informática, ou seja, deixar a sala de informática B suportar todo o tráfego online.
③ Depois que a sala de informática A for desocupada, fluiremos o tráfego de teste de pressão para a sala de informática A e realizaremos as operações de teste de pressão uniformemente na sala de informática A, para que o tráfego online não seja afetado.
Na verdade, o nó onde ocorreu este acidente não foi durante o teste de estresse, mas após a conclusão do teste de estresse, quando redirecionamos o tráfego da sala de informática A original para a sala de informática A, houve um aviso de que o volume de pedidos foi diminuindo mês a mês.
A primeira reação neste momento foi restaurar rapidamente ao estado anterior sem problemas. Depois de mudar para o grupo anterior, descobri que o alarme desapareceu. Há uma questão aqui: por que não houve alarme durante o teste de estresse, mas ocorreu um alarme quando o tráfego foi revertido?
O feedback do lado do pedido disse que todas as solicitações de tráfego enviadas para a sala de informática A têm uma marca de teste de estresse e os pedidos com uma marca de teste de estresse serão descartados. Para distinguir entre tráfego de teste de estresse e tráfego on-line, na verdade, um ThreadLocal é usado no código subjacente para definir um identificador de teste de estresse. No entanto, devido ao nosso erro,Durante o teste de estresse, apenas o sinalizador de teste de estresse é definido, mas não há remoção, portanto, o sinalizador de teste de estresse nunca desaparecerá.Mesmo se o tráfego do teste de estresse for retirado, o pool de threads ainda estará em um estado com o sinalizador de teste de estresse , o que faz com que, devido à poluição do pool de threads, quando novo tráfego for enviado novamente, ele será considerado como tráfego de teste de estresse, fazendo com que todas as solicitações de pedidos recebidas sejam descartadas.Então, depois de definido, certifique-se de remover.
2. Ajuste JVM
Ainda quero adicionar o processo de ajuste quando o OOM ocorre na memória heap e na memória fora do heap.
1. Ajuste de memória heap
① Primeiro, retire a máquina problemática do ambiente de balanceamento de carga;
② Em seguida, use o comando jps para encontrar o número do processo GC;
③ Use o comando jmap -dump para despejar seu instantâneo de heap;
④ Em seguida, use o comando TCP copy para copiar um sai uma cópia, uma para o ambiente de produção e outra para o ambiente de teste. Analisamos os parâmetros e modificamos o código de negócios no ambiente de teste.
2. Ajuste de memória fora do heap
A memória off-heap aqui se refere à área do método. Todos nós sabemos que as informações da classe são armazenadas na área do método. A área do método continua a aumentar, indicando que o código está constantemente gerando classes, resultando em GC importantes e frequentes.
① detalhado: a classe pode imprimir todas as informações de carregamento da classe;
② Encontre a classe carregada com frequência e conduza uma pesquisa global na ideia;
③ Descobrimos que cada solicitação irá compilar e gerar classes, fazendo com que a área do método se expanda continuamente;
④ O motivo is Nenhum cache foi feito. Após a modificação do cache, o problema foi resolvido.