La arquitectura de la JVM (Java™ Virtual Machine) HotSpot desarrollada por Sun e implementada por HP ha evolucionado de forma distinta al kit de desarrollo de software (SDK) de IBM. Su estructura interna, para una generación nueva o antigua y regiones permanentes, surge para principalmente dar soporte a la recogida de basura generacional, así como otras modalidades de recogida de basura que sean necesarias.
Antes de empezar
Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la
información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde
el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL
para resolver problemas de aplicaciones para obtener más información sobre la utilización de
HPEL.
- Determine el tipo de JVM en la que se ejecuta el servidor de aplicaciones.
Emita el mandato
java –fullversion desde el directorio raíz_servidor_aplicaciones/java/bin del servidor de aplicaciones. En respuesta a este mandato, el servidor de aplicaciones graba información sobre la JVM, incluida la información sobre el proveedor de JVM, en el archivo SystemOut.log.
Si el servidor de aplicaciones está en ejecución en una máquina virtual de IBM para Java, consulte el tema Ajuste de la máquina virtual de IBM para Java.
- Verifique que las siguientes sentencias son verdaderas para el sistema:
- Está instalada en el sistema la versión más reciente de JVM soportada.
- Está instalada en el sistema la actualización del servicio más reciente soportada. Prácticamente, cada
nuevo nivel de servicio incluye mejoras de rendimiento de JVM.
Acerca de esta tarea
El ajuste de la JVM HotSpot de SUN es un proceso interactivo donde se desarrolla la configuración de JVM, se recopilan datos, principalmente de datos verbosegc y luego se analiza, y se aplican todas las revisiones de la configuración en el ciclo siguiente. Realice uno o más de los pasos siguientes si necesita ajustar la JVM HotSpot de SUN.
Procedimiento
- Proporcione suficiente memoria de almacenamiento dinámico de Java.
La memoria de almacenamiento dinámico de Java es un conjunto de direcciones contiguas reservadas. El tamaño de la memoria de almacenamiento dinámico de Java es el tamaño máximo para el que se configura el almacenamiento dinámico de
Java.
Estas direcciones no están disponibles para otras demandas de memoria del sistema o nativas, y las mantiene y gestiona sólo la JVM porque el almacenamiento dinámico de Java se utiliza para el almacenamiento de objetos Java mientras exista dicha JVM.
Cuando la JVM se inicializa, asegura que se obtengan recursos para el almacenamiento dinámico de Java de acuerdo con los valores de configuración de la JVM. Si no hay suficiente memoria disponible, la inicialización de JVM falla. Si se configura una memoria no adecuada en el almacenamiento dinámico de Java, con el tiempo el sistema fallará con un informe OutOfMemory, que normalmente va precedido de mucha actividad de recogida de basura durante la que no se produce casi ningún proceso Java.
Se debe realizar un estudio sobre las necesidades de memoria nativa de otros componentes del proceso para dar cabida a las hebras en ejecución, el almacenamiento de datos para la entrada/salida y satisfacer requisitos como la alineación y el tamaño de página.
El almacenamiento dinámico de Java HotSpot de Sun consta de dos partes físicamente independientes que debe tener en cuenta cuando se especifican tamaños máximos de almacenamiento dinámico de Java:
- La región permanente, que es una combinación de regiones de generación viejas y jóvenes que a su vez se subdividen en regiones ocupadas, espacios supervivientes y edén.
- La memoria de suministro para los componentes Java de este sistema.
Los parámetros -XX:MaxPermSize= y -Xmx (tamaño máximo de almacenamiento dinámico de Java), respectivamente, configuran el tamaño máximo de la región permanente, donde el código de clase y los datos relacionados se presentan de forma lógica como parte de la región de generación antigua, pero se mantienen separados físicamente, y el tamaño máximo del almacenamiento dinámico principal donde se almacenan los objetos Java y sus datos en las regiones de generación antigua y nueva. La región permanente junto con el almacenamiento dinámico principal forman el almacenamiento dinámico de Java total.
Un error en la asignación en cualquiera de estas regiones representa la incapacidad de dar cabida a todo el código de aplicación o todos los datos de aplicación, siendo las dos condiciones extremas que pueden agotar el almacenamiento disponible y causar un error OutOfMemory.
Consulte estos parámetros de ajuste:
- -XX:MaxPermSize (región permanente)
- -Xmx (tamaño máximo del almacenamiento dinámico de Java)
- Inhabilite la recogida de basura explícita para elimina todos los ciclos de recogida de basura importantes que no sean necesarios e inoportunos que pueden haberse introducido en componentes de software del sistema.
Consulte el parámetro de ajuste
-XX:+DisableExplicitGC.
Avoid trouble: De forma predeterminada, la JVM descarga una clase de la memoria cuando no
hay instancias activas disponibles de esa clase. Puede utilizar
-Xnoclassgc para inhabilitar la recogida de basura de clases. No obstante, el impacto sobre el rendimiento de la recogida de basura de clase es normalmente mínimo y la desactivación de la recogida de basura de clase en un sistema basado en Java Platform, Enterprise Edition (Java EE), con su uso intensivo de cargadores de clase de aplicaciones que pueden crear efectivamente una fuga de memoria de datos de clase y causar que la JVM genere una excepción de falta de memoria.
Si utiliza el argumento -Xnoclassgc, cuando tenga que volver a desplegar una aplicación, siempre debe reiniciar el servidor de aplicaciones para borrar las clases y los datos estáticos de la versión anterior de la aplicación.
gotcha
Si utiliza el argumento -Xnoclassgc, cuando tenga que volver a desplegar una aplicación, siempre debe reiniciar el servidor de aplicaciones para borrar las clases y los datos estáticos de la versión anterior de la aplicación.
- Ajuste los tamaños de región para optimizar la acción de recogida de basura.
Cualquier decisión para intentar ajustar la recogida de basura se debe basar en el comportamiento de los recopiladores de basura. Debe identificar la modalidad de recogida de basura correcta que mejor convenga a las necesidades operacionales de la aplicación. También debe verificar que satisface los requisitos de rendimiento y que se reciclen de forma eficaz suficientes recursos de memoria para satisfacer regularmente las necesidades de la aplicación. Todos los cambios que realice en los valores del parámetro de recogida de basura deben producir resultados suficientemente distintos y mostrar las ventajas que se derivan de la explotación de regiones diferentes del almacenamiento dinámico de Java HotSpot.
Una elección imprudente normalmente prolonga el proceso ya que es necesario que el proceso de ajuste iterativo se repita sustancialmente. Las otras secciones presentan las dos opciones principales, rendimiento paralelo o baja pausa simultánea, y las opciones pertinentes para un ajuste adicional. Las dos modalidades ofrecen el potencial de alto rendimiento, pero el factor de rendimiento clave es que el comportamiento que se optimiza es distinto para cada modalidad.
La actividad de ajuste dominante se ocupa del control de la utilización de recursos para la actividad de asignación de servicios de la aplicación, así como organizar una recogida de basura eficiente para reciclar el almacenamiento, según sea necesario. Inevitablemente estos debates del ajuste dependen de la modalidad de recogida de basura empleada. Se tratan dos tipos de recogida de basura:
- El recopilador de rendimiento que lleva a cabo la recogida de copia de barrido paralelo en la generación nueva. Este tipo de recogida de basura es el tipo predeterminado en máquinas de clase de servidor de varios procesadores.
- Un recopilador de baja pausa simultánea.
El objetivo de ajustar estos recopiladores es ofrecer el comportamiento que más convenga a los patrones de asignación y duraciones de objetos del sistema de aplicaciones, y que maximice la eficacia de sus acciones de recopilación.
- Opción 1: Utilizar el recopilador de barrido de rendimiento/paralelo predeterminado con el ajuste incorporado habilitado.
A partir de la versión 5, la JVM HotSPot de Sun proporciona alguna detección del sistema operativo en el que se ejecuta el servidor, y la JVM intenta configurar una modalidad de recogida de basura generacional adecuada, es decir paralela o en serie, según haya o no varios procesadores y el tamaño de la memoria física.
Se supone que todo el hardware, en el que el producto se ejecuta en modalidad de preproducción y producción, satisface los requisitos de modo que se considere una máquina de clase de servidor. Sin embargo, es posible que algún hardware de desarrollo no satisfaga estos criterios.
El comportamiento del recopilador de basura de rendimiento, tanto si se ajusta automáticamente como si no, es el mismo y muestra algunas pausas significativas, que son proporcionales al tamaño del almacenamiento dinámico utilizado, en la ejecución del sistema de aplicaciones Java puesto que trata de maximizar la ventaja de la recogida de basura generacional. Sin embargo, estos algoritmos automáticos no pueden determinar si la carga de trabajo es apropiada para las acciones, o si el sistema requiere o le conviene más una estrategia de recogida de basura distinta.
Consulte estos parámetros de ajuste:
- -XX:+UseParallelGC
- -XX:+UseAdaptiveSizePolicy
- -XX:+AggressiveHeap
- Opción 2: Utilizar el recopilador de barrido de rendimiento/paralelo predeterminado, con el ajuste manual
Las desventajas de utilizar el algoritmo incorporado que se establece utilizando el parámetro
-XX:+UseAdaptiveSizePolicy, incluida la limitación que otros parámetros, como el parámetro
-XX:SurvivorRatio, puede configurarse para hacerlo conjuntamente con el algoritmo incorporado. Cuando se utiliza el algoritmo incorporado, se deja de tener una parte del control sobre la determinación de las asignaciones de recursos que se utilizan durante la ejecución.
Si el resultado de utilizar el algoritmo incorporado no es satisfactorio, es más fácil configurar manualmente los recursos de JVM que probar y ajustar las acciones del algoritmo. La configuración manual de recursos de JVM implica el uso de la mitad de las opciones que se utilizan para ajustar las acciones del algoritmo.
Consulte estos parámetros de ajuste:
- -XX:NewRatio=2 Es el valor predeterminado para un servidor que está configurado para la modalidad de VM
- -XX:MaxNewSize= y -XX:NewSize=
- -XX:SurvivorRatio=
- -XX:+PrintTenuringDistribution
- -XX:TargetSurvivorRatio=
- Opción 3: Utilizar el recopilador de marcado-barrido de baja pausa simultánea
Este recopilador es un punto de partida radical de la evolución de la recogida de basura que ha respaldado la arquitectura Hotspot, permitiendo que se solape el proceso de hebra de aplicación con una hebra de recogida de basura de fondo dedicada de prioridad baja. Si los datos de aplicación son incompatibles con el comportamiento del recopilador de rendimiento predeterminado, el recopilador de marcador barrido simultáneo (CMS) puede ser una estrategia viable, en concreto para los sistemas de aplicación que no toleran pausas invasivas. Este recopilador es especialmente útil con los almacenamientos dinámicos grandes que se utilizan con la JVM de 64 bits, o las aplicaciones que tienen un conjunto grande de datos de larga duración, a los que también se hace referencia como generación de larga permanencia, y que mantiene comparativamente una buena utilización de la memoria caché, conservando en gran parte páginas de generación joven, incluso cuando la hebra de fondo deba buscar por todas las páginas de todo el almacenamiento dinámico.
Para emplear el recopilador de marcado y barrido simultáneo como el agente de mantenimiento en principio, añada esta opción en lugar de cualquier otra modalidad de recogida de basura, a la configuración de JVM.
Consulte estos parámetros de ajuste:
- -XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=75
- -XX:SurvivorRatio=6
- -XX:MaxTenuringThreshold=8
- -XX:NewSize=128m
Entre las dificultades para realizar ajustes con CMS es que los peores tiempos de recogida de basura, que es cuando el ciclo CMS termina anormalmente, puede ser de varios segundos, que es especialmente costoso para un sistema que utiliza CMS para evitar largas pausas. Por consiguiente, los acuerdos de nivel de servicio pueden imponer el uso de CMS,
porque los tiempos de pausa promedio o medianos son muy bajos y el ajuste debe realizarse de forma
prudente para asegurarse de que los ciclos de CMS no terminen anormalmente. CMS sólo da resultado cuando su desencadenante anticipatorio asegura que el ciclo de CMS
siempre empieza los bastante temprano para asegurar que haya suficientes recursos libres disponibles antes de que se soliciten. Si el recopilador de CMS no puede terminar antes de que la generación veterana se llene, la recogida se completa haciendo una pausa en las hebras de aplicación, que se conoce como recogida completa.
Las colecciones completas son una señal de que es necesario realizar un ajuste adicional en el recopilador de CMS para que sea más apropiado para la aplicación.
Por último, a diferencia de otras modalidades de recogida de basura con una fase de compactación, el uso de CMS teóricamente aumenta el riesgo de que se produzca fragmentación con el HotSpot. Sin embargo, en la práctica raras veces supone un problema mientras la recogida recupera una proporción de la almacenamiento dinámico en buen estado. En los casos en que la CMS falla o termina anormalmente una recogida, se desencadena una recogida de basura compacta alternativa. Inevitablemente cualquier otro tipo de recogida de basura provoca una pausa invasiva significante en comparación con una recogida CMS normal.
Avoid trouble: Al igual que con el recopilador de rendimiento, existen bastantes más opciones disponibles para controlar de forma explícita CMS. Sin embargo, las mencionadas representan las opciones principales que es probable piense en utilizar cuando ajuste la JVM de HotSpot.
gotcha
Qué hacer a continuación
Recopile y analice los datos para evaluar la configuración, normalmente utilizando
verbosegc. Siga recopilando y analizando datos a medida que vaya ajustando cambios hasta que esté satisfecho con el rendimiento de la JVM.