Esta seção apresenta apenas a parte real de combate. Para parâmetros teóricos específicos, por favor, Baidu.
Ferramentas necessárias: Linux Server Jmeter Test Tool Xshell Um aplicativo da Web
Os parâmetros JVM do Tomcat podem ser configurados em catalina.sh e, se estiver na janela, você poderá configurar o arquivo .bat.
Configuração 1:
Aqui, configurei um caminho de log gc como /home/log/gc.log para imprimir o log do GC, a pilha inicial e a memória máxima de heap são definidas como 50m e, quando o arquivo de despejo de saída está transbordado, ele usa um coletor de lixo em série e o tamanho da geração permanente é de 50m.
Coloque o aplicativo da web no diretório correspondente, configure o server.xml (a configuração não é introduzida aqui) e inicie o TomCat.
O teste de taxa de transferência é realizado usando uma ferramenta de teste de pressão (JMeter). Os alunos que nunca o usaram podem baixar e aprender no site oficial http://jmeter.apache.org/
Crie um grupo de usuários (10 threads, cada thread solicita 1000 vezes), configure as informações da solicitação HTTP, gera um relatório agregado e um log GC
Vamos dar uma olhada no log do GC primeiro:
GC completo na tela, finalmente verifique o relatório agregado:
A taxa de transferência é mantida a 122,7 por segundo. A partir deste caso, podemos ver que a antiga geração está basicamente cheia e, após o FullGC, a nova geração terá um pouco de restante. Em geral, o tempo de pausa do GC completo é o mais longo e acontece com tanta frequência, obviamente, essa configuração é irracional.
Configuração 2:
Essa configuração aumenta principalmente a memória máxima da pilha. Para expandir automaticamente a máquina virtual e obter um tamanho estável da memória da heap.
Basta prestar atenção à memória máxima de 82924k é de cerca de 80m, o que significa que a máquina virtual expande automaticamente a memória da heap para 80m e a estabiliza. Este teste de configuração é apenas para encontrar uma memória de heap estável para o próximo teste.
Configuração três:
Defina a memória inicial da pilha em 128m.
A partir dos resultados da configuração 2, pode -se observar que a memória da heap está finalmente estável em cerca de 80m, portanto uma memória de heap menor que 80m provavelmente causará um grande número de reações GC, então aqui eu defino a memória da pilha para 128m, o que pode reduzir o número de GCs.
Você pode ver que a taxa de transferência aumentou um pouco, o número de GCs diminuiu significativamente e os intervalos de tempo dos GCs se tornaram mais longos.
Configuração 4:
Atualmente usando o Parallalgc Recycler, que é um reciclador paralelo multithread.
A taxa de transferência do reciclador de GC usando paralelo multithread foi ligeiramente aprimorada. (Parallalgc e SerialGC têm pouco efeito na taxa de transferência sem pressão do GC.)
Configuração 5:
Configuração 6:
De acordo com a conclusão da configuração 3, o GC ocorrerá frequentemente na memória de heap abaixo de 80m. Combinada com a conclusão obtida na configuração 4, quando há uma certa pressão de GC, a taxa de transferência de ParallelGC e SerialGC mostrará certas diferenças. Se a memória da pilha de 5 e 6 estiver configurada com 64m <80m, ocorrerá GC frequente. Ao usar diferentes recicladores do GC, teoricamente haverá uma grande diferença na taxa de transferência, mas por que a diferença no meu experimento não é muito grande e por quê? Ei, minha família é pobre. Eu uso uma CPU de núcleo único. No caso de um único núcleo, as alterações de desempenho do ParallelGC não são óbvias. O SerialGC é recomendado quando recursos de núcleo único ou paralelo são fracos. Os alunos que têm as condições podem experimentá-lo com um servidor multi-core!
Configuração 7:
Tente usar o PARNEWGC. A nova geração usa o Parnewgc para reciclar, enquanto a geração antiga ainda usa o SerialGC para reciclar. Veja como é o desempenho?
Tem melhor desempenho do que usar um desempenho em série, mas pior do que usar tudo para um reciclador paralelo.
Além disso, a atualização da versão JDK também pode melhorar um pouco o desempenho, mas a atualização da versão JDK vem com certos riscos, e alguns bugs desconhecidos podem ser introduzidos na nova versão do JDK.
Por fim, listei alguns parâmetros de configuração da JVM comumente usados para referência:
1. Parâmetros relacionados ao período de recuperação serial
• -xx:+useSerialGC: use colecionadores em série nas gerações novas e antigas
• -xx: SurvivorRatio: Defina o tamanho da área do Éden e a proporção da área do sobrevivente
• -xx: PretenuresizeTheshold: Defina o limite para objetos grandes para entrar diretamente na velhice. Quando o tamanho do objeto exceder esse valor, ele será alocado diretamente na velhice
• -xx: maxtenuringthreshold: define o valor máximo da idade do objeto que entra na velhice. Após cada GC menor, a idade do sujeito é adicionada por 1. Qualquer objeto maior que essa idade definitivamente entrará na velhice.
2. Parâmetros relacionados ao GC paralelo
• -xx:+useParnewgc: use colecionadores paralelos na nova geração.
• -xx:+useparalleloldgc: use colecionadores paralelos na velhice
• -xx:+parallelgcthreads: define o número de threads usados para coleta de lixo, que geralmente pode ser definido como igual ao número de CPUs. Quando há um grande número de CPUs, também é possível definir um valor relativamente pequeno.
• -xx:+maxgcpauseMillis: defina o tempo máximo de pausa de coleta de lixo. Seu valor é um número inteiro maior que 0. Quando o coletor funcionar, ele ajusta o tamanho da pilha Java ou alguns outros parâmetros e controlará o tempo de pausa para maxgcpauseMillis o máximo possível.
• -xx: +useadaptivesizepolicy: ligue a estratégia Adaptive GC. Nesse modo, parâmetros como o tamanho da nova geração e a proporção de Survivio, e a idade do objeto na geração antiga serão ajustados automaticamente para atingir o ponto de equilíbrio entre o tamanho, a taxa de transferência e a pausa.
• -xx:+gctimeratio: defina o tamanho da taxa de transferência. Seu valor é um certificado entre 0 e 100. Supondo que o valor do gctimeratio seja n, o sistema gastará não mais que 1/(1+n) de tempo na coleta de lixo.
3. Parâmetros relacionados ao coletor do CMS
• -xx:+useConcmarksweepGC: A nova geração usa colecionadores paralelos, enquanto a geração antiga usa colecionadores seriais CMS+.
• -xx: parallelcmsthreads: defina o número de threads para o CMS.
• -xx: cmsinitiationingCupancyFração: Defina quanto coletor CMS é acionado após o uso do espaço da velhice, padrão 68%
• -xx: usecmscompactatfullcollection: Defina se o CMS precisa desfragmentar uma vez depois de concluir a coleta de lixo
• -xx: cmSfullgcbeforeCompaction: Defina quantas vezes é executada a coleta de lixo CMS e a compactação de memória é realizada.
• -xx:+cmsclassunloadingEnabled: permite a recuperação de metadados da classe
• -xx: cmsinitiatingPermocpupancyFração: Quando a taxa de ocupação permanente atinge essa porcentagem, inicie a recuperação do CMS (desde que -xx:+cmsclassunloadingEnabledEnabled) é ativado)
• -xx: usecmsInitationingCupancuCancanly: significa que a recuperação do CMS é realizada apenas quando o limite é atingido.
• -xx:+cmsincremeMode: use o modo incremental, o que é mais adequado para a CPU único. O modo incremental é marcado como descartado no meio e será completamente removido no JDK9.
4. Parâmetros relacionados ao período de recuperação G1
• -xx:+useg1gc: use a recuperação G1
• -xx:+maxgcpauseMillis: defina o tempo máximo de coleta de lixo
• -xx:+gcpauseIntervalmillis: defina o intervalo de tempo de pausa.
5. TLAB relacionado
• -xx:+usetLab: ligue a alocação do TLAB.
• -xx:+printtlab: imprimir informações de alocação relacionadas ao TLAB
• -xx: tlabsize: defina o tamanho do TLAB
• -xx:+resizEtLab: ajuste automaticamente o tamanho do TLAB
6. Alguns outros parâmetros
• -xx:+desabillexplicitgc: desativar GC explícito
• -xx:+explicitgcinvokesconcurrent: use simultaneidade para lidar com o GC explícito
O desempenho da JVM TOMCAT acima é prático (recomendado) é todo o conteúdo que eu compartilho com você. Espero que você possa lhe dar uma referência e espero que você possa apoiar mais o wulin.com.