jdk - java virtual machine descargar
¿Los distintivos-Xms y-Xms reservan los recursos de la máquina? (3)
Sé que el indicador -Xms del proceso JVM es permitir que el proceso JVM use una cantidad específica de memoria para inicializar su proceso. Y en lo que respecta al rendimiento de una aplicación Java, a menudo se recomienda establecer los mismos valores para ambos -Xms y -Xmx al iniciar la aplicación, como -Xms2048M -Xmx2048M .
Tengo curiosidad por saber si los -Xms y -Xmx significan que el proceso JVM hace una reserva para la cantidad específica de memoria para evitar que otros procesos en la misma máquina la utilicen.
¿Es esto correcto?
¿El proceso de JVM hace una reserva para la cantidad específica de memoria?
Sí, la JVM reserva la memoria especificada por Xms al comienzo y puede reservar hasta Xmx pero la reserva no necesita estar en la memoria física, sino que también puede estar en el intercambio. Las páginas JVM se intercambiarán dentro y fuera de memoria según sea necesario.
¿Por qué se recomienda tener el mismo valor para Xms y Xmx?
Nota: El ajuste de Xms y Xmx generalmente se recomienda para sistemas de producción donde las máquinas están dedicadas a una sola aplicación (o no hay muchas aplicaciones que compitan por los recursos del sistema). Esto no generaliza, es bueno en todas partes.
Evita el tamaño del montón:
La JVM comienza con el tamaño de Xms dinámico especificado inicialmente por el valor de Xms . Cuando el montón se agota debido a la asignación de objetos por la aplicación. La JVM comienza a aumentar el montón. Cada vez que la JVM aumenta el tamaño del almacenamiento dinámico, debe solicitar al sistema operativo más memoria. Esta es una operación que consume mucho tiempo y da como resultado un aumento en los tiempos de pausa de cc e introduce los tiempos de respuesta para las solicitudes.
Comportamiento de las aplicaciones a largo plazo:
Aunque no puedo generalizar, muchas aplicaciones a largo plazo eventualmente crecen hasta el valor máximo de almacenamiento dinámico. Esta es otra razón para comenzar con la memoria máxima en lugar de aumentar el montón con el tiempo y crear una sobrecarga innecesaria de cambio de tamaño del montón. Es como pedirle a la aplicación que tome la memoria al comienzo mismo, lo que finalmente tomará.
Cantidad de GC :
Comenzar con tamaños pequeños de montón resulta en la recolección de basura con más frecuencia. Los tamaños de montón más grandes reducen la cantidad de gcs que se producen porque hay más memoria disponible para la asignación de objetos. Sin embargo, debe tenerse en cuenta que el aumento de los tamaños de almacenamiento aumenta los tiempos de pausa de gc. Esta es una ventaja solo si su recolección de basura se ha ajustado correctamente y los tiempos de pausa no aumentan significativamente con el aumento en los tamaños de almacenamiento dinámico.
Una razón más para hacer esto es que los servidores generalmente vienen con grandes cantidades de memoria. ¿Por qué no utilizar los recursos disponibles?
Xmx simplemente reserva espacio de direcciones virtuales. Xms realmente lo asigna (confirma) pero no necesariamente lo predetermina.
Cómo los sistemas operativos responden a las asignaciones varía.
Windows le permite reservar grandes porciones de espacio de direcciones (Xmx) pero no permitirá overcommit (Xms). El límite está definido por swap + físico. La excepción son las páginas grandes (que deben habilitarse con una configuración de directiva de grupo), que lo limitará mediante un ram físico.
El comportamiento de Linux es más complicado, depende de la vm.overcommit_memory y de los sysctls relacionados y de varios indicadores pasados a mmap syscall, que hasta cierto punto pueden controlarse mediante los indicadores de configuración de JVM. El comportamiento puede variar desde a) Xms puede exceder el total de ram + swap hasta b) Xmx está limitado por el ram físico disponible.
Respuesta corta: depende del sistema operativo, aunque definitivamente es un NO en todos los sistemas operativos populares.
Tomaré el ejemplo de la terminología de asignación de memoria de Linux aquí.
-Xms y -Xmx especifican el tamaño mínimo y máximo del montón de JVM. Estos tamaños reflejan las asignaciones de VIRTUAL MEMORY que pueden mapearse físicamente en páginas en RAM denominadas RESIDENT SIZE del proceso en cualquier momento.
Cuando se inicie JVM, asignará la cantidad de memoria virtual de Xms. Esto se puede asignar a la memoria residente (memoria física) una vez que se crean dinámicamente más objetos en el montón. Esta operación no requerirá que JVM solicite ninguna nueva asignación del sistema operativo, pero aumentará su utilización de memoria RAM, porque esas páginas virtuales ahora también tendrán la asignación de memoria física correspondiente. Sin embargo, una vez que su proceso intenta crear más objetos en el montón después de consumir toda su asignación de Xms en la RAM, tiene que solicitar el sistema operativo para más memoria virtual del sistema operativo, que puede / no puede mapearse también a la memoria física más tarde dependiendo de cuándo lo necesita. El límite para esto es su asignación de -Xmx.
Tenga en cuenta que todo esto es posible porque la memoria en Linux está compartida. Por lo tanto, incluso si un proceso asigna memoria de antemano, lo que obtiene es memoria virtual que es solo una asignación de ficción contigua contigua que puede o no asignarse a páginas físicas reales en función de la demanda. Lea esta respuesta para obtener una breve descripción de cómo funciona la administración de memoria en los sistemas operativos populares. Aquí hay una información muy detallada (algo desactualizada pero muy útil) sobre cómo funciona la administración de memoria de Linux.
También tenga en cuenta que estos indicadores solo afectan los tamaños de almacenamiento dinámico. El tamaño de la memoria residente que verá será mayor que el tamaño del almacenamiento dinámico de JVM actual. Más específicamente, la memoria consumida por una JVM es igual a su HEAP SIZE más DIRECT MEMORY que refleja las cosas provenientes de las pilas de métodos, asignaciones de buffer nativas, etc.