Valores de la máquina virtual Java

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.

[AIX Solaris HP-UX Linux Windows] [iSeries] 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

[z/OS] Para la plataforma z/OS siga uno de los siguientes recorridos.
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
[AIX Solaris HP-UX Linux Windows] [iSeries] Para las plataformas i5/OS y distribuidas, siga uno de los siguientes recorridos.
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

Pestaña Configuración

Classpath

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.

En este campo sólo deben añadirse las variables classpath que especifican la ubicación de los siguientes elementos:
  • Una herramienta de inspección o supervisión para el sistema.
  • Archivos JAR para un producto que se ejecuta encima de este producto.
  • Parches o arreglos de diagnóstico de JVM.
Pueden producirse errores de proceso si añade variables classpath a este campo que especifican la ubicación de los elementos siguientes:
  • Archivos JAR para proveedores de recursos, como DB2. Las vías de acceso de estos archivos JAR deben añadirse en las variables classpath relevantes del proveedor.
  • Un archivo JAR utilizado por una o más de las aplicaciones que se ejecutan en el producto. La vía de acceso de este tipo de archivo JAR debe especificarse en cada aplicación que requiera dicho archivo JAR, o en bibliotecas compartidas asociadas con el servidor.
  • Un archivo JAR de extensiones. Si debe añadir un archivo JAR de extensiones al sistema, debe utilizar la propiedad personalizada ws.ext.dirs de JVM para especificar la vía de acceso absoluta de dicho archivo. También puede colocar el archivo JAR en el directorio WAS_HOME/lib/ext/, pero se recomienda utilizar la propiedad personalizada ws.ext.dirs de JVM para especificar la vía de acceso a un archivo JAR de extensiones.
Tipo de datos Serie
Classpath de arranque

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.

En este campo sólo deben añadirse las variables classpath que especifican la ubicación de los siguientes elementos:
  • Una herramienta de inspección o supervisión para el sistema.
  • Archivos JAR para un producto que se ejecuta encima de este producto.
  • Parches o arreglos de diagnóstico de JVM.
Pueden producirse errores de proceso si añade variables classpath a este campo que especifican la ubicación de los elementos siguientes:
  • Archivos JAR para proveedores de recursos, como DB2. Las vías de acceso de estos archivos JAR deben añadirse en las variables classpath relevantes del proveedor.
  • Un archivo JAR utilizado por una o más de las aplicaciones que se ejecutan en el producto. La vía de acceso de este tipo de archivo JAR debe especificarse en cada aplicación que requiera dicho archivo JAR, o en bibliotecas compartidas asociadas con el servidor.
  • Un archivo JAR de extensiones. Si debe añadir un archivo JAR de extensiones al sistema, debe utilizar la propiedad personalizada ws.ext.dirs de JVM para especificar la vía de acceso absoluta de dicho archivo. También puede colocar el archivo JAR en el directorio WAS_HOME/lib/ext/, pero se recomienda utilizar la propiedad personalizada ws.ext.dirs de JVM para especificar la vía de acceso a un archivo JAR de extensiones.
Carga de clase verbosa

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.

[AIX Solaris HP-UX Linux Windows] 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
Recogida de basura verbosa

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.

[AIX Solaris HP-UX Linux Windows] 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.

Puede comprobar el informe verboseGC para determinar:
  • Cuánto tiempo emplea la JVM para realizar la recogida de basura.
    Idealmente, es deseable que la JVM dedique menos del 5 por ciento de su tiempo de procesamiento a la recogida de basura. Para determinar el porcentaje de tiempo que dedica la JVM en la recogida de basura, divida el tiempo que tarda en completar la recogida por el tiempo transcurrido desde el último AF y multiplique el resultado por 100. Por ejemplo:
    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.

  • Si el almacenamiento dinámico asignado aumenta con cada ejecución de la recogida de basura.

    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.

[z/OS] 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.

JNI verbosa

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
Tamaño de almacenamiento dinámico inicial

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.

[z/OS] 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.

[AIX Solaris HP-UX Linux Windows] [iSeries] Para i5/OS y plataformas distribuidas, el tamaño de almacenamiento dinámico inicial por omisión es 50 MB.

Procedimientos recomendados: Estos valores predeterminados son suficientes para la mayoría de aplicaciones. bprac
[iSeries] Evite problemas: Para i5/OS, el tamaño de almacenamiento dinámico máximo debe ser siempre menor que el tamaño de almacenamiento dinámico máximo. No establezca nunca las propiedades de tamaño de almacenamiento dinámico inicial y tamaño de almacenamiento dinámico máximo en el mismo valor. gotcha

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.

Tamaño máximo de almacenamiento dinámico

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.

[z/OS] 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.

[z/OS] 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.

[iSeries] 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.

Procedimientos recomendados: Estos valores predeterminados son adecuados para la mayoría de aplicaciones. Habilite la propiedad Recogida de basura verbosa si cree que la recogida de basura se produce con demasiada frecuencia. Si la recogida de basura se realiza con mucha frecuencia, aumente el tamaño máximo del almacenamiento dinámico JVM. bprac
Ejecutar HProf [AIX Solaris HP-UX Linux Windows] [iSeries]

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
Argumentos de HProf [AIX Solaris HP-UX Linux Windows] [iSeries]

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.

Modalidad de depuración

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
Argumentos de depuración

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
Argumentos de JVM genéricos

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.

Puede especificar los siguientes argumentos opcionales de línea de mandatos en el campo Argumentos de la JVM genéricos. Si especifica más de un argumento, separe cada argumento con un espacio.
Evite problemas: Si el argumento indica que es únicamente para IBM Developer Kit, no puede utilizar dicho argumento con la JVM de otro proveedor, como la de Microsoft o Hewlett-Packardgotcha
  • [z/OS] [AIX Solaris HP-UX Linux Windows] hotRestartSync:

    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.

  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xquickstart
    Especifique -Xquickstart si desea que la compilación inicial se produzca en un nivel de optimización inferior que en la modalidad por omisión. Posteriormente, dependiendo de los resultados de la prueba, puede volver a compilar al nivel de compilación inicial de la modalidad por omisión.
    Procedimientos recomendados: Utilice -Xquickstart para las aplicaciones en las que es más importante una velocidad moderada inicial que la producción a largo plazo. En algunos escenarios de depuración, cuando se comprueban las herramientas a corto plazo, puede mejorar el proceso de arranque entre un 15 y un 20 por ciento. bprac
    [iSeries] Evite problemas: i5/OS no admite este argumento. gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xverify:none

    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.

    Evite problemas:
    • No utilice este argumento si efectúa modificaciones de bytecode, ya que puede que la JVM sufra una anomalía si se produce un error de instrumentación.
    • Si sufre una anomalía de la JVM o ésta se comporta de una forma imprevista mientras este argumento está en vigor, elimine este argumento como primer paso para depurar el problema de la JVM.
    • [iSeries] i5/OS no admite este argumento.
    gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xnoclassgc

    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.

    [iSeries] Evite problemas: i5/OS no admite este argumento. Debe utilizar -noclassgc para inhabilitar la recogida de basura de clases en esta plataforma. gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xgcthreads

    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.

    Procedimientos recomendados: Debe utilizar la recogida de basura en paralelo si la máquina tiene más de un procesador. bprac
    [iSeries] Evite problemas: i5/OS no admite este argumento. gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xnocompactgc

    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.

    [iSeries] Evite problemas: i5/OS no admite este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xgpolicy

    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.

    [iSeries] Evite problemas: i5/OS no admite este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -XX

    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.

    Los objetos que sobreviven al primer ciclo de recogida de basura se transfieren a otra agrupación. Utilice el parámetro SurvivorRatio para especificar el tamaño de la agrupación superviviente. SurvivorRatio. Puede utilizar las estadísticas de objeto que recoge Tivoli Performance Viewer o incluir el argumento verbose:gc del valor de configuración para supervisar las estadísticas de recogida de basura. Si la recogida de basura se convierte en un cuello de botella, especifique los siguientes argumentos para personalizar los valores de la agrupación de generación de modo que se adapte mejor al entorno.
    -XX:NewSize=límite_inferior
    -XX:MaxNewSize=límite_superior
     -XX:SurvivorRatio=nuevo_tamaño_ratio 
    Procedimientos recomendados: Los valores predeterminados de estos argumentos son: NewSize=2m MaxNewSize=32m SurvivorRatio=2. Sin embargo, si tiene una JVM configurada con un tamaño de almacenamiento dinámico mayor que 1 GB, utilice los valores: -XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16 o defina un 50 o 60 por ciento de tamaño de almacenamiento dinámico total en una agrupación de generación nueva. bprac
    [iSeries] Evite problemas: i5/OS no admite este argumento. gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xminf

    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).

    [iSeries] Evite problemas: i5/OS no admite este argumento. gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -server | -client

    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.

    [iSeries] Evite problemas: i5/OS no admite este argumento.gotcha
  • -Dcom.ibm.CORBA.RequestTimeout=intervalo_tiempo_espera

    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.

  • -Dcom.ibm.websphere.wlm.unusable.interval=intervalo

    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.

  • [z/OS] -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

    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.

    Los almacenamientos intermedios de bytes directos, que crea la JVM para manejar los datos de petición, se asignan en el almacenamiento dinámico de LE (Language Environment) en lugar del almacenamiento dinámico de la JVM. En general, aunque los almacenamientos intermedios de bytes directos ya no sean necesarios, la JVM no libera este almacenamiento nativo de LE hasta que se produzca la siguiente recogida de basura. Si el servidor maneja muchas peticiones, el almacenamiento de LE puede agotarse antes de que JVM ejecute un ciclo de recogida de basura, lo que hará que el servidor finalice de forma anormal (terminación anómala). La configuración de la JVM con el siguiente argumento impide que se produzcan estas terminaciones anómalas.
    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

    [z/OS] 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.

  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xshareclasses:none

    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:
    • [Solaris] [iSeries] [HP-UX] La IBM JVM para J2SE 5 no se admite en Solaris, HP e i5/OS.
    • Las clases de aplicación J2EE que se ejecutan en un proceso de servidor de aplicaciones no se añaden a la memoria caché de la clase compartida.
    gotcha
Tipo de datos Serie
Unidades Argumentos de línea de mandatos de Java
Nombre del archivo JAR ejecutable

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
Inhabilitar JIT

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
Nombre del sistema operativo

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.

Pestaña Tiempo de ejecución

Recogida de basura verbosa

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.

[AIX Solaris HP-UX Linux Windows] 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.

Puede comprobar el informe verboseGC para determinar:
  • Cuánto tiempo emplea la JVM para realizar la recogida de basura.
    Idealmente, es deseable que la JVM dedique menos del 5 por ciento de su tiempo de procesamiento a la recogida de basura. Para determinar el porcentaje de tiempo que dedica la JVM en la recogida de basura, divida el tiempo que tarda en completar la recogida por el tiempo transcurrido desde el último AF y multiplique el resultado por 100. Por ejemplo:
    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.

  • Si el almacenamiento dinámico asignado aumenta con cada ejecución de la recogida de basura.

    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.

[z/OS] 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.

Tareas relacionadas
Referencia relacionada
Colección de propiedades personalizadas
[AIX Solaris HP-UX Linux Windows]


Nombre de fichero: urun_rconfproc_jvm.html