Coding the Architecture - Is VM size an architectural smell?

@James Roper: need to 24GB -> 512MB: isn't this a JVM issue?

Daniel D.C. — Fri, 06 Jul 2012 20:35:00 GMT

>> James said: I once inherited a service that had a "memory leak", and had to be restarted every day. So, I looked at the maximum heap size, it was 24GB. I changed it to 512MB, and the problem went away. The memory leak was that the JVM was never garbage collecting, but rather just increasing its heap size until the OS refused, and then it threw out of memory errors.

To me, this looks more of a JVM design (or coding) issue. Why not subscribe to the OS notification that the memory is low, and do a collection then? Even if low-memory notification is not supported, then do a collection before returning the OOM condition to the app.
There is enough information for the VM to do the right thing, and not require human intervention.

Re: Is VM size an architectural smell?

Kevin Seal — Sat, 30 Jun 2012 09:52:43 GMT

The heap size may be a faint whiff. However, if there's a problem it'll most likely stink the place up in the form of genuine impact to your system's behaviour.

Sensible metric capture, even simple GC logging, will typically show issues fairly readily. They will also continue to demonstrate whether all is well for the lifetime of your software.

A similar smell, in my experience, is setting GC parameters at all (logging aside). A reasonably well designed and written app will typically be pretty amenable to GC ergonomics. YMMV, but I've seen these properties used most often in an attempt to keep a struggling JVM on its feet.

Is VM size an architectural smell?

ArtEze — Thu, 17 May 2012 21:31:52 GMT

No. Is insufficient info.