jdk - java runtime environment
¿Es bueno establecer el tamaño máximo y mínimo del montón de JVM de la misma manera? (5)
Actualmente, en nuestro entorno de prueba, el tamaño máximo y mínimo de la pila JVM se establece en el mismo valor, básicamente tanto como la máquina del servidor dedicado permitirá nuestra aplicación. ¿Es esta la mejor configuración de rendimiento o le daría un mejor rango a la JVM?
AFAIK, establecer ambos en el mismo tamaño elimina el paso adicional de cambiar el tamaño del montón, lo que podría ser de su agrado si sabe bastante cuánto va a utilizar. Además, tener un tamaño de pila grande reduce las invocaciones de GC hasta el punto de que sucede muy pocas veces. En mi proyecto actual (análisis de riesgo de las operaciones), nuestros motores de riesgo tienen Xmx y Xms al mismo valor que bastante grande (alrededor de 8 Gib). Esto asegura que, incluso después de un día entero de invocar los motores, casi no se produce GC.
También, encontré una discusión interesante here .
Definitivamente yes para una aplicación de servidor. ¿Cuál es el punto de tener tanta memoria pero no usarla? (No, no ahorra electricidad si no usa una celda de memoria)
JVM ama la memoria. Para una aplicación determinada, cuanta más memoria JVM tenga, menos GC realiza. La mejor parte es que más objetos morirán jóvenes y menos la tenencia.
Especialmente durante el inicio de un servidor, la carga es incluso mayor de lo normal. Es una muerte cerebral dar al servidor una pequeña memoria para trabajar en esta etapa.
La razón principal para configurar el -Xms es si necesita un cierto montón en el inicio. (Evita que se produzcan OutOfMemoryErrors en el inicio). Como se mencionó anteriormente, si necesita que el montón de inicio coincida con el máximo, es cuando lo haría. De lo contrario, realmente no lo necesitas. Solo le pide a la aplicación que ocupe más memoria que puede necesitar. Ver su uso de la memoria a lo largo del tiempo (creación de perfiles) mientras realiza pruebas de carga y utiliza su aplicación debería darle una buena idea de lo que necesita configurar. Pero no es lo peor ponerlos en el mismo inicio. Para muchas de nuestras aplicaciones, en realidad empiezo con algo como 128, 256 o 512 para el mínimo (inicio) y un gigabyte para el máximo (esto es para aplicaciones que no son de servidor de aplicaciones).
Acabo de encontrar esta pregunta sobre el desbordamiento de pila, que también puede ser útil side-effect-for-increasing-maxpermsize-and-max-heap-size . Vale la pena mirar.
La respuesta de Peter es correcta, ya que -Xms se asigna al inicio y crecerá hasta -Xmx (tamaño máximo de pila), pero es un poco engañoso en la forma en que ha redactado su respuesta. ( Lo siento Peter, sé que sabes esto frío ).
Al configurar ms == mx se desactiva este comportamiento. Si bien esto solía ser una buena idea en las JVM anteriores , ya no es el caso. Hacer crecer y contraer el montón permite que la JVM se adapte a los aumentos de presión en la memoria y reduzca el tiempo de pausa al reducir el montón cuando se reduce la presión de la memoria. A veces, este comportamiento no le proporciona los beneficios de rendimiento que espera y, en esos casos, es mejor configurar mx == ms . OOME se lanza cuando la pila es más del 98% del tiempo que se invierte en recolectar y las colecciones no pueden recuperar más del 2% de eso. Si no está en el tamaño máximo de montones, entonces la JVM simplemente crecerá para que esté más allá de esos límites. No puede tener un OutOfMemoryError en el inicio a menos que su montón OutOfMemoryError el tamaño máximo del montón y cumpla con las otras condiciones que definen un OutOfMemoryError .
Por los comentarios que han llegado desde que publiqué. No sé qué muestra la entrada del blog de JMonitor, pero es del coleccionista PSYoung .
size_t desired_size = MAX2(MIN2(eden_plus_survivors, gen_size_limit()),
min_gen_size());
Podría investigar más pero apostaría a que encontraría un código que ParNew el mismo propósito en las ParNew y PSOldGen y CMS Tenured . De hecho, es poco probable que CMS pueda devolver memoria a menos que se haya producido un Concurrent Mode Failure . En el caso de un CMF el colector en serie se ejecutará y eso debería incluir una compactación después de la cual la parte superior del montón probablemente esté limpia y, por lo tanto, sea elegible para ser desasignada.
Por lo que veo aquí en http://java-monitor.com/forum/showthread.php?t=427 la JVM bajo prueba comienza con la configuración de Xms, pero desasignará la memoria que no necesita y la llevará hasta La marca Xmx cuando la necesita.
A menos que necesite una porción de memoria dedicada para un gran consumidor de memoria inicialmente, no tiene mucho sentido poner un alto Xms = Xmx. Parece que la desasignación y la asignación se producen incluso con Xms = Xmx