Valores de Java Virtual Machine
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, conecte la consola administrativa y navegue al panel de la máquina virtual Java.
![[z/OS]](../images/ngzos.gif)
Información | Valor |
---|---|
Servidor de aplicaciones | Pulse | . A continuación, en la sección Infraestructura del servidor, pulse .
Gestor de despliegue | Pulse | .A continuación, en la sección Infraestructura del servidor, pulse
Agente de nodo | Pulse | . A continuación, en la sección Infraestructura del servidor, pulse
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Información | Valor |
---|---|
Servidor de aplicaciones | . A continuación, en la sección Infraestructura del servidor, pulse |
Gestor de despliegue | . A continuación, en la sección Infraestructura del servidor, pulse |
Agente de nodo | . A continuación, en la sección Infraestructura del servidor, pulse |
Classpath
Especifica la vía de acceso de clases estándar en la que el código de la máquina virtual Java busca 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.
- Una herramienta de inspección o supervisión para su sistema.
- Archivos JAR para un producto que se ejecuta encima de este producto.
- Parches o arreglos de diagnóstico de JVM.
- Archivos JAR para proveedores de recursos como DB2. Las vías de acceso a estos archivos JAR deben añadirse a las vías de acceso de clases del proveedor correspondiente.
- 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 ampliación. 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 ampliación.
Información | Valor |
---|---|
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 vías de acceso de claves a este campo, para separarlas puede utilizar un carácter de dos puntos (:) o punto y coma (;), en función del sistema operativo en el que resida el nodo.
- Una herramienta de inspección o supervisión para su sistema.
- Archivos JAR para un producto que se ejecuta encima de este producto.
- Parches o arreglos de diagnóstico de JVM.
- Archivos JAR para proveedores de recursos, como DB2. Las vías de acceso a estos archivos JAR deben añadirse a las vías de acceso de clases del proveedor correspondiente.
- 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 ampliación. 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 ampliación.
Carga de clase verbosa
Especifica si se debe utilizar la salida de depuración detallada 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.
Información | Valor |
---|---|
Tipo de datos | Booleano |
Valor predeterminado | false |
Recogida de basura verbosa
Especifica si se debe utilizar la salida de depuración detallada de la recogida de basura. El valor predeterminado es no habilitar la recogida de basura detallada.
Si se habilita la recogida de basura verbosa, la salida de depuración se envía a una de las anotaciones de proceso nativas.
Información | Valor |
---|---|
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 proporcionarle una indicación de cómo funciona el proceso de recogida de basura de Java.
- 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 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, observe 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.
JNI verbosa
Especifica si se debe utilizar la salida de depuración detallada de la invocación de método nativo. El valor predeterminado es no habilitar la actividad de JNI (Java Native Interface) verbosa.
Información | Valor |
---|---|
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 predeterminado.
En z/OS, el tamaño de almacenamiento dinámico inicial predeterminado para el controlador es 256
MB, y el tamaño de almacenamiento dinámico inicial predeterminado para el sirviente es 512 MB.
Para IBM® i
y plataformas distribuidas, el tamaño inicial predeterminado del almacenamiento dinámico 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.
Aumentar el tamaño de 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 transferencia de páginas, se observará una disminución importante en el rendimiento.
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 utilizará el valor predeterminado.
El tamaño máximo de almacenamiento dinámico predeterminado es el 25% de la cantidad total de memoria del sistema hasta 4 GB, o el valor predeterminado de la JVM cuando el tamaño de la memoria es inaccesible.
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 transferencia de páginas, se observará una disminución importante en el rendimiento. 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.
En z/OS, el tamaño máximo de almacenamiento dinámico predeterminado para el controlador es
512
MB, y el tamaño de almacenamiento dinámico inicial predeterminado para el sirviente es 1024 MB. 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.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Ejecutar HProf
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.
Información | Valor |
---|---|
Tipo de datos | Booleano |
Valor predeterminado | false |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Argumentos de HProf
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.
Información | Valor |
---|---|
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 para el argumento de dirección. El argumento de dirección define el puerto que se utiliza para la depuración. Si dos servidores, para los que está habilitada la depuración, se configuran para utilizar el mismo puerto de depuración, los servidores podrían no iniciarse correctamente. Por ejemplo, es posible que ambos servidores estén aún configurados con el argumento de depuración address=7777, que es el valor predeterminado para el argumento de dirección de depuración.
Información | Valor |
---|---|
Tipo de datos | Serie |
Unidades | Argumentos de línea de mandatos Java |
Argumentos de JVM genéricos
Especifica los argumentos de línea de mandatos para pasar al código de la máquina virtual Java que inicia el proceso de servidor de aplicaciones.

-DhotRestartSync:
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 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.
- -Dcom.ibm.crypto.provider.doAESInHardware:
Establezca esta opción en true si desea habilitar la función AES (estándar de cifrado avanzado) que se proporciona con IBM SDK y 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.
-Xquickstart
Especifique -Xquickstart si desea que la compilación inicial se produzca en un nivel de optimización inferior que en la modalidad predeterminada. Posteriormente, dependiendo de los resultados de la prueba, puede volver a compilar al nivel de compilación inicial de la modalidad predeterminada.Best practice: 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
Avoid trouble: IBM i no soporta este argumento. gotcha
-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 dañados, puede que la JVM se comporte de una forma imprevista o que tenga un funcionamiento anómalo.
Avoid trouble:
- 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.
IBM i no admite este argumento.
-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.
Avoid trouble: El impacto de rendimiento de la recogida de basura de clases es normalmente mínimo, y si se desactiva la recogida de basura de clases en un sistema basado en Java Platform, Enterprise Edition (Java EE), con el uso intenso de cargadores de clases de aplicaciones, es posible que se cree realmente una fuga de memoria de datos de clase y 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 que la reclamación de estos recursos causa en el rendimiento.
Si especifica el argumento -Xnoclassgc, siempre que vuelva a desplegar una aplicación, deberá reiniciar siempre el servidor de aplicaciones para borrar las clases y los datos estáticos de la versión anterior de la aplicación.
Avoid trouble: IBM i no admite este argumento. Debe utilizar el argumento -noclassgc para inhabilitar la recogida de basura de clases en esta plataforma.gotcha
-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.
Especifique -Xgcthreads de la manera siguiente:-Xgcthreads<número de procesadores>
Avoid trouble: No añada un espacio entre -Xgcthreads y el valor n para el número de procesadores.
-Xgcthreads5 es un ejemplo de especificación de -Xgcthreads con cinco procesadores.
gotchaBest practice: Debe utilizar la recogida de basura en paralelo si la máquina tiene más de un procesador.bprac
Avoid trouble: IBM i no soporta este argumento. gotcha
-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 de almacenamiento dinámico. Si inhabilita la compactación del almacenamiento dinámico, elimina toda la actividad general asociada.
Avoid trouble: IBM i no admite este argumento.gotcha
-Xgcpolicy
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 supone ningún problema si hay 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 balanced si desea utilizar la recogida de basura de estilo marca, barrido, compactación y generacional. La fase de marca simultánea está inhabilitada; se utiliza la tecnología de recogida de basura simultánea, pero no en la forma en que se implementa la marca simultánea para otras políticas. La política equilibrada utiliza un diseño basado en regiones para el almacenamiento dinámico de Java™. Estas regiones se gestionan individualmente para reducir el tiempo de pausa máximo en almacenamientos dinámicos de gran tamaño y aumentar la eficiencia de la recogida de basura. La política intenta evitar recogidas globales emparejando la asignación de objetos y las tasas de supervivencia. Si tiene problemas con los tiempos de pausa de aplicaciones provocados por recogidas de basura globales, particularmente las compactaciones, esta política puede mejorar el rendimiento de la aplicación. Si está utilizando sistemas grandes que tienen características NUMA (Non-Uniform Memory Architecture) (sólo plataformas x86 y POWER®), la política equilibrada podría mejorar aún más el rendimiento de la aplicación.
Avoid trouble: IBM i no admite este argumento.gotcha
-XX
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 generacional 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 generacional de modo que se adapte mejor al entorno.-XX:NewSize=límite_inferior -XX:MaxNewSize=límite_superior -XX:SurvivorRatio=nuevo_tamaño_ratio
Los valores predeterminados son los siguientes:- NewSize=2m
- MaxNewSize=32m
- SurvivorRatio=32
Best practice: 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
Como alternativa, puede establecer de 50% a 60% del tamaño total de almacenamiento dinámico para una agrupación generacional nueva.
Avoid trouble: IBM i no admite este argumento.gotcha
-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, 0 a 1. El valor predeterminado es .3 (30 por ciento).
Avoid trouble: IBM i no admite este argumento.gotcha
-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 predeterminada, el tiempo de arranque del servidor es más corto y se efectúa un menor uso de memoria. No obstante, esta modalidad reduce el rendimiento a la larga. 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.
Avoid trouble: IBM i no admite este argumento.gotcha
- -Dcom.ibm.CORBA.RequestTimeout=intervalo_tiempo_espera
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 sufre problemas de tiempo de espera. No hay valores recomendados para este argumento.
- -Dcom.ibm.server.allow.sigkill=true
El argumento -Dcom.ibm.server.allow.sigkill=true permite que el proceso del agente de nodo utilice el método terminate de un proceso cuando el método stop no finaliza en el intervalo de tiempo especificado para el intervalo de Ping. Este valor es útil cuando el agente de nodo supervisa un servidor de aplicaciones y pierde contacto con ese servidor de aplicaciones.
Si la política de supervisión del servidor de aplicaciones permite que el agente de nodo reinicie el servidor de aplicaciones debido a que en éste se ha habilitado la opción de reinicio automático, 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 Ping, y este argumento se establece en true, que es el valor predeterminado, el agente de nodo ejecuta el método terminate en el proceso del servidor de aplicaciones para detenerlo.
Si establece este argumento en false, el agente de nodo sigue ejecutándose para supervisar el proceso de detención, pero no intenta reiniciar el servidor de aplicaciones.
Para utilizar la consola administrativa 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.
- -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=
Este argumento especifica el número máximo de veces que una alarma informa de su seguimiento de la pila completa 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.
Nota: Esta propiedad especifica un umbral para cada clase de manejador de alarma, no para el número total de mensajes o para cada instancia del manejador de alarma. - -Dcom.ibm.websphere.native.logging.timestamp=true
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
Nota: Debería especificar -Dws.ext.debug=true solamente en la dirección del personal de soporte de IBM. - -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true
Especifique -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true cuando los repositorios DB/LA del Gestor de miembros virtuales (VMM) se comparten en diferentes instalaciones. Esta propiedad no se puede utilizar en entornos en clúster. Si se establece esta propiedad le permite que VMM sincronice llamadas desde las instalaciones de WebSphere Application Server que comparten repositorios.
-Dcom.ibm.websphere.wlm.unusable.interval=intervalo
Este argumento sólo es aplicable en 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 de 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.
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=
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 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 solicitud, se asignan en el almacenamiento dinámico de LE (Language Environment) en lugar de en el almacenamiento dinámico 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 solicitudes, 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
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.
-DisSipComplianceEnabled=true|false
Especifica si la comprobación de conformidad con SIP está habilitada en el servidor proxy SIP. La comprobación de conformidad SIP garantiza que los mensajes SIP cumplen el estándar Session Initiation Protocol. Cuando se establece esta propiedad en true, se habilita la comprobación de conformidad con SIP.
Avoid trouble: Si va a ejecutar un servidor proxy en un entorno z/OS WebSphere Application Server, Network Deployment, y su 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 de dicho servidor proxy SIP. No obstante, si ejecuta 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 con SIP.gotcha
-Xshareclasses:none
Especifique el argumento -Xshareclasses:none para inhabilitar la opción de compartir clases para un proceso. 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é, llame al programa de utilidad<raíz_servidor_aplic>/bin/clearClassCache.bat o detenga el proceso y, a continuación, reinícielo.
Nota: Cuando se utiliza clearClassCache, debe detener todas las máquinas virtuales Java asociadas para borrar la memoria caché completa.Avoid trouble:
- 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.
- -XXallowvmshutdown:false
Utilice el argumento -XXallowvmshutdown:false para volver a un comportamiento anterior de la JVM cuyo comportamiento actual no es correcto. 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.
Información | Valor |
---|---|
Tipo de datos | Serie |
Unidades | Argumentos de línea de mandatos 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.
Información | Valor |
---|---|
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.
Información | Valor |
---|---|
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 nodo como los valores de la JVM del sistema operativo.