¿Se ralentiza la JVM de Sun cuando se asigna más memoria a través de -Xmx?

Question

¿Se ralentiza la JVM de Sun cuando hay más memoria disponible y se usa a través de -Xmx?

Lo pregunto porque mis servidores de producción han de recibir una actualización de memoria: (Supuesto La máquina tiene suficiente memoria física para que el intercambio de memoria virtual no es un problema.). Me gustaría subir el valor de -Xmx a algo decadente. La idea es evitar cualquier falla de agotamiento del espacio de montón debido a mis propios errores de programación que ocurren de vez en cuando. Eventos raros, pero se podrían evitar con mi aplicación web de rápida evolución si tuviera un valor de Xmx obsceno, como 2048 mb o más. La aplicación se monitorea en gran medida, por lo que se notarían picos inusuales en el consumo de memoria JVM y se corregirían los defectos.

posibles detalles importantes:

• Java 6 (Runnign en el modo de 64 bits)
• 4-core Xeon
• RHEL4 64 bits
• Spring, Hibernate
• alta disco y red IO

EDIT: Intenté evitar publicar la configuración de mi JVM, pero claramente eso hace que la pregunta sea ridículamente abierta. Por lo tanto, aquí vamos con los parámetros de configuración relevantes:

-Xms256m 
-Xmx1024m 
-XX:+UseConcMarkSweepGC 
-XX:+AlwaysActAsServerClassMachine 
-XX:MaxGCPauseMillis=1000 
-XX:MaxGCMinorPauseMillis=1000 
-XX:+PrintGCTimeStamps 
-XX:+HeapDumpOnOutOfMemoryError 

Answer 1

Mediante la adición de más memoria, se necesitará más tiempo para el montón a llenarse. En consecuencia, reducirá la frecuencia de las recolecciones de basura. Sin embargo, dependiendo de cuán mortales sean sus objetos, es posible que aumente el tiempo necesario para hacer cualquier GC.

El factor principal de cuánto tiempo tarda un GC es en cuántos viven los objetos que hay. Por lo tanto, si virtualmente todos sus objetos mueren jóvenes y una vez que se establezca, ninguno de ellos escapará del joven montón, es posible que no note mucho cambio en el tiempo que lleva hacer un GC.Sin embargo, cada vez que tenga que hacer un ciclo del montón permanente, puede encontrar que todo se detiene durante un período de tiempo irrazonable, ya que la mayoría de estos objetos seguirán existiendo. Sintonice los tamaños en consecuencia.

Answer 2

más memoria por lo general le da un mejor rendimiento en entornos de recogida de basura, por lo menos, siempre y cuando esto no conduce a virtual uso de la memoria/el intercambio.

El GC solo rastrea las referencias, no la memoria per se. Al final, la máquina virtual asignará el mismo número de objetos (en su mayoría efímeros, temporales), pero el recolector de basura debe invocarse con menos frecuencia: la cantidad total de trabajo del recolector de basura no será mayor, incluso menos, ya que esto también puede ayudar con los mecanismos de caché que usan referencias débiles.

no estoy seguro de si todavía hay un servidor y un cliente VM de 64 bits (no es de 32 bits), por lo que puede que desee investigar eso también.

Answer 3

Si solo tira más memoria al problema, tendrá un mejor rendimiento en su aplicación, pero su capacidad de respuesta puede disminuir si no está en un sistema multinúcleo que utiliza el recolector de basura CMS. Esto se debe a que se producirán menos GC, pero tendrán más trabajo por hacer. Lo bueno es que obtendrá más memoria liberada con sus GC, por lo que la asignación seguirá siendo muy económica, por lo tanto, la mayor capacidad de almacenamiento.

usted parece estar confundiendo -Xmx y -Xms, por cierto. -Xms solo establece el tamaño del montón inicial, mientras que -Xmx es tu tamaño máximo de almacenamiento dinámico.

Answer 4

De acuerdo con mi experiencia, no se ralentiza, PERO la JVM intenta cortar a Xms todo el tiempo y tratar de permanecer en el límite inferior o cerca de. Entonces, si puedes esforzarte, golpea a Xms también. Sun recomienda ambos al mismo tamaño. Agregue un poco de -XX: NewSize = 512m (solo un número inventado) para evitar el costoso montón de datos antiguos en la generación anterior con cables que conducen a GC más largos/más pesados ​​en el camino. Estamos ejecutando nuestra aplicación web con 700 MB NewSize porque la mayoría de los datos son de corta duración.

Por lo tanto, línea de fondo: no espero una desaceleración, pero ponga su mayor cantidad de memoria a trabajar. Establezca un área de tamaño nuevo más grande y configure Xms en Xmx para reducir el estrés en el GC, ya que no es necesario intentar reducir los límites de Xms ...

Answer 5

Por lo general, no ayudará a su rendimiento/rendimiento, si usted aumenta -Xmx. En teoría, podría haber fases más largas de "detener el mundo", pero en la práctica con el CMS eso no es un problema real.

Por supuesto que no debe asignar un valor a -Xmx loco como 300Gbyte a menos que realmente lo necesite :)