Memory usage of the Playframework

Question

Just a quick question on the memory usage of the play framework. I have a production instance, which appears to use 680768 kB of memory. Most of it is located in the swap.

The (virtual) server has about 750 MB, but also runs the MySQL server and 12 Apache virtual servers. Sometimes becomes temporary unrespondent (or very slow) for short periods. I guess it is because of the swapping (it is not the CPU).

Does the framework need that much memory? I could limit the memory usage with a JVM parameter -Xmx256m or so, but what value to put in, and what is the reason it uses so much memory?

This is the usage by Play! before and after start:

Java: ~~~~~ Version: 1.6.0_26 Home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Max memory: 194641920 Free memory: 11813896 Total memory: 30588928 Available processors: 2

After restart: Java: ~~~~~ Version: 1.6.0_26 Home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Max memory: 194641920 Free memory: 9893688 Total memory: 21946368 Available processors: 2

Solution 1

It depends on a lot of things but yes java need some memory for native allocation, the heap and the non heap memory space.

Play status says that your heap consumes only 30588928 bytes but at startup java allocates 194641920 for the heap. You can try to start with -Xmx64M to limit heap allocation.

You can then save about 128 Mo of RAM but, java also allocates memory for the jvm, so the footprint of the process will be more than 64 Mo, it depends on your platform but it will be at least 200/250 Mo.

Try with limiting your heap to 64Mo but 750 Mo may not be enough to run the jvm and mysql.

Have in mind that you must not use swap with java because memory is allocated in one block so you swap in/swap out the entire heap.

Solution 2

I am assuming that the 680768 kB of memory that you are reporting is from an OS tool like ps or task manager. The total amount of memory used by the JVM is not causing the temporary freezing of the app. The likely cause of the pause is that the JVM Garbage collector is running a full GC which will suspend all threads in the JVM which the full GC is running (unless you have a concurrent gc configured).

You should run the JVM running the playframework with -verbosegc -XX:+PrintGCDetails to see what the GC is doing.

Your question "Does the Play Framework need that much memory" can not be answered because the amount of memory used will depend on what your application is doing on a pre request basis. Also the JVM will let the heap run down and then do a GC cycle to clean up the Heap. A well behaved JVM app should show a saw tooth pattern on the GC graph.

I don't know which JVM you are using if you are using the hotspot VM read the JVM tunning guide. http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html You generally need to understand the following GC concepts before reading the JVM tuning guide for the guide to make sense.

• Mark and Sweep Garbage Collection
• Mark, Sweep and Compact Garbage Collection
• Copy collector
• Generational Garbage Collection
• Parallel Garbage Collection
• Concurrent Garbage Collection

http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ is probably a good book on this subject

A couple of free tools that ship with the hotspot JVM that you can use include jconsole, and jvisualvm. jvisualvm has a nice plugin called VisualGC which is great at learning how the hotspot vm manages memory.

Comments

[Luuk D. Jansen]

Sorry for the slow reaction, I didn't get a chance to setup a proper test to look at the difference. What is the best, or even just way, command to run Play! with -Xmx64M?

[Seb Cesbron]

In your application.conf file, add a line "jvm.memory=-Xmx64M"

[Luuk D. Jansen]

I did this, and this saw a drop. Before the change: Max memory: 249364480 Free memory: 20543688 Total memory: 59219968 Available processors: 2 Top gives: (Virt) 627m (Res) 185m After the change: Max memory: 64880640 Free memory: 2793576 Total memory: 53366784 Available processors: 2 Top gives (dirt) 470m (res) 199m So would take the -Xmx64M be the right value to put in without compromising the framework? It is a bit unclear to me exactly what the reasons are to do it one way or the other (I know I should read up!)

[Isvara]

"memory is allocated in one block so you swap in/swap out the entire heap" -- That's not true, is it? VM swaps pages in and out. I don't think the OS cares or even knows that the process's memory is one big heap. It just knows that it called brk to get some more pages.