Re: VM - a plenty of inactive memory

["Andreas Grimm" <agrimm61@gmail.com>]

Hi everybody,

i investigated this further. The tunables swappiness, drop_caches etc.
are no options to solve this. The problem is becoming very unpleasent,
because the system isn't able to cache that much:

The 16GB system (expected behaviour):
MemTotal:     16619808 kB
MemFree:       4490032 kB
Cached:        6929448 kB
Inactive:      1670812 kB

The 32GB system :
MemTotal:     33265916 kB
MemFree:        600000 kB
Cached:        1561124 kB
Inactive:     25873128 kB

Don't you think this is insane? Wasting 25GB at the expense of caching
(compare the cached value)? I'm clueless about this issue. Who (which
process) owns that memory? Is there a way to flush this inactive
memory? I assume that this memory hasn't been reclaimed for days,
because the amount of inactive memory is at this level for days now.

All values in /proc/sys/vm are at the defaults again, on both systems.

Any help would be appreciated.

Andreas

2008/4/9, Johannes Weiner <hannes@saeurebad.de>:
> Hi,
>
>
>  "Andreas Grimm" <agrimm61@gmail.com> writes:
>
>  > Hello everybody,
>  >
>  > i got a weird problem with one of my servers. It's a Intel SR2500AL
>  > with 32GB of RAM.
>  > Looking at the memory usage of the system, something is going totally
>  > wrong. The crucial numbers from /proc/meminfo are:
>  >
>  > MemTotal: 33265916 kB
>  > MemFree: 416168 kB
>  > Inactive: 24630428 kB (24GB? whooaaa)
>  >
>  > Another system with only 16GB, same amount of users and load, shows a
>  > more normal behaviour:
>  >
>  > MemTotal: 16619808 kB
>  > MemFree: 6912676 kB
>  > Inactive: 1774364 kB
>  >
>  > Why does the 32GB-System have this plenty of inactive memory. Is there
>  > a way to find out, what the kernel is holding in readiness (that's the
>  > definition of inactive memory afaik)?
>
>
> Inactive pages are marked in use but haven't been touched for some time.
>  These are candidates for memory reclaiming.
>
>  If nothing memory consuming happens, the kswapd should reclaim them back
>  eventually.
>
>         Hannes
>