Ajuste de las máquinas virtuales Java

Debe tener en cuenta varios aspectos específicos sobre el ajuste de la máquina virtual Java (JVM) para conseguir el mejor rendimiento posible de WebSphere eXtreme Scale. En la mayoría de los casos, se requieren pocos valores de JVM especiales, o ninguno. Si se almacenan muchos objetos en la cuadrícula de datos, ajuste el tamaño del almacenamiento dinámico en un valor adecuado para evitar quedarse sin memoria.

Configurando eXtremeMemory, puede almacenar objetos en memoria nativa en lugar de hacerlo en el almacenamiento dinámico Java. La configuración de eXtremeMemory habilita eXtremeIO, un nuevo mecanismo de transporte. Si mueve los objetos fuera del almacenamiento dinámico de Java, evitará las pausas de recogida de basura, lo que hará que el rendimiento sea más constante y los tiempos de respuesta sean predecibles. Para obtener más información, consulte Configuración de IBM eXtremeMemory e IBM eXtremeIO.

Plataformas probadas

La prueba de rendimiento se ha producido principalmente en sistemas AIX (de 32 vías), Linux (cuatro vías) y Windows (ocho vías). Con sistemas AIX de gama alta, puede probar escenarios con un gran número de hebras para identificar los puntos de contención y corregirlos.

Recogida de basura

WebSphere eXtreme Scale crea objetos temporales asociados a cada transacción como, por ejemplo, una petición y una respuesta y una secuencia de registro. Puesto que estos objetos afectan a la eficacia de la recogida de basura, es muy importante ajustar la recogida de basura.

Todas las JVM modernas utilizan algoritmos de recogida de basura paralelos, lo que significa que si se utilizan más núcleos se puede reducir las pausas en la recogida de basura. Un servidor físico con ocho núcleos tiene una recogida de basura más rápida que un servidor físico con cuatro núcleos.

Cuando la aplicación debe gestionar una gran cantidad de datos para cada partición, la recogida de basura podría ser un factor. Un escenario principalmente de lectura funciona incluso con almacenamientos intermedios grandes (20 GB o más) si se utiliza un recopilador generacional. Sin embargo, después de que se llene el almacenamiento dinámico de tenencia, se produce una pausa proporcional al tamaño del almacenamiento dinámico activo y al número de procesadores en el sistema. Esta pausa puede ser grande en sistemas más pequeños con almacenamientos dinámicos grandes.

Máquina virtual IBM para la recogida de basura de Java

Para la máquina virtual IBM® para Java, utilice el recopilador optavgpause para escenarios con un índice alto de actualización (100% de entradas de modificación de transacciones). El recopilador gencon funciona mucho mejor que el recopilador optavgpause para escenarios donde los datos se actualizan con relativa poca frecuencia (10% del tiempo o menos). Experimente con los dos tipos de recolectores para ver cuál funciona mejor en su escenario. Realice la ejecución con la recogida de basura detallada activada para comprobar el porcentaje de tiempo que se emplea en la recogida de basura. Se han dado casos en los que se empleaba el 80% del tiempo en la recogida de basura hasta que se arregló el problema.

Utilice el parámetro -Xgcpolicy para cambiar el mecanismo de recogida de basura. El valor del parámetro -Xgcpolicy se puede establecer en: -Xgcpolicy:gencon o -Xgcpolicy:optavgpause, en función de la recogida de basura que desea utilizar.

Otras opciones de recogida de basura

Atención: Si utiliza una JVM Oracle, es posible que sean necesarios ajustes en la recogida de basura predeterminada y en la política de ajuste.

WebSphere eXtreme Scale soporta WebSphere Real Time Java. Con WebSphere Real Time Java, la respuesta del proceso de transacción de WebSphere eXtreme Scale es más coherente y predecible. Como resultado, el impacto de la recogida de basura y la planificación de hebras se minimiza considerablemente. El impacto se reduce hasta el nivel de que la desviación estándar del tiempo de respuesta es menor que el 10% del Java habitual.

Rendimiento de la JVM

WebSphere eXtreme Scale se puede ejecutar en distintas versiones de Java Platform, Standard Edition. WebSphere eXtreme Scale soporta Java SE versión 5, Java SE versión 6 y Java SE versión 7. Para mejorar la productividad y el rendimiento del desarrollador, utilice Java SE versión 5, versión 6, o Java SE versión 7 para beneficiarse de las anotaciones y de una recogida de basura mejorada. WebSphere eXtreme Scale funciona en máquina virtuales Java de 32 bits o de 64 bits.

WebSphere eXtreme Scale se prueba con un subconjunto de las máquinas virtuales disponibles, sin embargo, la lista soportada no es exclusiva. Puede ejecutar WebSphere eXtreme Scale en cualquier JVM de proveedor en la Edición 5 o posterior. Sin embargo, si se produce un problema con una JVM de proveedor, debe ponerse en contacto con el proveedor de JVM para solicitar soporte. Si es posible, utilice la JVM del tiempo de ejecución de WebSphere en cualquier plataforma que dé soporte a WebSphere Application Server.

En general, utilice la versión más reciente disponible de Java Platform, Standard Edition para obtener el mejor rendimiento.

Tamaño de almacenamiento dinámico

La recomendación es almacenamientos dinámicos de entre 1 y 2 GB con una JVM por cada cuatro núcleos. El número óptimo del tamaño de almacenamiento dinámico depende de los factores siguientes:
  • El número de objetos activos en el almacenamiento dinámico.
  • La complejidad de los objetos activos del almacenamiento dinámico.
  • El número de núcleos disponibles para la JVM.

Por ejemplo, una aplicación que almacena matrices de bytes de 10 K puede ejecutar un almacenamiento dinámico más grande que una aplicación que utiliza gráficos complejos de objetos POJO.

Número de hebras

El número de hebras depende de unos pocos factores. Existe un límite en el número de hebras que puede gestionar un solo fragmento. Un fragmento es una instancia de una partición, y puede ser un fragmento primario o de réplica. Con más fragmentos para cada JVM, tiene más hebras con cada fragmento adicional, lo que proporciona más vías de acceso simultáneas a los datos. Cada fragmento es tan simultáneo como es posible aunque hay un límite para la simultaneidad.

Requisitos de Object Request Broker (ORB)

IBM SDK incluye una implementación de IBM ORB que se ha probado con WebSphere Application Server y WebSphere eXtreme Scale. Para facilitar el proceso de soporte, utilice una JVM proporcionada por IBM. Otras implementaciones de JVM utilizan un ORB diferente. El ORB de IBM sólo se proporciona con máquinas virtuales IBM-provided Java. WebSphere eXtreme Scale requiere un ORB en funcionamiento para poder funcionar. Puede utilizar WebSphere eXtreme Scale con ORB de otros proveedores. Sin embargo, si tiene un problema con un proveedor de ORB, debe ponerse en contacto con el proveedor del ORB para obtener soporte. La implementación del IBM ORB es compatible con las máquinas virtuales Java de otros proveedores y se puede sustituir, si es necesario.

Ajuste de orb.properties

En el laboratorio, se ha utilizado el archivo siguiente en cuadrículas de datos de hasta 1500 JVM. El archivo orb.properties se encuentra en la carpeta lib del entorno de ejecución.
# Propiedades de IBM JDK para ORB
org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton

# Interceptores de WS
org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer

# Propiedades de plugins y ORB de WS
com.ibm.CORBA.ForceTunnel=never
com.ibm.CORBA.RequestTimeout=10
com.ibm.CORBA.ConnectTimeout=10

# Necesario cuando muchas JVM se conectan al catálogo a la vez
com.ibm.CORBA.ServerSocketQueueDepth=2048

# Los clientes y el servidor de catálogo pueden tener sockets abiertos para todas las JVM
com.ibm.CORBA.MaxOpenConnections=1016

# Agrupación de hebras para el manejo de solicitudes de entrada, aquí 200 hebras
com.ibm.CORBA.ThreadPool.IsGrowable=false
com.ibm.CORBA.ThreadPool.MaximumSize=200
com.ibm.CORBA.ThreadPool.MinimumSize=200
com.ibm.CORBA.ThreadPool.InactivityTimeout=180000

# No se dividen las peticiones/respuestas grandes en fragmentos menores
com.ibm.CORBA.FragmentSize=0