La configuración de Docker JVM detecta automáticamente la memoria asignada
Imagine que tiene un nodo con 32 GB de RAM y desea utilizar Docker para ejecutar una aplicación Java limitada a 1 GB. Si no se proporciona el parámetro -Xmx, la JVM utilizará su configuración predeterminada:
- La JVM comprobará la memoria total disponible. Debido a que la JVM no conoce el contenedor de Linux (especialmente el grupo de control que limita la memoria), cree que se está ejecutando en el host y tiene acceso a los 32 GB completos de memoria disponible.
- De forma predeterminada, JVM utilizará MaxMemory / 4, en este caso 8GB (32GB / 4).
- A medida que el tamaño del montón crece y supera 1 GB, Docker eliminará el contenedor.
Los primeros en adoptar Docker Java intentaron durante un tiempo comprender por qué su JVM fallaba sin ningún mensaje de error. Para comprender lo que sucedió, debe verificar el contenedor Docker que se eliminó. En este caso, verá un mensaje que dice "OOM fue eliminado" (OutOf Memory).
Por supuesto, una solución obvia es usar el parámetro Xmx para arreglar el tamaño del montón de la JVM, pero esto significa que necesita controlar la memoria dos veces, una en Docker y otra en la JVM. Siempre que desee realizar un cambio, debe hacerlo dos veces. no es ideal.
La primera solución a este problema es usar las versiones lanzadas por Java 8u131 y Java 9. Dije que la solución es porque tienes que usar el querido parámetro -XX: + UnlockExperimentalVMOptions. Si se dedica a los servicios financieros, creo que estará feliz de explicarles a sus clientes oa su jefe que es una decisión acertada.
Luego debe usar -XX: + UseCGroupMemoryLimitForHeap, que le indicará a la JVM que verifique el límite de memoria del grupo de control para establecer el tamaño máximo del montón.
Finalmente, debe usar -XX: MaxRAMFraction para determinar la cantidad máxima de memoria que se puede asignar para la JVM. Desafortunadamente, este parámetro es un número natural. Por ejemplo, si configura el límite de memoria de Docker en 1 GB, tendrá lo siguiente:
-XX: MaxRAMFraction = 1 El tamaño máximo del montón es 1 GB. Esto no es muy bueno, porque no puede darle a la JVM el 100% de la memoria permitida.
-XX: MaxRAMFraction = 2 El tamaño máximo de pila es 500 MB. Eso es mejor, pero ahora parece que desperdiciamos mucha memoria.
-XX: MaxRAMFraction = 3 El tamaño de pila máximo es 250 MB. Está pagando por 1 GB de RAM y su aplicación Java puede utilizar 250 MB. Esto es ridículo
-XX: MaxRAMFraction = 4 es demasiado pequeño.
Básicamente, el indicador de JVM que controla la RAM máxima disponible se establece como una fracción en lugar de un porcentaje, lo que dificulta establecer un valor que pueda usar de manera efectiva la RAM disponible (permitida).
Nos centramos en la memoria, pero lo mismo se aplica a la CPU. Necesitas usar parámetros como este
-Djava.util.concurrent.ForkJoinPool.common.parallelism = 2
Controle el tamaño de los diferentes grupos de subprocesos en la aplicación. 2 significa dos subprocesos (el valor máximo se limitará al número de subprocesos disponibles en el host).
Con todo, con Java 8u131 y Java 9, tendrá una configuración similar:
-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction=2
-Djava.util.concurrent.ForkJoinPool.common.parallelism=2Afortunadamente, Java 10 viene al rescate. En primer lugar, no tiene que usar la bandera de característica experimental aterradora. Si ejecuta una aplicación Java en un contenedor de Linux, la JVM detectará automáticamente el límite de memoria del grupo de control. De lo contrario, solo necesita agregar -XX: -UseContainerSupport.
Luego, puede usar -XX para controlar la memoria: InitialRAMPercentage, -XX: MaxRAMPercentage y -XX: MinRAMPercentage. como
- Límite de memoria de Docker: 1 GB
- -XX: InitialRAMPercentage = 50
- -XX ： MaxRAMPercentage = 70
Su JVM comenzará con un tamaño de pila de 500 MB (50%) y crecerá a 700 MB (70%) con una memoria máxima disponible de 1 GB en el contenedor.