Utilice esta página para ver y modificar los valores de configuración de la JVM (Java Virtual Machine) de un proceso de un servidor de aplicaciones.
Para ver esta página de la consola administrativa, conéctese a la consola administrativa y vaya al panel de la máquina virtual Java.
Para i5/OS y plataformas distribuidas, pulse Servidores > Tipos de servidor > Servidores de aplicaciones > nombre_servidor.
A continuación, en Infraestructura de servidor, pulse Java
y gestión de procesos > Definición de procesos > Máquina virtual Java
Servidor de aplicaciones | Pulse Servidores > Tipos de servidor > Servidores de aplicaciones WebSphere > nombre_servidor. A continuación, en Infraestructura de servidor, pulse Java y gestión de procesos > Definición de procesos > Control > Máquina virtual Java |
Gestor de despliegue | Pulse Administración del sistema > Gestor de despliegue. A continuación, en Infraestructura de servidor, pulse Java y gestión de procesos > Definición de procesos > Control > Máquina virtual Java |
Agente de nodo | Pulse Administración del sistema > Agente de nodo > agente_nodo. A continuación, en Infraestructura de servidor, pulse Java y gestión de procesos > Definición de procesos > Máquina virtual Java |
Servidor de aplicaciones | Servidores > Tipos de servidor > Servidores de aplicaciones WebSphere > nombre_servidor. A continuación, en Infraestructura de servidor, pulse Java y gestión de procesos > Definición de procesos > Máquina virtual Java |
Gestor de despliegue | Administración del sistema > Gestor de despliegue. A continuación, en Infraestructura de servidor, pulse Java y gestión de procesos > Definición de procesos > Máquina virtual Java |
Agente de nodo | Administración del sistema > Agente de nodo > agente_nodo. A continuación, en Infraestructura de servidor, pulse Java y gestión de procesos > Definición de procesos > Máquina virtual Java |
Especifica la classpath estándar donde el código de la máquina virtual Java busca las clases.
Si debe añadir una variable classpath a este campo, especifique la entrada classpath en una fila de tabla distinta. No es necesario que añada un carácter de dos puntos o punto y coma al final de cada entrada.
Tipo de datos | Serie |
Especifica las clases y recursos de rutina de carga para el código JVM. Esta opción sólo está disponible para las instrucciones JVM que dan soporte a las clases y recursos de rutina de carga.
Si debe añadir una variable classpath a este campo, especifique la entrada classpath en una fila de tabla. No es necesario añadir el símbolo de dos puntos o de punto y coma al final de cada entrada.
Si debe añadir varias variables classpath en este campo, para separarlas puede utilizar un carácter de dos puntos (:) o o punto y coma (;), en función del sistema operativo en el que resida la JVM.
Si debe añadir varias variables classpath en este campo, para separarlas puede utilizar un carácter de dos puntos (:) o o punto y coma (;), en función del sistema operativo en el que resida el nodo.
Especifica si se debe utilizar la salida de depuración verbosa de la carga de clase. El valor predeterminado es no habilitar la carga de clase verbosa.
Si se habilita la carga de clases verbosa, la salida de depuración se envía a una de las anotaciones de proceso nativas.
Tipo de datos | Booleano |
Valor predeterminado | false |
Especifica si se debe utilizar la salida de depuración verbosa de la recogida de basura. El valor predeterminado es no habilitar la recogida de basura verbosa.
Si se habilita la recogida de basura verbosa, la salida de depuración se envía a una de las anotaciones de proceso nativas.
,
Tipo de datos | Booleano |
Valor predeterminado | false |
Cuando este campo está habilitado, se escribirá un informe en la secuencia de salida cada vez que se ejecute el recopilador de basura. Este informe debe ofrecerle una indicación de cómo se está realizando el proceso de recogida de basura 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 de Java.
Para determinar si el almacenamiento dinámico asignado está aumentando, mire el porcentaje del almacenamiento dinámico que permanece sin asignar después de cada ciclo de recogida de basura y verifique que el porcentaje no va disminuyendo. Si el porcentaje de espacio libre va disminuyendo, sufre un aumento gradual del tamaño del almacenamiento dinámico entre cada recogida de basura. Esta situación puede indicar fugas de memoria en la aplicación.
En la plataforma z/OS también puede emitir el mandato de consola MVS, modify display, jvmheap, para visualizar la información de almacenamiento dinámico de JVM.
Además, pude comprobar la actividad de servidor y los registros
de SMF de intervalo. El tamaño de almacenamiento dinámico de JVM también está
disponible en PMI y puede supervisarse mediante Tivoli Performance Viewer.
Especifica si se debe utilizar la salida de depuración verbosa de la invocación de método nativo. El valor predeterminado es no habilitar la actividad de JNI (Java Native Interface) verbosa.
Tipo de datos | Booleano |
Valor predeterminado | false |
Especifica, en megabytes, el tamaño de almacenamiento dinámico inicial disponible para el código de JVM. Si este campo se deja en blanco, se utiliza el valor por omisión.
Para z/OS, el tamaño de almacenamiento dinámico
inicial por omisión para el controlador es 48 MB, y el tamaño de
almacenamiento dinámico inicial por omisión para el sirviente es 128
MB. Estos valores predeterminados se aplican a las configuraciones de 31 bits y de 64 bits.
Para i5/OS y plataformas distribuidas, el
tamaño de almacenamiento dinámico inicial por omisión es 50 MB.
Aumentar este valor puede suponer una mejora en el proceso de arranque. Se reduce el número de veces que se efectúa la recogida de basura y se obtiene una mejora de rendimiento del 10 por ciento.
Incrementar el tamaño del almacenamiento dinámico de Java sigue mejorando el rendimiento hasta que el almacenamiento dinámico es demasiado grande para residir en la memoria física. Si el tamaño del almacenamiento dinámico supera la memoria física disponible, y se produce una paginación, el rendimiento sufre una disminución notable.
Especifica, en megabytes, el tamaño máximo de almacenamiento dinámico que hay disponible para el código de JVM. Si este campo se deja en blanco, se utiliza el valor por omisión.
Para z/OS, el tamaño de almacenamiento dinámico
máximo predeterminado es 256 MB. Este valor predeterminado se aplica
para configuraciones de 31 y 64 bits.
El incremento del valor de tamaño de almacenamiento dinámico máximo puede mejorar el proceso de arranque. Al aumentar el tamaño de almacenamiento dinámico, se reduce el número de veces que se efectúa la recogida de basura con una mejora de rendimiento del 10 por ciento.
El incremento de este valor generalmente mejora el rendimiento hasta que el almacenamiento dinámico es demasiado grande para residir en la memoria física. Si el tamaño del almacenamiento dinámico supera la memoria física disponible, y se produce una paginación, el rendimiento sufre una disminución notable. Por consiguiente,e s importante que el valor que especifique para esta propiedad permita la presencia del almacenamiento dinámico en la memoria física.
Para evitar la paginación, especifique un valor de esta propiedad que permita que todos los
procesadores dispongan de 256 MB de memoria física como mínimo y todos
los servidores de aplicaciones de 512 MB. Si la utilización del procesador es baja debido a la paginación, aumente la memoria disponible, si es posible, en lugar de aumentar el tamaño máximo de almacenamiento dinámico. El aumento del tamaño máximo de almacenamiento intermedio puede disminuir el rendimiento en lugar de aumentarlo.
En i5/OS, cuando esta propiedad se establece en 0, el colector de basura solamente se ejecuta cuando se alcanza el umbral del colector de basura.
Cuando se especifica un valor distinto a 0, el colector de basura se ejecuta siempre que el tamaño del almacenamiento dinámico alcanza el tamaño máximo especificado.
No obstante, a diferencia de un recolector de basura normal, si se alcanza el tamaño máximo, todas las hebras de la aplicación deben esperar hasta que el proceso del recolector de basura finalice para poder continuar. Esta situación puede provocar períodos de pausa no deseados. Por lo tanto, utilice el tamaño máximo de almacenamiento dinámico como medida de seguridad para manejar los períodos en los que el almacenamiento dinámico crece de modo imprevisto y así garantizar que el almacenamiento dinámico no crezca por encima de la memoria disponible. En circunstancias normales, no se alcanza nunca el tamaño máximo de almacenamiento dinámico especificado.
Especifica si se utiliza el soporte de perfiles HProf. Para utilizar otro perfil, especifique los valores del perfil personalizado mediante el valor Argumentos de HProf. El valor predeterminado es no habilitar el soporte de perfiles de HProf.
Si establece la propiedad Ejecutar HProf en true, debe especificar los argumentos de perfil de la línea de mandatos como valores de la propiedad Argumentos de HProf.
Tipo de datos | Booleano |
Valor predeterminado | false |
Especifica los argumentos de perfil de la línea de mandatos que se pasan al código JVM que inicia el proceso del servidor de aplicaciones. Puede especificar argumentos cuando el soporte de perfiles de HProf está habilitado.
Los argumentos de HProf sólo son necesarios si se establece la propiedad Ejecutar HProf en true.
Especifica si se debe ejecutar la JVM en modalidad de depuración. El valor predeterminado es no habilitar el soporte de modalidad de depuración.
Si establece la propiedad Modalidad de depuración en true, debe especificar los argumentos de depuración de la línea de mandatos como valores de la propiedad Argumentos de depuración.
Tipo de datos | Booleano |
Valor predeterminado | false |
Especifica los argumentos de depuración de la línea de mandatos que se pasan al código JVM que inicia el proceso del servidor de aplicaciones. Puede especificar argumentos cuando la propiedad Modalidad de depuración esté establecida en true.
Si habilita la depuración en varios servidores de aplicaciones en el mismo nodo, verifique que no se especifica el mismo valor en el argumento de dirección. El argumento de dirección define el puerto que se utiliza para la depuración. Si se configuran dos servidores, en los que se habilita la depuración, para que utilicen el mismo puerto de depuración, puede que los servidores no se inicien correctamente. Por ejemplo, puede que los dos servidores aún estén configurados con el argumento de depuración address=7777, que es el valor predeterminado del argumento de dirección de depuración.
Si habilita la depuración en varios servidores de aplicaciones, verifique que no se especifica el mismo valor en el argumento de dirección. El argumento de dirección define el puerto que se utiliza para la depuración. Si se configuran dos servidores, en los que se habilita la depuración, para que utilicen el mismo puerto de depuración, puede que los servidores no se inicien correctamente. Por ejemplo, puede que los dos servidores aún estén configurados con el argumento de depuración address=7777, que es el valor predeterminado del argumento de dirección de depuración.
Tipo de datos | Serie |
Unidades | Argumentos de línea de mandatos de Java |
Especifica los argumentos de línea de mandatos que se pasan al código de la máquina virtual Java que inicia el proceso del servidor de aplicaciones.
Especifique hotRestartSync 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 repositorio 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, utilicen varios nodos y ejecutan varias aplicaciones.
Especifique -Xverify:none si desea evitar 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, cuando se especifica este argumento, no se detectarán datos de clases no válidos o anómalos. Si se cargan datos de clase anómalos, puede que la JVM se comporte de una forma imprevista o que tenga un funcionamiento anómalo.
Especifique -Xnoclassgc si desea inhabilitar la recogida de basura de clases. Este argumento se traduce en una mayor reutilización de las clases y un rendimiento ligeramente mayor. No obstante, los recursos propiedad de estas clases siguen en uso cuando no se efectúa ninguna llamada a dichas clases. 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 que la reclamación de estos recursos causa en el rendimiento. Si se realiza repetidamente la recogida de basura del mismo conjunto de clases, puede que sea deseable inhabilitar la recogida de basura de clases. La recogida de basura de clases está habilitada por omisión.
Especifique -Xgcthreads si desea utilizar varias hebras de recogida de basura al mismo tiempo. Esta técnica de recogida de basura se conoce como recogida de basura en paralelo. Este argumento es válido sólo para IBM Developer Kit.
Cuando especifique este valor en el campo Argumentos de la JVM genéricos, especifique también el número de procesadores que se ejecutan en la máquina. Por ejemplo, si tiene 3 procesadores ejecutándose en la máquina, especifique -Xgcthreads 3. En un nodo con n procesadores, el número de hebras por omisión es n.
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 del almacenamiento dinámico. Si inhabilita la compactación del almacenamiento dinámico, elimina toda la actividad general asociada.
Especifique -Xgpolicy para establecer la política de recogida de basura. Este argumento es válido sólo para IBM Developer Kit.
Establezca este argumento en optavgpause si desea que se utilice la marca simultánea para hacer un seguimiento de las hebras de aplicaciones que se inician desde la pila hasta que se llene el almacenamiento dinámico. Cuando se especifica este parámetro, las pausas del colector de basura son uniformes y las pausas más largas no son aparentes. No obstante, la utilización de esta política disminuye el rendimiento puesto que las hebras pueden tener que hacer un trabajo adicional.
Establezca este argumento en optthruput si desea optimizar el rendimiento y no crear un problema si se produce una pausa larga en la recogida de basura. Éste es el parámetro por omisión y el valor recomendado.
Java Platform, Standard Edition 6 (Java SE 6) tiene recogida de basura de generación, 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 los objetos de ciclo de vida más corto para que los objetos de la agrupación no se conserven 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 generación nueva.
-XX:NewSize=límite_inferior -XX:MaxNewSize=límite_superior -XX:SurvivorRatio=nuevo_tamaño_ratio
Especifique -Xminf si desea modificar el porcentaje de tamaño de almacenamiento dinámico libre mínimo. La pila 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 los almacenamientos dinámicos del middleware y temporales. El valor especificado para este argumento es un número de coma flotante, del 0 al 1. El valor predeterminado es .3 (30 por ciento).
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 casos, utilice la modalidad -server , que proporciona una ejecución más eficaz en períodos de tiempo largos.
Si utiliza la modalidad -client por omisión, el tiempo de arranque del servidor es más corto y se efectúa un menor uso de memoria. No obstante, esta modalidad disminuye el mayor rendimiento. Utilice la modalidad -server, que aumenta 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 las diferencias de rendimiento entre las modalidades -client y -server.
Este argumento sólo es aplicable a z/OS. Especifique el argumento -Dcom.ibm.CORBA.RequestTimeout=intervalo_tiempo_espera para establecer el período de tiempo de espera para responder a las peticiones 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 sufre problemas de tiempo de espera. No existen valores recomendados para este argumento.
Este argumento sólo es aplicable a z/OS. Especifique el argumento -Dcom.ibm.websphere.wlm.unusable.interval=intervalo_tiempo_espera para modificar el valor de la propiedad com.ibm.websphere.wlm.unusable.interval cuando 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 intervalo 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 a 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 deje de ser necesario. El único valor admitido 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 indicar que el canal libere los almacenamientos intermedios de lectura iniciales utilizados en las conexiones nuevas tan pronto como dichos almacenamientos intermedios ya no sean necesarios para la conexión.
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.
Tipo de datos | Serie |
Unidades | Argumentos de línea de mandatos de Java |
Especifica un nombre completo de la vía de acceso del archivo JAR ejecutable que el código JVM utiliza.
Tipo de datos | Serie |
Unidades | Nombre de vía de acceso |
Especifica si se debe inhabilitar la opción del compilador JIT (just-in-time) del código JVM.
Si inhabilita el compilador JIT, el rendimiento disminuirá de forma perceptible. Por lo tanto, por motivos de rendimiento, mantenga JIT habilitado.
Tipo de datos | Booleano |
Valor predeterminado | false (JIT habilitado) |
Recomendado | JIT habilitado |
Especifica los valores de JVM de un determinado sistema operativo.
Cuando se inicia el proceso, éste utiliza los valores de la JVM especificados para el servidor como los valores de JVM para el sistema operativo.
Cuando se inicia el proceso, éste utiliza los valores de la JVM especificados para el nodo como los valores de JVM para el sistema operativo.
Especifica si se debe utilizar la salida de depuración verbosa de la recogida de basura. El valor predeterminado es no habilitar la recogida de basura verbosa.
Si se habilita la recogida de basura verbosa, la salida de depuración se envía a una de las anotaciones de proceso nativas.
,
Tipo de datos | Booleano |
Valor predeterminado | false |
Cuando este campo está habilitado, se escribirá un informe en la secuencia de salida cada vez que se ejecute el recopilador de basura. Este informe debe ofrecerle una indicación de cómo se está realizando el proceso de recogida de basura 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 de Java.
Para determinar si el almacenamiento dinámico asignado está aumentando, mire el porcentaje del almacenamiento dinámico que permanece sin asignar después de cada ciclo de recogida de basura y verifique que el porcentaje no va disminuyendo. Si el porcentaje de espacio libre va disminuyendo, sufre un aumento gradual del tamaño del almacenamiento dinámico entre cada recogida de basura. Esta situación puede indicar fugas de memoria en la aplicación.
En la plataforma z/OS también puede emitir el mandato de consola MVS, modify display, jvmheap, para visualizar la información de almacenamiento dinámico de JVM.
Además, pude comprobar la actividad de servidor y los registros
de SMF de intervalo. El tamaño de almacenamiento dinámico de JVM también está
disponible en PMI y puede supervisarse mediante Tivoli Performance Viewer.
Los enlaces marcados (en línea) requieren acceso a Internet.