2012-02-12 24 views
9

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.Uso de memoria del Playframework

El servidor (virtual) tiene alrededor de 750 MB, pero también se ejecuta el servidor MySQL y Apache 12 servidores virtuales. 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 de JVM -Xmx256m, pero ¿qué valor poner y por qué usa tanta memoria?

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

Java: ~~~~~ Versión: 1.6.0_26 Inicio: /usr/lib/jvm/java-6-sun-1.6.0.26/jre memoria Max: 194 641 920 gratuito memoria: 11813896 memoria total: 30588928 procesadores disponibles: 2

Después de reiniciar: Java: ~~~~~ Versión: 1.6.0_26 Inicio: /usr/lib/jvm/java-6-sun-1.6 .0.26/jre Memoria máxima: 194641920 Gratis memoria: 9893688 Memoria total: 21946368 Procesadores disponibles: 2

+0

Es extremadamente difícil responder a esa pregunta. Depende de tantos factores (complejidad, almacenamiento en caché, etc.) - ¡Juega! fomenta un diseño sin estado, por lo que la utilización de la memoria parece un poco alta (aunque no es sorprendente para Java). ¿Intentó reiniciar el servidor y ver si la huella de memoria bajaba? Además, un volcado de memoria puede darle una pista de dónde se asigna esta memoria. –

+0

puede enviar la salida de memoria que el estado de reproducción le da (al comienzo del estado). Por mi parte, estoy ejecutando aplicaciones de reproducción con -Xmx64Mo sin ningún problema. Si necesita más memoria, puede tener alguna pérdida de memoria en su código –

+0

Lo agregaré a la pregunta. Solo 71 MB de los 665 MB actuales se encuentran en la memoria activa (arriba). El 665 parece una figura lo suficientemente estable. ¡Después de una réplica del juego! aplicación (y al menos una solicitud) la memoria reportada por la parte superior es 524m. (ponga el uso de memoria reportado por Play! En la pregunta) –

Respuesta

5

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

El estado de reproducción indica que su montón ocupa solo 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 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.

Trate de limitar su pila a 64Mo pero 750 Mo puede no ser suficiente para ejecutar el jvm y mysql.

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

+0

Lo siento por la reacción lenta, no tuve la oportunidad de configurar una prueba adecuada para ver la diferencia. ¿Cuál es el mejor, o incluso el mismo, comando para ejecutar Play! con -Xmx64M? –

+4

En su archivo application.conf, agregue una línea "jvm.memory = -Xmx64M" –

+0

Hice esto, y esto produjo una caída.Antes del cambio: la memoria Max: 249364480 Memoria libre: 20543688 Memoria total: 59219968 procesadores disponibles: 2 Top da: (Virt) 627m (Res) 185m Después del cambio: memoria Max: 64880640 memoria libre: 2793576 memoria total: 53366784 procesadores disponibles: 2 Top da (suciedad) 470m (res) 199m Así que tomaría el -Xmx64M sea el valor correcto para poner en sin comprometer el marco? No está claro para mí exactamente cuáles son las razones para hacerlo de una forma u otra (¡sé que debería leer!) –

6

Supongo que el 680768 kB de memoria que está informando es de una herramienta de sistema operativo como ps o 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).

debería ejecutar la JVM que ejecuta el playframework con -XX -verbosegc: + PrintGCDetails a ver lo que el GC está haciendo.

Su pregunta "¿Necesita el marco Play que la cantidad de memoria" no se puede responder porque la cantidad de memoria utilizada dependerá de lo que hace la aplicación bajo petición previa. 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é máquina virtual que está utilizando si está utilizando el punto de acceso VM leer la guía de tunning 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.

  • Mark y Barrer recolección de elementos
  • Marcos, barrido y recolección de basura compacto
  • Copia colector
  • Recolección de basura generacional
  • de recolección de elementos
  • Recolección de basura concurrente

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

Un par de herramientas gratuitas que se incluyen con el punto de acceso JVM 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.