Valores de la máquina virtual Java

83,29/3724,32 * 100 = 2,236 por ciento

Si está empleando más del 5 por ciento del tiempo en la recogida de basura y ésta se produce con frecuencia, puede que deba aumentar el tamaño del almacenamiento dinámico Java.

Para determinar si el almacenamiento dinámico asignado crece, fíjese en el porcentaje del almacenamiento dinámico que permanece sin asignar tras cada ciclo de recogida de basura y verifique que este porcentaje no sigue disminuyendo. Si el porcentaje de espacio libre sigue disminuyendo, el tamaño de almacenamiento dinámico experimenta un crecimiento gradual entre cada recogida de basura. Esta situación podría indicar que la aplicación sufre una fuga de memoria.

Especifique -DhotRestartSync si desea habilitar la característica de sincronización de reinicio dinámico del servicio de sincronización. Esta característica indica al servicio de sincronización que la instalación se está ejecutando en un entorno en el que las actualizaciones de configuración no se realizan cuando el gestor de despliegue no está activo. Por lo tanto, el servicio no tiene que realizar una comparación completa del depósito cuando se reinicia el gestor de despliegue o los servidores de agente de nodo. Si habilita esta característica mejorará la eficacia de la primera operación de sincronización una vez que se ha reiniciado el gestor de despliegue o el agente de nodo, en especial para las instalaciones que incluyen células de distintos releases, utilizan varios nodos y ejecutan varias aplicaciones.

Establezca esta opción en true si desea habilitar la función AES (estándar de cifrado avanzado) que se proporciona con IBM SDK and Runtime Environment for AIX, Java Technology Edition, Versión 7. AES es un cifrado de bloque simétrico que cifra y descifra los datos en varias rondas. La habilitación de esta función ha dado como resultado mejoras de rendimiento en el proceso SSL de WebSphere Application Server.

Especifique -Xverify:none si desea ignorar la fase de verificación de clases durante la carga de clases. La utilización de -Xverify:none inhabilita la verificación de clases Java lo que puede representar una mejora del 10 al 15 por ciento en el tiempo de arranque. Sin embargo, los datos de clases dañados o no válidos no se detectan si se especifica este argumento. Si se cargan datos de clases dañados, la JVM podría comportarse de manera inesperada o podría fallar.

Evite problemas:

• No utilice este argumento si efectúa modificaciones en el código de bytes porque la JVM podría fallar si se produce algún error de instrumentación.
• Si experimenta una anomalía en la JVM o esta se comporta de manera inesperada mientras este argumento está en vigor, elimine este argumento como primer paso para depurar el problema de la JVM.
• IBM i no soporta este argumento.

gotcha

Especifique -Xnoclassgc si desea inhabilitar la recogida de basura de clases. Este argumento lleva a reutilizar más las clases y a un rendimiento ligeramente mayor. No obstante, se siguen utilizando los recursos que son propiedad de estas clases aunque no se las llame.

Evite problemas: El impacto sobre el rendimiento de la recogida de basura de clases normalmente es mínimo, y si se desactiva la recogida de basura de clases en un sistema basado en Java EE (Java Platform, Enterprise Edition), con su uso intenso de cargadores de clases de aplicaciones, es posible crear efectivamente una pérdida de memoria de datos de clase y causar que la JVM genere una excepción de falta de memoria.gotcha

Puede utilizar el valor de configuración verbose:gc si desea supervisar la recogida de basura. Puede utilizar la salida resultante para determinar el impacto en el rendimiento producido al reclamar estos recursos.

Si especifica el argumento -Xnoclassgc, cuando vuelva a desplegar una aplicación, siempre deberá reiniciar el servidor de aplicaciones para borrar las clases y los datos estáticos de la versión anterior de la aplicación.

Evite problemas: IBM i no soporta este argumento.Debe utilizar el argumento -noclassgc para inhabilitar la recogida de basura de clases en esta plataforma.gotcha

Especifique -Xgcthreads si desea utilizar varias hebras de recogida de basura al mismo tiempo. Estas técnicas de recogida de basura son conocidas como recogida de basura paralela. Este argumento es válido sólo para IBM Developer Kit.

Cuando especifica este valor en el campo Argumentos genéricos de JVM, también debe especificar el número de procesadores que se ejecutan en la máquina.

Especifique -Xgcthreads del modo siguiente:

-Xgcthreads<número de procesadores>

Evite problemas: No añada un espacio entre --Xgcthreads y el valor n para el número de procesadores.

-Xgcthreads5 es un ejemplo de especificar -Xgcthreads con 5 procesadores.

gotcha

Procedimientos recomendados: Debe utilizar la recogida de basura paralela, si la máquina tiene más de un procesador.bprac

Evite problemas: IBM i no soporta este argumento.gotcha

Especifique -Xnocompactgc si desea inhabilitar la compactación del almacenamiento dinámico. La compactación del almacenamiento dinámico es la operación de recogida de basura más cara. Si utiliza IBM Developer Kit, debe evitar la compactación de almacenamiento dinámico. Si inhabilita la compactación del almacenamiento dinámico, elimina toda la actividad general asociada.

Evite problemas: IBM i no soporta este argumento.gotcha

Especifique -Xgcpolicy para establecer la política de recogida de basura. Este argumento es válido sólo para IBM Developer Kit.

Establezca el valor de este argumento en optthruput si desea optimizar el rendimiento y no crea un problema si se producen largas pausas durante la recogida de basura.

Establezca este argumento en gencon si utiliza un colector de basura generacional. El esquema generacional intenta conseguir un alto rendimiento junto con una reducción de los tiempos de pausa de recogida de basura. Para alcanzar este objetivo, el almacenamiento dinámico se divide entre segmentos nuevos y antiguos. Los objetos de larga duración se promocionan al espacio antiguo mientras que los objetos de corta duración se recogen rápidamente en el recopilador de basura en el nuevo espacio. La política gencon proporciona ventajas significativas para muchas aplicaciones. No obstante, no es adecuada para todas las aplicaciones y normalmente es más difícil de ajustar.

Establezca este argumento en optavgpause, si desea utilizar la marca simultánea para realizar un seguimiento de las hebras de aplicación a partir de la pila, antes de que el almacenamiento dinámico esté lleno. Si se especifica este parámetro, las pausas del recolector de basura son uniformes y las pausas más largas no son aparentes. Sin embargo, la utilización de esta política reduce el rendimiento, ya que las hebras tendrán que realizar un trabajo adicional.

Establezca este argumento en subpool si desea aumentar el rendimiento en sistemas de varios procesadores que habitualmente utilizan más de ocho procesadores. Esta política sólo está disponible en los procesadores System i, System p y System z de IBM. La política subpool es parecida a la política optthruput excepto en que el almacenamiento dinámico se divide en subagrupaciones que proporcionan una escalabilidad mejorada para la asignación de objetos.

Evite problemas: IBM i no soporta este argumento.gotcha

Java Platform, Standard Edition 6 (Java SE 6) tiene recogida de basura de generación, lo que permite que agrupaciones de memoria separadas contengan objetos con distinta antigüedad. El ciclo de recogida de basura recopila los objetos de forma separada según la antigüedad. Con parámetros adicionales, puede establecer el tamaño de las agrupaciones de memoria separadamente. Para mejorar el rendimiento, establezca el tamaño de la agrupación que contiene objetos que tengan ciclos de vida cortos, para que los objetos de la agrupación no se conserven durante más de un ciclo de recogida de basura. Utilice los parámetros NewSize y MaxNewSize para especificar el tamaño de la agrupación de nueva generación.

-XX:NewSize=límite_inferior
-XX:MaxNewSize=límite_superior
 -XX:SurvivorRatio=nuevo_tamaño_proporción 

Procedimientos recomendados: Sin embargo, si tiene una JVM con más de 1 GB de tamaño de almacenamiento dinámico, debe usar los siguientes valores:

• -XX:NewSize=640m
• -XX:MaxNewSize=640m
• -XX:SurvivorRatio=16

bprac

Como alternativa, puede establecer de 50% a 60% del tamaño total de almacenamiento dinámico para una agrupación de generación nueva.

Evite problemas: IBM i no soporta este argumento.gotcha

Especifique -Xminf si desea cambiar el porcentaje mínimo de tamaño de almacenamiento dinámico libre. El almacenamiento dinámico crece si el espacio libre está por debajo de la cantidad especificada. En la modalidad de restauración habilitada, este argumento especifica el porcentaje mínimo de espacio libre para las pilas de middleware y temporales. El valor especificado para este argumento es un número de coma flotante, del 0 al 1. El valor predeterminado es 0,3 (30 por ciento).

Evite problemas: IBM i no soporta este argumento.gotcha

Java HotSpot Technology de Java SE 6 utiliza una JVM adaptativa que contiene algoritmos que, con el tiempo, optimizan el funcionamiento del bytecode. La JVM se ejecuta en dos modalidades, -server y -client. En la mayoría de los casos, utilice la modalidad -server , que permite un rendimiento más eficaz en periodos de tiempo largos.

Si utiliza la modalidad -client predeterminada, el tiempo de arranque del servidor es más rápido y con un menor uso de la memoria. No obstante, esta modalidad reduce el rendimiento a la larga. Utilice la modalidad -server, que mejora el rendimiento, a menos que el tiempo de arranque del servidor tenga mayor importancia que el rendimiento. Puede supervisar el tamaño del proceso y el tiempo de arranque del servidor para comprobar la diferencia en rendimiento entre las modalidades -client y -server.

Evite problemas: IBM i no soporta este argumento.gotcha

Especifique el argumento -Dcom.ibm.CORBA.RequestTimeout= intervalo_tiempo_espera para establecer el período de tiempo de espera para responder a las solicitudes enviadas desde el cliente. Este argumento utiliza la opción -D. intervalo_tiempo_espera es el período de tiempo de espera en segundos. Si la red tiene muchas dificultades de latencia, especifique un valor grande para evitar que se exceda el tiempo de espera. Si se especifica un valor demasiado pequeño, un servidor de aplicaciones que participa en la gestión de la carga de trabajo puede exceder el tiempo de espera antes de recibir una respuesta.

Especifique este argumento sólo si la aplicación tiene dificultades porque excede los tiempos de espera. No hay valores recomendados para este argumento.

El argumento -Dcom.ibm.server.allow.sigkill=true permite que el proceso de agente de nodo utilice el método terminate de un proceso cuando el método stop no se completa en el intervalo de tiempo especificado para el intervalo de sondeo. Este valor es útil cuando el agente de nodo supervisa un servidor de aplicaciones y pierde contacto con ese servidor de aplicaciones.

Cuando la política de supervisión para el servidor de aplicaciones permite que el agente de nodo reinicie el servidor de aplicaciones debido a que se ha habilitado el reinicio automático para el servidor de aplicaciones, el agente de nodo ejecuta el método stop en el proceso del servidor de aplicaciones. Durante el proceso de detención, el agente de nodo supervisa el servidor de aplicaciones y si éste no se detiene en el intervalo de tiempo especificado para el intervalo de sondeo, y este argumento está establecido en true, que es el valor predeterminado, el agente de nodo ejecuta el método terminate en el proceso del servidor de aplicaciones para detener dicho proceso.

Si establece este argumento en false, el agente de nodo continúa supervisando el proceso de detención, pero no intenta reiniciar el servidor de aplicaciones.

Para utilizar la consola de administración para inhabilitar este argumento, pulse Administración del sistema > Agentes de nodo > nombre_agente_nodo > Java & Gestión de procesos > Definición de proceso > Máquina virtual Java > Argumentos de JVM genéricos.

Este argumento especifica el número máximo de veces que una alarma informa de su seguimiento de la pila completo en mensajes de hebra colgada en los registros del sistema.

Cuando una hebra de alarma del sistema está activa durante más tiempo que el umbral de supervisor de hebras de alarma, el servidor de aplicaciones registra un mensaje de hebra colgada con el nombre de la hebra de alarma, el período de tiempo que la hebra de alarma ha estado activa y el seguimiento de pilas de excepciones completo. El seguimiento de la pila completa para depurar la causa del retraso, pero si se desencadenan con frecuencia mensajes de hebra colgada, los mensajes largos repetidos pueden ofrecer otro tipo de información en los registros del sistema que resultan difíciles de encontrar. Establezca este argumento en un entero mayor que 0 para especificar el número máximo de veces que una simple alarma informa de su seguimiento de pila completo. Cuando se alcanza este umbral, cada mensaje de hebra colgada posterior sólo incluye la entrada del manejador de alarmas colgadas.

El valor predeterminado de 0 indica que todos los mensajes de hebra colgada de una alarma incluyen el seguimiento de pila completo.

Especifique este argumento para añadir una indicación de fecha y hora así como el identificador de hebra antes de que todos los mensajes de depuración del servidor sean la salida a los archivos de registro native_stdout y native_stderr. Puede utilizar la indicación de fecha y hora así como el identificador de hebra para correlacionar los comportamientos de los componentes del programa de arranque del servidor de aplicaciones con los comportamientos de otros mecanismos del servidor, que se indican en los archivos de registro SystemOut y SystemErr. Este comportamiento está inhabilitado de forma predeterminada.

Cuando se configura el servidor con un argumento genérico de JVM -Dws.ext.debug=true, emite mensajes de depuración durante la secuencia de la rutina de carga para native_stdout.log y native_stderr.log. Si -Dcom.ibm.websphere.native.logging.timestamp también se ha establecido en true, el servidor emite una salida de los mensajes de depuración con una indicación de fecha y hora así como el identificador de hebras, tal como se muestra en el ejemplo siguiente:

[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[0]=-nosplash
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[1]=-application
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer

Este argumento sólo es aplicable en z/OS. Especifique el argumento -Dcom.ibm.websphere.wlm.unusable.interval= intervalo_tiempo_espera para cambiar el valor de la propiedad com.ibm.websphere.wlm.unusable.interval si el estado de gestión de la carga de trabajo del cliente se renueva con demasiada rapidez o con demasiada lentitud. Esta propiedad especifica, en segundos, el periodo de tiempo que espera el cliente de gestión de la carga de trabajo a marcar un servidor como no disponible antes de intentar volver a ponerse en contacto con el servidor. Este argumento utiliza la opción -D. El valor predeterminado es 300 segundos.Si la propiedad es establece en un valor demasiado grande, el servidor se marca como no disponible durante un período de tiempo largo. Esto impide que el protocolo de renovación de la gestión de la carga de trabajo renueve el estado de gestión de la carga de trabajo del cliente hasta después de que finalice el período.

Este argumento sólo es aplicable en z/OS. Especifique el argumento -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= para indicar que se deben liberar los almacenamientos intermedios de bytes directos individuales en cuanto el almacenamiento intermedio ya no se necesita. El único valor soportado para este argumento es com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.

-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

En la plataforma z/OS, también debe especificar este argumento si especifica la propiedad personalizada zaioFreeInitialBuffers para un canal TCP para que el canal libere los almacenamientos intermedios de lectura iniciales utilizados en las nuevas conexiones, tan pronto como estos almacenamientos intermedios ya no sean necesarios para la conexión.

Especifica si la comprobación de conformidad SIP está habilitada en el servidor proxy SIP. La comprobación de conformidad SIP garantiza que los mensajes SIP cumplan con el estándar Session Initiation Protocol. Cuando esta propiedad está establecida en true, se habilita la comprobación de conformidad SIP.

Evite problemas: Si ejecuta un servidor proxy en un entorno de z/OSWebSphere Application Server, Network Deployment, y el servidor proxy no forma parte de un clúster, puede utilizar la propiedad personalizada del servidor proxy SIP isSipComplianceEnabled para habilitar o inhabilitar la comprobación de conformidad SIP para dicho servidor proxy SIP. No obstante, si está ejecutando un servidor de aplicaciones autónomo o el servidor proxy forma parte de un clúster, debe utilizar este argumento JVM genérico para habilitar o inhabilitar la comprobación de conformidad SIP.gotcha

Especifique el argumento -Xshareclasses:none para inhabilitar la opción de compartir clases para un proceso. La opción de compartir clases, que está disponible con Java SE 6, le permite compartir clases en la memoria caché. Al compartir clases en una memoria caché se mejora el tiempo de arranque y se disminuye el uso de la memoria. Procesos como, por ejemplo, los servidores de aplicaciones, los agentes de nodos y los gestores de despliegue pueden utilizar la opción de compartir clases.

Si utiliza esta opción, debe borrar la memoria caché cuando no se utiliza el proceso. Para borrar la memoria caché, invoque el programa de utilidad raíz_servidor_aplicaciones/bin/clearClassCache.bat/sh y luego reinicie el proceso.

Evite problemas:

• La JVM IBM para J2SE 5 no está soportada en Solaris, HP e IBM i.
• Las clases de aplicación Java EE que se ejecutan en un proceso del servidor de aplicaciones no se añaden a la memoria caché de la clase compartida.

gotcha

Utilice el argumento -XXallowvmshutdown:false argument para volver a un comportamiento anterior para la JVM que no es correcto. Java 5.0 SR10 y Java 6 SR5 corrigen problemas por los que la máquina virtual Java (JVM) no se cierra correctamente. Si tiene una aplicación que depende del comportamiento anterior, puede volver al comportamiento anterior añadiendo este argumento en la sección Argumentos de JVM genéricos.