In the interests of completeness, I pulled out 2.1.4 out and installed 2.0.6.
Ran the same 2 guests, and the memory usage is indeed a good bit less - the 180 Meg is back under 100 Meg The other is hovering around that mark.

Seems you were just unlucky, and fell over the edge.

Well the "big" ls at 01:15 am actually seems to free memory... I really have to spend a few hours|days|years on reading about Linux memory manegement to understand this...

BTW, no VirtualBox VM was running during the period the graph shows.

Attached Thumbnails

 

Did this ever get resolved to your satisfaction?

I am having the same issue. The VM is lightly loaded, but the filesystem caching takes everything available and doesn't do a good job it seems of giving that back when it needs to.

The chaining effect is that all of my services end up being killed due to being OOM. Since the whole point of having the VM is to run those services... it is just not workable.

I am using VB 2.2.0 (personal use binary edition).

Well, not really. But I've kind of learnt to live with it.... The strange thing is that I can have at least two guests running for a week with no problems. But if I have one single guest that is paused over night, OOM-killer almost always kills the guest.

I have absolutely no idea why but it seems like having the guest paused somehow triggers the OOM-killer for me.

For mine, one thing I've noticed is that there is a lot of memory used up just by caching files. I know that it is designed to do that, then will give that memory back as other programs need it. But that isn't happening properly.

If I do a watch free -m I can watch the free meg disappear if I do something file intensive. If I look at the actual memory consumed by programs it is very low, but either file caching (or maybe something related to the dynamic code recompiling that the VM does for some operations) just keeps eating up memory that never gets reclaimed.

I've increased the total memory to my guest which just seems to postpone the problem. I guess I'm just living with this (I don't do any pausing so that is news to me).

The root problem is your device driver does not recycle memory enough so that the free memory falls below min_free_kbytes. No more memory is available to the driver and OOM killer kicks in.

A good written driver should work on both 32 or 64 bit platform. Running on 64 bit so that you have more memory to work on (from 1G to 8G in your case) just defers the problem. If you want a real fix you should continue working on 32 bit platform. Running on 64 bit may bypass the problem because the driver may decide to free up memory before you hit the same condition (LowFree < min_free_kbytes) again.

1) The driver should not exhaust free memory below min_free_kbytes. VM won't allocate more memory to the driver when free memory drops below min_free_kbytes(16384 KB in your case). The driver should regularly reclaims memory before allocating memory. For example calling balance_dirty_pages_ratelimited() or set_shrinker(). Your driver probably alloc_pages()/kmem_cache_get() too much memory without freeing it. Otherwise you are going to hit the same problem regardless how much memory the machine has and 32 or 64 bit platform you are running.


2) Consider use of Highmem and PAE(7G+ memory above 860M in your system) to access the rest of 7G memory. These 7G+ memory only maps to around 100M of linear space. Making use of highmem may or may not help your situation because there is only 100M linear space available. A good written driver works just fine without using highmem. But why waste these extra 7G+ memory. This is just a minor issue.


vm.min_free_kbytes = 16384

MemTotal: 8311768 kB <--- total 8G
MemFree: 5831424 kB

LowTotal: 841240 kB <--- 840M on low memory
LowFree: 12072 kB <--- page_alloc() is blocked when it's below min_free_kbytes(16384 KB)
oom killer kicks in here to get LowFree back to 16384.