Depois de substituir o sistema operacional do computador em funcionamento pelo Win7, meu myeclipse foi insatisfatório na inicialização e na velocidade de execução. Especialmente ao modificar e depurar vários modelos de página ao mesmo tempo, a alternância entre dois arquivos sempre ficará presa por cerca de dez segundos. Tentar desligar vários plugins e verificá -los não ajudará. Então, depois de estudar aproximadamente a JVM, decidi tentar resolver esse problema da perspectiva da JVM.
Inicie a otimização:
Primeiro, vamos dar uma olhada nos parâmetros de inicialização padrão em myeclipse.ini:
-Xmx512m: defina o valor máximo de memória da heap como 512m
-Xx: maxpermsize = 256m: defina o valor máximo da geração persistente como 256m
-Xx: ReservaservedCodecachesize = 64m: Defina o tamanho da memória ocupado pelo código como 64m
Nada pode ser visto nos parâmetros de inicialização; portanto, adicione os parâmetros relevantes para imprimir alterações na memória:
-Xx:+printgctimestamps: imprima o registro de data e hora de cada gc
-Xx:+printgcdetails: imprimir informações detalhadas para cada gc
-Xloggc: myeclipsegc.log: saída GC Records para arquivo
-verbose: gc: emitir a situação relevante de cada gc
Em seguida, comece o myeclipse e verifique as informações em myeclipsegc.log:
A startup leva cerca de 30 segundos. Interceptar seletivamente uma pequena parte dos logs. Você pode ver que, nos primeiros 10 segundos da startup do Myeclipse, a JVM executou mais de 300 GCs e 9 GCs completos.
A partir da frequência e informação do GC, pode -se observar que a taxa de recuperação de memória é muito alta e o tamanho está se ajustando constantemente. Isso deve ser devido ao espaço insuficiente na geração mais jovem, e é necessário um valor inicial considerável.
Em seguida, concentre -se no GC completo:
Copy the code as follows: 5.961: [Full GC 5.961: [Tenured: 34568K->34456K(49676K), 0.1397651 secs] 35336K->34456K(53452K), [Perm: 26623K->26458K(26624K)], 0.1398562 secs] [Vezes: usuário = 0,14 sys = 0,00, real = 0,14 segundos]
9.030: [GC completo 9.030: [Tenado: 53310K-> 52332K (64588k), 0,2034757 s] 56020k-> 52332k (69516k), [Perm: 43007k-> 42996k (43008k), [Perm: 43007k-> 42996k (43008k), sys = 0,00, real = 0,20 segundos]
A partir da comparação dos dois troncos, podemos ver que o GC completo está reciclando principalmente as duas áreas de tocar e perm, e os tamanhos dessas duas áreas estão sendo constantemente ajustados, então decidimos consertar seu tamanho primeiro.
Portanto, os parâmetros ajustados são os seguintes:
-Xms512m: defina o valor mínimo da pilha como 512m
-Xmn192m: Defina o tamanho da geração mais jovem para 192m
-Xx: PermSize = 192m: Defina o valor inicial da geração persistente como 192m
-Xx: maxpermsize = 192m
-Xx: reservascodecachesize = 64m
-Xx:+printgctimestamps
-Xx:+printgcdetails
-Xloggc: myeclipsegc.log
-verbose: gc
Reinicie o Myeclipse uma vez para visualizar as informações do log:
A startup levou cerca de 12 segundos. A partir do tronco, pode -se observar que apenas 5 GCs foram realizados nos primeiros 10 segundos e nenhum ajuste no tamanho de cada área foi envolvido. Esse resultado é aceitável porque não requer reinicializações frequentes durante o trabalho.
Otimização da velocidade de resposta do trabalho:
Em seguida, estudei atrasos frequentes e grandes problemas de cartão ao alterar os arquivos HTML para frente e para trás que me incomodaram por um longo tempo. Para estudar mais intuitivamente as mudanças de memória da JVM, decidi usar o JCONSOLE, uma ferramenta auxiliar que vem com Java. Primeiro restaure os parâmetros do myeclipse.ini para evitar interferências desde o primeiro estágio de otimização.
Comece o Myeclipse, comece a JConsole e conecte -se à JVM onde o Myeclipse está localizado. O diagrama de memória de toda a pilha após o estábulo é o seguinte:
Em seguida, tente abrir alguns modelos e depois observar as mudanças de memória.
Primeiro de tudo, o uso geral da memória da heap:
Pode -se observar que, após a abertura de vários modelos, o uso da memória da heap aumentou repentinamente do original abaixo de 100m para mais de 300m. O uso triplicou, mas ainda está dentro da faixa de 512m que eu defini. Portanto, você não pode considerar temporariamente continuar aumentando a memória da heap, mas, em vez disso, considere ajustar a razão do tamanho da memória de cada zona.
Por isso, observamos o uso da memória de cada zona durante esse período, entre os quais a zona do Éden é a seguinte:
A taxa de uso de memória da área do Éden aumentou significativamente durante esse período e o GC ocorreu várias vezes. Através das informações de monitoramento abaixo, podemos saber que, por padrão, a área do Éden aloca apenas 31m de memória máxima, o que obviamente não é suficiente. A execução de um pequeno ponto acionará o GC na área do Éden. Essa deve ser uma das razões para atrasar o atraso no interruptor de abertura do modelo e precisa ser ajustado.
Em seguida é a área titular:
O espaço máximo alocado pela JVM para esta área por padrão é de 470m. À medida que o uso da memória muda, o tamanho real dessa área está sendo constantemente ajustado. O GC completo ocorrerá sempre que o tamanho da área é ajustado, o que deve ser uma das razões para grandes blocos frequentes. A abertura do novo modelo é o principal motivo para desencadear esse ajuste. Do ponto de vista do uso da memória nessa área, ainda é necessário manter uma certa quantidade de redundância mantendo e corrigindo o espaço de memória nessa área em torno de 450m.
Desse ponto de vista, ainda é necessário expandir a memória da JVM para manter uma área de titular maior e uma área de Éden.
Por fim, vamos dar uma olhada na área de perm:
Como parte da área do método, as mudanças de memória nessa área não são grandes e relativamente estáveis; portanto, não há necessidade de deixar muita redundância. No entanto, considerando que o volume real do código do projeto atualmente aberto não é grande, é decidido mantê -lo temporariamente em cerca de 128m e ajustá -lo lentamente no futuro.
Portanto, de acordo com a análise acima, os parâmetros são ajustados para:
-Xmx768m
-Xms768m
-Xmn256m
-Xx: PermSize = 192m
-Xx: maxpermsize = 192m
-Xx: reservascodecachesize = 64m
Reinicie o Myeclipse, conecte -se ao JCONSOLE e abra trinta modelos ao mesmo tempo para fazer o teste. Ao olhar para a taxa de uso de memória de cada zona, encontrei um problema. Após ajustar a geração jovem para 256m, uma vez que o Eden não ocorre mais frequentemente no GC, a quantidade de dados que entra na área titular é significativamente reduzida. O diagrama de uso de memória da área titular é a seguinte:
Como mostrado na figura acima, quando muitos modelos são abertos deliberadamente, o espaço de 450m+ usa apenas menos de 250m e a taxa de utilização de espaço é muito baixa, portanto, os ajustes precisam ser feitos.
Resumir
O exposto acima são algumas idéias e processo de ajuste real para eu sintonizar meu myeclipse. Em uso real, fiz alguns ajustes e personalizações de acordo com minhas preferências. Os parâmetros finais do myeclipse.ini são os seguintes:
-vmargs
-Xmx512m
-Xms512m
-Xmn192m
-Xx: PermSize = 128m
-Xx: maxpermsize = 128m
-Xx: reservascodecachesize = 64m
Sob essa configuração de parâmetros, a velocidade de resposta do myeclipse é relativamente garantida e a frequência de vários atrasos de atraso é bastante reduzida. A desvantagem é que a memória do sistema ocupada pelo residente permanente é relativamente alta. Os alunos que gostam de abrir o myeclipse múltiplo ao mesmo tempo podem fazer ajustes apropriados de acordo com suas necessidades e condições reais.
O exposto acima é tudo sobre este artigo, espero que seja útil para o aprendizado de todos.