Después de reemplazar el sistema operativo de la computadora en funcionamiento con Win7, mi myeclipse ha sido insatisfactorio en la velocidad de inicio y ejecución. Especialmente al modificar y depurar múltiples plantillas de página al mismo tiempo, cambiar entre dos archivos siempre se atascará durante unos diez segundos. Intentar apagar varios complementos y verificarlos no ayudará. Entonces, después de estudiar aproximadamente el JVM, decidí tratar de resolver este problema desde la perspectiva del JVM.
Optimización de inicio:
Primero, echemos un vistazo a los parámetros de inicio predeterminados en myeclipse.ini:
-Xmx512m: establezca el valor máximo de memoria de montón en 512m
-Xx: maxPermsize = 256m: establezca el valor máximo de la generación persistente en 256m
-Xx: ReservedCodeCachesize = 64m: Establezca el tamaño de la memoria ocupado por el código a 64m
No se puede ver nada desde los parámetros de inicio, así que agregue los parámetros relevantes para imprimir cambios de memoria:
-Xx:+printgctimestamps: imprima la marca de tiempo de cada GC
-Xx:+printgcdetails: imprima información detallada para cada GC
-Xloggc: myeclipsegc.log: salida de registros GC para archivar
-verbose: GC: emitir la situación relevante de cada GC
Luego comience a MyEClipse y consulte la información en MyECLIPSEGC.LOG:
La startup tarda unos 30 segundos. Interceptar selectivamente una pequeña parte de los registros. Puedes ver que en los primeros 10 segundos de la startup de Myeclipse, el JVM ejecutó más de 300 GC y 9 GC completos.
A partir de la frecuencia e información de GC, se puede ver que la tasa de recuperación de la memoria es muy alta y el tamaño se ajusta constantemente. Esto debería deberse al espacio insuficiente en la generación más joven, y se necesita un valor inicial considerable.
Luego concéntrese en GC completo:
Copie el código de la siguiente manera: 5.961: [GC 5.961 completo: [TENIDO: 34568K-> 34456K (49676K), 0.1397651 SECS] 35336K-> 34456K (53452K), [Perm: 26623k-> 26458k (26624k)], 0.1398598598 [Times: usuario = 0.14 sys = 0.00, real = 0.14 segundos]
9.030: [GC completo 9.030: [Lifuado: 53310k-> 52332k (64588k), 0.2034757 secs] 56020k-> 52332k (69516k), [permanente: 43007k-> 42996k (43008k)], 0.2036030 secs] [usuarios = usuarios sys = 0.00, real = 0.20 segundos]
A partir de la comparación de los dos registros, podemos ver que GC completo recicla principalmente las dos áreas de titulares y permanentes, y los tamaños de estas dos áreas se ajustan constantemente, por lo que decidimos arreglar su tamaño primero.
Entonces los parámetros ajustados son los siguientes:
-Xms512m: establezca el valor mínimo de la pila en 512m
-Xmn192m: establezca el tamaño de la generación más joven a 192m
-Xx: permSize = 192m: Establezca el valor inicial de la generación persistente a 192m
-Xx: maxPermsize = 192m
-Xx: ReservedCodeCachesize = 64m
-Xx:+printgctimestamps
-Xx:+printgcdetails
-Xloggc: myeclipsegc.log
-verbose: GC
Reinicie MyEClipse una vez para ver la información del registro:
La startup tardó unos 12 segundos. Desde el registro, se puede ver que solo se realizaron 5 GC en los primeros 10 segundos, y no se involucraron ajustes al tamaño de cada área. Este resultado es aceptable porque no requiere reinicios frecuentes durante el trabajo.
Optimización de la velocidad de respuesta laboral:
A continuación, estudié los retrasos frecuentes y los problemas de la tarjeta grandes al cambiar los archivos HTML de un lado a otro que me habían preocupado durante mucho tiempo. Para estudiar más intuitivamente los cambios de memoria de JVM, decidí usar JConsole, una herramienta auxiliar que viene con Java. Primero restaure los parámetros de myeclipse.ini para evitar la interferencia desde la primera etapa de optimización.
Comience MyEClipse, comience JConsole y conéctese al JVM donde se encuentra MyEClipse. El diagrama de memoria de todo el montón después del establo es el siguiente:
A continuación, intente abrir algunas plantillas y luego observar los cambios de memoria.
En primer lugar, el uso general de la memoria del montón:
Se puede ver que después de abrir varias plantillas, el uso de la memoria del montón aumentó repentinamente de los menores de 100 m a más de 300 m. El uso se ha triplicado, pero todavía está dentro del rango de 512m que establecí. Por lo tanto, puede no considerar temporalmente continuar aumentando la memoria del montón, sino considerar ajustar la relación de tamaño de memoria de cada zona.
Por lo tanto, observamos el uso de la memoria de cada zona durante este período, entre los cuales la zona del Edén es la siguiente:
La tasa de uso de la memoria del área del Edén aumentó significativamente durante este período, y GC ocurrió varias veces. A través de la información de monitoreo a continuación, podemos saber que, por defecto, el área del Edén solo asigna 31 m de memoria máxima, que obviamente no es suficiente. La ejecución de un pequeño punto activará el GC en el área del Edén. Esta debería ser una de las razones del retraso de retraso en el interruptor de apertura de la plantilla y debe ajustarse.
El siguiente es el área titular:
El espacio máximo asignado por JVM a esta área de forma predeterminada es de 470 m. A medida que cambia el uso de la memoria, el tamaño real de esta área se ajusta constantemente. GC completo ocurrirá cada vez que se ajuste el tamaño del área, que debería ser una de las razones de los bloques grandes frecuentes. La apertura de la nueva plantilla es la razón principal para activar este ajuste. Desde la perspectiva del uso de la memoria en esta área, todavía es necesario mantener una cierta cantidad de redundancia manteniendo y fijando el espacio de memoria en esta área a alrededor de 450 m.
Desde este punto de vista, todavía es necesario expandir la memoria del montón de JVM para mantener un área y área de Edén más grandes.
Finalmente, echemos un vistazo a la zona permanente:
Como parte del área del método, los cambios de memoria en esta área no son grandes y relativamente estables, por lo que no es necesario dejar demasiada redundancia. Sin embargo, teniendo en cuenta que el volumen de código real del proyecto abierto actualmente no es grande, se decide mantenerlo temporalmente a alrededor de 128 m y ajustarlo lentamente en el futuro.
Entonces, según el análisis anterior, los parámetros se ajustan a:
-Xmx768m
-Xms768m
-Xmn256m
-Xx: permSize = 192m
-Xx: maxPermsize = 192m
-Xx: ReservedCodeCachesize = 64m
Reinicie MyEClipse, conéctese a JConsole y abra treinta plantillas al mismo tiempo para hacer la prueba. Al observar la tasa de uso de la memoria de cada zona, encontré un problema. Después de ajustar la generación joven a 256 m, ya que el Eden ya no ocurre con frecuencia en GC, la cantidad de datos que ingresan al área teniente se reduce significativamente. El diagrama de uso de la memoria del área titular es el siguiente:
Como se muestra en la figura anterior, cuando muchas plantillas se abren deliberadamente, el espacio de 450m+ solo usa menos de 250 m, y la tasa de utilización del espacio es demasiado baja, por lo que se deben realizar ajustes.
Resumir
Las anteriores son algunas ideas y un proceso de ajuste real para que yo sintonice mi myeclipse. En uso real, hice algunos ajustes y personalizaciones de acuerdo con mis preferencias. Los parámetros finales de myeclipse.ini son los siguientes:
-vmargs
-Xmx512m
-Xms512m
-Xmn192m
-Xx: permSize = 128m
-Xx: maxPermsize = 128m
-Xx: ReservedCodeCachesize = 64m
Bajo esta configuración de parámetros, la velocidad de respuesta de Myeclipse está relativamente garantizada, y la frecuencia de varios retrasos de retraso se reduce considerablemente. La desventaja es que la memoria del sistema ocupada por el residente permanente es relativamente alta. A los estudiantes a los que les gusta abrir múltiples myeclipse al mismo tiempo pueden hacer los ajustes apropiados de acuerdo con sus necesidades y condiciones reales.
Lo anterior se trata de este artículo, espero que sea útil para el aprendizaje de todos.