Linux – How to reboot the VPS if it says “Cannot allocate memory”

As of GNU coreutils 7.5 released in August 2009, sort allows a -h parameter, which allows numeric suffixes of the kind produced by du -h:

du -hs * | sort -h

If you are using a sort that does not support -h, you can install GNU Coreutils. E.g. on an older Mac OS X:

brew install coreutils
du -hs * | gsort -h

From sort manual:

-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)

A really good reference to read on GC and performance is Oracle's GC Tuning whit

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

In general, the more memory you can allocate to your JVM, the better. The larger you set the young generation (to half or so the total VM size) the better. I've played with JVMs of up to 28 GB in size.

For monitoring, you want to use jconsole (if you're a sysadmin, it's horribly interfaced, instrumented, and limiting, but it's what you've got) and watch in particular your GC activity and total sweeps. This will also give you a sense of what your memory utilization patterns look like. This is a GUI monitor instrumented in Java. You'll need to enable the JMX extensions in your JVM to use it.

For seeing what's actually using memory, the 'jmap' utility will show you both heap size ('jmap -heap ') and an inventory ("histogram") of objects in heap ('jmap -F -histo '). The first usually runs quickly, I've seen the second run for 20-30 minutes, during which the JVM is nonresponsive to other tasks, so this isn't something to use lightly on production instances.

Somewhat counterintuitively, the larger you make your ParNew / young generation, the less often, faster, and more effectively, GC runs. GC works by tracking live objects in heap, and runs as ParNew fills up. With a bigger ParNew, more time elapses, and more objects have expired (died), so GC runs less often, and more of the objects have died. allowing more memory to be GCd. We had a configuration in which ParNew was set absurdly small (~50 MB or so), and bumping it to 1-2 GB dropped GC overhead to about 1-5% of what it had been previously (0.01% - 2% of CPU depending on host/workload now, had been 10-50%).

You'll also want to size PermGen such that you don't run out of space. This is where persistent objects (mostly classes) are kept, and when you run out of space it's usually a Bad Thing.