java - Uso de memoria del Playframework

memory jvm

Question

Solo una pregunta rápida sobre el uso de memoria del marco de juego. Tengo una instancia de producción, que parece usar 680768 kB de memoria. La mayor parte se encuentra en el intercambio.

El servidor (virtual) tiene alrededor de 750 MB, pero también ejecuta el servidor MySQL y 12 servidores virtuales Apache. Algunas veces se convierte en unresponsible temporal (o muy lento) por períodos cortos. Supongo que es por el intercambio (no es la CPU).

¿El marco necesita tanta memoria? Podría limitar el uso de la memoria con un parámetro JVM -Xmx256m o menos, pero ¿qué valor poner, y cuál es la razón por la que usa tanta memoria?

Este es el uso de Play! antes y después del comienzo:

Java: ~~~~~ Versión: 1.6.0_26 Inicio: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Memoria máxima: 194641920 Memoria libre: 11813896 Memoria total: 30588928 Procesadores disponibles: 2

Después del reinicio: Java: ~~~~~ Versión: 1.6.0_26 Inicio: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Memoria máxima: 194641920 Memoria libre: 9893688 Memoria total: 21946368 Procesadores disponibles: 2

Answer 1

Supongo que el 680768 kB de memoria que está informando proviene de una herramienta del sistema operativo como ps o el administrador de tareas. La cantidad total de memoria utilizada por la JVM no está causando la congelación temporal de la aplicación. La causa probable de la pausa es que el recopilador JVM Garbage está ejecutando un GC completo que suspenderá todos los subprocesos en la JVM que ejecuta el GC completo (a menos que tenga un gc concurrente configurado).

Debe ejecutar la JVM que ejecuta el marco de reproducción con -verbosegc -XX: + PrintGCDetails para ver qué hace el GC.

Su pregunta "¿Play Framework necesita tanta memoria?" No se puede responder porque la cantidad de memoria utilizada dependerá de lo que esté haciendo su aplicación previa solicitud. Además, la JVM permitirá que se ejecute el montón y luego realice un ciclo de GC para limpiar el Heap. Una aplicación JVM con buena conducta debería mostrar un patrón de diente de sierra en el gráfico de GC.

No sé qué JVM está utilizando si está utilizando la VM de hotspot lea la guía de ajuste de JVM. http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Por lo general, debe comprender los siguientes conceptos de GC antes de leer la guía de ajuste de JVM para que la guía tenga sentido.

• Marcar y barrer la recolección de basura
• Marque, barra y compacte la recolección de basura
• Copiar coleccionista
• Colección Generational Garbage
• Colección de basura paralela
• Recolección concurrente de basura

http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ es probablemente un buen libro sobre este tema

Un par de herramientas gratuitas que se entregan con la JVM de hotspot que puede usar incluyen jconsole y jvisualvm. jvisualvm tiene un buen plugin llamado VisualGC que es excelente para aprender cómo el hotspot vm administra la memoria.

Answer 2

Depende de muchas cosas, pero sí, java necesita algo de memoria para la asignación nativa, el montón y el espacio de la memoria no montón.

El estado de reproducción indica que tu montón solo consume 30588928 bytes, pero al inicio java asigna 194641920 para el montón. Puede intentar comenzar con -Xmx64M para limitar la asignación del montón.

Puede guardar aproximadamente 128 Mo de RAM pero, java también asigna memoria para el jvm, por lo que la huella del proceso será más de 64 Mo, depende de su plataforma, pero será de al menos 200/250 Mo.

Intenta limitar tu montón a 64Mo pero 750 Mo puede no ser suficiente para ejecutar jvm y mysql.

Tenga en cuenta que no debe usar swap con java porque la memoria está asignada en un bloque, por lo que puede intercambiar / intercambiar todo el montón.