When I get back, my hosting company have wasted all my hard work! How have they done this – by offering me a free* upgrade from 512Mb of RAM to 1024Mb. I now have oodles of capacity meaning that

• my various websites zip along really rather speedily at the moment – there’s little to no current swap file usage
• I’m going to have to spend time installing / writing more software to use the available capacity (assuming current traffic levels don’t suddenly change )

Here’s the current memory usage to compare with the screen grabs in the previous post.

Memory usage

To say that I am chuffed with this update from the hosting provider is an understatement. In recent months they have

• doubled the RAM available in the plan
• increased the available disk space
• moved to newer hardware with recent CPUs

And the price has remained the same*. Which would all be so-so if the level of service hadn’t continued to be excellent!

So, if you are looking for good VPS supplier, I’d suggest you include Linode in the list that you look at. I have no connection with Linode other than being that rare thing – a satisfied customer!

* the upgrade for doubling your RAM actually costs an extra 5 cents but you can stay on your old plan at the previous price…

Just because it is ickle in size, doesn’t mean that I don’t want to run several different frameworks! There’s a couple of Java JVMs (one for a Play framework app and one for a Tomcat app), a MySQL database and an Apache web server with several PHP apps (a restored backup of  a Joomla site, this WordPress bloggy thing and a tiddly PHP development).

The Apache / PHP and MySQL were tuned for a small deployment – there are several good guides for this. None of the applications gets that much traffic so I’m happy to trade throughput for considerate resource usage.

Java is, of course, quite a memory hog by comparison with some frameworks and running two JVM is perhaps a little ambitious for a small VPS. However, all was fine for quite a while until a combination of adding yet more running software and peaky traffic from a badly behaved crawler started problems. Every Friday morning, I started getting notifications from the server monitoring tools about high CPU levels. This was something of a surprise as, while there might be a lot of software, none of it actually does very much!

However, after a little digging, something called kswapd0 seemed to be the culprit. When Google told me that this is involved in managing swap space the reason for the problem became clearer (even if the reason for kswapd0 to continue to fret when there was no traffic was not).

Of the two JVMs on the VPS, the one running the Play application was using a lot more memory than the Tomcat one. Sure – the Play app creates a few more objects than the Tomcat one and loads a few more libraries so the heap and permgen it requires was expected to be a little higher than the Tomcat JVM. Still – I thought there was room for a little tweaking to claw back some available memory.

As a first guess at the maximum required heap space and permgen I added
-Xmx128m -XX:MaxPermSize=60m
to the JVM startup. However, as far as I could tell, this made no difference to actual memory usage

I’d added the above JVM settings through the Play 1.2.x application.conf setting of
%<play_instance_id>.jvm.memory=-XX:MaxPermSize=60m -Xmx128m
but the Java command line also included a -server parameter. This seemed logical given that I was running Play in production mode but I had to admit I had no real idea what this setting actually affected.

Stackoverflow seemed to point at a less capacious memory usage in -client mode so I decided to give it a go. Some Oracle docs said when -server will be assumed and gave very brief details of the -client versus -server trade off .

The question then became one of how to control the -server setting. I couldn’t find any way to change this through Play configuration so eventually edited <PLAY_HOME>/framework/pym/play/application.py

application_mode = self.read('application.mode').lower()

#if application_mode == 'prod':
#    java_args.append('-server')

While this seems less than ideal, it seemed to work in terms of the JVM start up args (and I learnt that Python is sensitive to indentation levels ). Does anyone know a better way of controlling this?

So did it all do any good? Well – here a couple of htop snapshots (the Tomcat JVM is the 2nd line in each output). The first is with -server after a few calls to the various apps. The second is without -server a few calls to the apps. It seems as though it is making quite a difference. The Play application’s appetite for memory now seems quite similar to the Tomcat one.

JVM with -server

JVM -client

Of course, only time will tell if this makes a real difference when the applications have been running for while. On the plus side, my VPS didn’t go into a swap driven melt down this Friday morning!

If anyone knows how to control the Play 1.2.x framework’s setting of -server in production mode without tweaking the framework code please do let me know.