Artículo técnico

Este artículo ha sido actualizado para incluir el software GC Portal para Linux y Java Desktop System (JDS), disponible tanto para los servidores Sun Java System Application Server 7 (antes Sun ONE Application Server 7 (S1AS7)) como para Tomcat. Originalmente, sólo estaba disponible para Solaris y Windows. Esta versión del software GC Portal también incluye VisualGC integrado en el GC Portal.

El GC Portal permite analizar y ajustar el rendimiento de las aplicaciones Java desde la perspectiva de la recolección de basura (GC) mediante la minería de los verbose:gc registros generados por la JVM. El Portal GC es una página única para cuestiones de GC e incluye una amplia colección de libros blancos, estudios de casos y otros materiales. El Portal está pensado para ser utilizado con la JVM HotSpot de Sun Microsystems, distribuida como parte de Java 2, Standard Edition (J2SE). El uso del Portal GC permite a los desarrolladores modelar los comportamientos de la aplicación y de la JVM desde la perspectiva de la GC. Este artículo presenta el diseño y las características del Portal GC, para permitir a los desarrolladores utilizarlo como una herramienta para analizar y afinar la GC.

El Portal GC requiere el uso de los siguientes interruptores por parte de la JVM para la generación de verbose:gc registros que son procesados por el Portal para su análisis.

 -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 

No se requiere el uso de otros switches de la JVM para la generación de los logs apropiados para el Portal GC, pero pueden añadirse según se considere apropiado para afinar y dimensionar la JVM y la aplicación. Nota: -XX interruptores no son estándar y también están sujetos a cambios sin previo aviso en futuras versiones de JVM.

Modelado de aplicaciones y ajuste del rendimiento desde una perspectiva de GC

El modelado de aplicaciones Java hace posible que los desarrolladores eliminen la imprevisibilidad atribuida a la frecuencia y duración de las pausas para la recolección de basura. Estas pausas están directamente relacionadas con:

• Número y tamaño total de los objetos creados y vivos
• Vida media de estos objetos
• Tamaño del heap de la JVM

A partir del análisis proporcionado por el Portal GC para un conjunto específico de verbose:gc archivos de registro alimentados al Portal, los desarrolladores pueden construir un modelo que les ayude a comprender mejor el comportamiento de la aplicación y la JVM.

Los registros verbose:gc contienen información valiosa sobre:

• Tiempos de pausa de GC
• Frecuencia de GC
• Tiempos de ejecución de la aplicación
• Tamaño de los objetos creados y destruidos
• Tasa de creación de objetos
• Memoria reciclada en cada GC

El comportamiento de la aplicación puede ser graficado y analizado para determinar las diferentes relaciones entre duración de las pausas, la frecuencia de las pausas, la tasa de creación de objetos y la memoria liberada. El análisis de esta información puede permitir a los desarrolladores ajustar el rendimiento de una aplicación, optimizando la frecuencia de la GC y los tiempos de recolección especificando los mejores tamaños de la pila, otras opciones de la JVM y algoritmos alternativos de GC para una situación determinada.

Información derivada de los registros verbose:gc para analizar y modelar el comportamiento de la GC

Este tipo de información puede utilizarse para ajustar el rendimiento del proceso de recolección de basura.

Promedio de pausas de GC en la generación joven y vieja

El tiempo promedio que la aplicación se suspende mientras se realiza la recolección de basura en la JVM.

Frecuencia promedio de GC en la generación joven y vieja

La periodicidad con la que se ejecuta el recolector de basura en la generación joven y vieja. Se puede obtener ya que se registra la instancia de tiempo de cada actividad de GC.

Sobrecarga secuencial de GC

El porcentaje de tiempo del sistema durante el cual la aplicación se suspende para que se realice la recolección de basura. Calculado como Avg. GC pausa * Avg. GC * 100%

Sobrecarga concurrente de la GC

El porcentaje de tiempo del sistema durante el cual la recolección de basura ocurre concurrentemente con la aplicación. Calculado como Tiempo medio de GC concurrente (fase de barrido) * Frecuencia media de GC concurrente / nº de CPUs

Memoria reciclada por cada GC en la generación joven y en la antigua

El total de basura recogida durante cada GC.

Tasa de asignación

La tasa a la que los datos son asignados por la aplicación en la generación joven. Si la ocupación del montón de la generación joven al inicio de la generación actual = x, la ocupación al final de la generación anterior = y y la frecuencia de la GC es de 1 por segundo, la tasa de asignación es aproximadamente de x a y por segundo.

Tasa de promoción

La tasa de promoción de los datos a la generación antigua.

Datos totales asignados por la aplicación

Es el total de datos asignados por la aplicación por transacción.

Los datos totales pueden dividirse en datos de corta duración y datos de larga duración

Los datos de larga duración son los que sobreviven a los ciclos de GC de la generación joven y se promueven a la generación vieja.

Datos de corta duración

Los datos de corta duración que mueren muy rápidamente y se recogen en la generación joven. Esto se puede calcular como Datos totales – Datos de larga duración.

Datos activos totales

Este es el total de datos vivos en cualquier instancia de tiempo. Esto es crítico para construir un modelo para dimensionar el montón de la JVM. Por ejemplo, para una carga de 100 transacciones por segundo, con datos a largo plazo de 50K por transacción que duran un mínimo de 40 segundos, la huella de memoria mínima de la vieja generación tendría que ser

50K*40s*100 = 200M

Fugas de memoria

Estas pueden ser detectadas y los errores de «fuera de memoria» pueden ser mejor entendidos mediante el monitoreo de la basura recolectada en cada barrido como se muestra en estos registros.

Flags y conmutadores para generar registros de GC

Hay mucha información útil relacionada con la GC que la JVM puede registrar en un archivo. Esta información es utilizada por el Portal GC para ajustar y dimensionar las aplicaciones y la JVM desde la perspectiva de la GC. Los registros que contienen información detallada de la GC se generan cuando se ejecuta una aplicación Java con los siguientes switches:

– verbose:gc Esta bandera activa el registro de la información de la GC. Disponible en todas las JVMs.

-XX:+PrintGCTimeStamps Imprime los tiempos en los que ocurren las GCs en relación al inicio de la aplicación. Disponible sólo a partir de J2SE1.4.0.

-XX:+PrintGCDetails Da detalles sobre las GCs, como:

• Tamaño de la generación joven y vieja antes y después de las GCs
• Tamaño del heap total
• Tiempo que tarda una GC en suceder en la generación joven y vieja
• Tamaño de los objetos promovidos en cada GC

Disponible sólo desde JVM1.4.0.

Uso del Portal GC para el modelado de aplicaciones y el ajuste del rendimiento

El Portal GC puede utilizarse para comprender mejor el comportamiento de la GC de una aplicación y así ajustar el rendimiento y el tamaño de las aplicaciones para que se ejecuten de forma óptima en condiciones de escasez, pico y ráfaga. Soporta J2SE1.2.2, J2SE1.3, J2SE1.4 y J2SE1.4.1 en adelante, incluyendo las dos nuevas implementaciones de recolección de basura, el Parallel Collector y el Concurrent Collector. Permite a los desarrolladores enviar archivos de registro de GC y analizar el comportamiento de la aplicación, basándose en estos archivos de registro. También considera alguna información específica de la aplicación y del entorno, incluyendo:

• Tasa de transacciones o carga del servidor

  Esto se aplica a las típicas aplicaciones del lado del servidor que operan en una configuración Cliente-Servidor. Para tales aplicaciones, esta es la tasa a la que el cliente podría estar generando una carga estable para que el servidor procese y es útil para un análisis de estado estable del servidor. El análisis de estado estacionario puede incluir varios escenarios como el peor de los casos, la situación de pico o de ráfaga o una situación media. Esta información no es obligatoria. Si no está disponible o no es aplicable, puede ignorarse. En este caso, también debería ignorarse parte de la información presentada por el Portal, que incluye:

  • Rendimiento teórico
  • Datos a corto plazo
  • Datos a largo plazo

• Número de procesadores en la máquina de destino

  Esta información es utilizada para realizar ciertos cálculos por el Portal, como la sobrecarga de GC concurrente.

• Versión de JVM utilizada por la aplicación (1.2.2_xx, 1.3.x, 1.4.0, 1.4.1)

  Como el formato de registro verbose:gc no es estándar, y ha habido cambios de la JVM, esta información es necesaria para el Portal GC.

Diseño del Portal GC

El Portal GC está compuesto por cuatro motores:

• Motor de análisis e informes
• Motor gráfico
• Motor de inteligencia
• Motor de sesión y almacenamiento
• VisualGC

Motor de análisis e informes

• Carga verbose:gcficheros de registro, los mina e informa:
  • Pausas del CG en la generación joven y en la vieja
  • Frecuencia del CG en la generación joven y en la vieja
  • Tasa de asignación de objetos
  • Tasa de promoción de objetos de la generación joven a la vieja
  • Tiempo total de GC
  • Tiempo total de aplicación
  • Tamaño inicial y final del montón de las generaciones joven y vieja
  • GC secuencial overhead
  • GC concurrente overhead
• Calcula y presenta información relacionada con la aplicación
  • Datos a corto plazo por transacción
  • Datos a largo plazo por transacción
  • El rendimiento máximo teórico
  • Eficiencia de la CPU

  Esta información puede ser ignorada para aplicaciones que no están basadas en transacciones, pero es relevante para las aplicaciones del lado del cliente o aquellas que puedan mostrar un comportamiento extremadamente escalonado.

• Presenta el comportamiento detallado de la GC de la aplicación y de la JVM a lo largo del tiempo
  • El usuario puede ver los datos de la GC, muestreados a intervalos de tiempo elegidos para toda la ejecución.

  Esta información detallada de la GC muestreada a intervalos elegidos para toda la ejecución es extremadamente útil cuando las aplicaciones exhiben un comportamiento variado a lo largo del tiempo, como las aplicaciones por fases, cíclicas o reactivas al azar, y la información promedio del resumen podría estar sesgada como resultado. Esta información detallada y muestreada puede utilizarse para ver el comportamiento de la aplicación y la JVM a medida que cambia con el tiempo.

• Información detallada del reciclaje de la memoria a lo largo del tiempo en las generaciones jóvenes y viejas
  • Memoria antes de la GC
  • Memoria después de la GC
  • Memoria liberada en cada GC
• Información del envejecimiento de los objetos en la generación joven
  • Disponible si se utiliza el interruptor -XX:+PrintTenuringDistribution para generar registros.

La figura 1 es una instantánea de un ejemplo de informe presentado por el motor de análisis del Portal GC.

Figura 1. Instantánea del motor de análisis del Portal GC

Motor gráfico

La mayor parte de la información que es presentada por el motor de análisis en forma tabular puede ser trazada gráficamente. Se pueden trazar múltiples tablas en el mismo gráfico para ayudar a las comparaciones.

• Presentación gráfica del análisis detallado de la GC de la línea de tiempo
• Presentación gráfica de la información de reciclaje de memoria en cada GC
• Comparación gráfica de la información de la GC de varios archivos de registro
• Presentación gráfica de la información de tenencia de la edad de los objetos para cada «edad»

Figura 2. Instantánea del Motor Gráfico del Portal GC

Motor de Inteligencia

El Motor de Inteligencia se compone de:

• Recomendaciones Generales

  Esta sección proporciona documentos que cubren información general y recomendaciones sobre el ajuste del rendimiento del GC. El Portal no proporciona recomendaciones dinámicas ni de ajuste automático. Las recomendaciones incluyen información general sobre cómo:

  • Reducir la pausa y la frecuencia de la GC
  • Reducir la sobrecarga secuencial de la GC
  • Dimensionar los heaps de generación joven y vieja para manejar una carga determinada
  • Detectar las fugas de memoria
  • Elegir colectores
  • Elegir diferentes opciones e interruptores de la JVM.
• Modelado empírico

  Registrar las ejecuciones de la aplicación en base a los datos analizados de múltiples verbose:gcregistros. El usuario puede elegir los archivos (entre todos los que se cargaron) para el modelado en base a las siguientes opciones:

  • Tasa de transacciones
  • Número de procesadores
  • Tamaño de la generación joven
  • Tamaño de la generación vieja
  • Versión del JDK

  Tamaño de las pilas

El usuario puede clasificar el entorno JVM óptimo en base a los siguientes criterios:

• Pausas de la JVM
• Carga secuencial de la JVM
• Frecuencia de la JVM
• Eficiencia de la CPU

El usuario también puede ver la comparación gráfica de las distintas ejecuciones.

Figura 3. Instantánea del motor de Inteligencia del Portal GC

Motor de sesión y almacenamiento

• Gestionar las sesiones de los usuarios
• Gestionar y almacenar los perfiles de los usuarios
• Gestionar y almacenar los datos/registros de los usuarios de forma segura
• Hacer que los registros de los usuarios/datos estén disponibles para la visualización de referencias, y el modelado empírico

Figura 4. Instantánea del motor de almacenamiento del Portal GC

VisualGC

La herramienta visualgc se acopla a una JVM HotSpot instrumentada y recoge y muestra gráficamente los datos de rendimiento de la recolección de basura, del cargador de clases y del compilador HotSpot. Se incorpora al Portal GC para recopilar información relacionada con la GC en tiempo de ejecución de la JVM. GC Portal utiliza la herramienta webstart para ejecutar y mostrar la información visualGC en un navegador. Más detalles sobre esta herramienta están disponibles en la página CoolStuff – jvmstat. El archivo ReadMe para ejecutar VisualGC desde el Portal GC está integrado en el software del Portal GC.

Agradecimientos:

El autor desea agradecer a Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham y S.R.Venkatramanan su contribución al Portal GC. El autor también desea agradecer a los arquitectos y expertos en recolección de basura de la JVM de Sun, John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree e Y.S. Ramakrishna, su ayuda y orientación en este trabajo. El autor también desea agradecer a los miembros del equipo de rendimiento de JVM de Sun, Timothy Cramer y Brian Doherty (autor de las herramientas VisualGC y jvmstat) su ayuda para integrar VisualGC en GC Portal.

Acerca del autor:

Alka Gupta es miembro del personal técnico de Sun Microsystems. Es responsable de trabajar con los ISV y socios de Sun para ayudarles a adoptar las tecnologías y plataformas emergentes de Sun de forma rápida y eficiente. Lleva casi 7 años trabajando en el área de ajuste de rendimiento en plataformas Sun y casi 10 años en esta industria. Alka se graduó en el Instituto Indio de Tecnología (IIT), India.