Active Memory never reclaimed please help me understand

[Prem Kumar]

Dear Mulyadi,

Another observation I wanted to add to this:

On some nodes, when the cached memory is high, for example when I look at
the atop output, it showed me about 15G cached. Now when I run a simple
malloc program to grab all available virtual memory and wait for OOM killer
to kill it. To my surprise and obvious in retrospect I see all of my cached
memory is now released and amount of free bumps up closer to the total RAM
excluding the minimal used by the system services, which is what I would
like to see. Now I thought If I use this simple trick it would clear up
similar issues on other machines, but this was not true and the big
difference was in the amount of cached memory. Another big difference
between them are AnonHugePages and AnonPages. On the machine A below
AnonHugePages is about 13.9G(13936640 kB), while on machine B below
AnonHugePages is about 1.5G(1153024 kB). If I run my simple malloc program
to infinitely claim virtual memory on the below two machines: Machine A's
run will fail at 9G and no change on MemFree. And machine B's run will fail
at 1.7TB (1735372 MB). Note the reclaimed space on Machine-B below after a
simple malloc run to glob available virtual memory.

This basically tells me that AnonHugePages limit the amount of RAM
available in the user space. Now I wonder what is using up the AnonPages on
Machine-A and how can I claim that back without a reboot since there is no
other user using the machine? Also is there a way I can peek into what
process has allocated AnonPages so that I can tell if it is/was user
related? Please advise.

-regards!!
Prem


A# free -g
             total       used       free     shared    buffers     cached
Mem:            23         14          8          0          0          0
-/+ buffers/cache:         14          9
Swap:            0          0          0


B# free -g
             total       used       free     shared    buffers     cached
Mem:            23         20          3          0          0         14
-/+ buffers/cache:          5         18
Swap:            0          0          0


MachineB after Malloc-run
$ free -g
             total       used       free     shared    buffers     cached
Mem:            23          2         21          0          0          0
-/+ buffers/cache:          1         21
Swap:            0          0          0


On Wed, Sep 23, 2015 at 11:07 AM, Mulyadi Santosa <mulyadi.santosa at gmail.com
> wrote:

>
>
> On Wed, Sep 23, 2015 at 4:47 AM, Prem Kumar <prem.it.kumar at gmail.com>
> wrote:
>
>> also wondering if there is a way I can list Active memory map showing me
>> what is cached?
>>
>> -regards.
>>
>> On Tue, Sep 22, 2015 at 3:08 PM, Prem Kumar <prem.it.kumar at gmail.com>
>> wrote:
>>
>>> Dear All,
>>>
>>> I have done quite a bit of reading on Active memory reported in
>>> /proc/meminfo and in short says it is never reclaimed unless absolutely
>>> necessary, and it caches the recently used files/pages in memory. Although
>>> I fail to understand the consequences that I face here.
>>>
>>> I have disk-less and swap-less nodes. So all I have to do, is play with
>>> the RAM on the box. Issue that brought me here is investigating why after
>>> running some applications, used memory is never available for use with any
>>> other applications.
>>>
>>> In other words I cannot run any programs that requests memory more than
>>> what is shown as free in the output of free command and MemFree in the
>>> output of the cat /proc/meminfo
>>> For example if I ran any program that requires more than 6GB on the
>>> first node below and more than 1GB on the second node below they fail
>>> instantly, and work fine if within the limist of free. There is nothing
>>> else running on the system other than system processes/services.
>>>
>>>              total       used       free     shared    buffers     cached
>>> Mem:            23         17          6          0          0          9
>>> -/+ buffers/cache:          8         15
>>> Swap:            0          0          0
>>>
>>>              total       used       free     shared    buffers     cached
>>> Mem:            23         22          1          0          0          0
>>> -/+ buffers/cache:         21          1
>>> Swap:            0          0          0
>>>
>>> Since the applications that ran previously are not running any more
>>> "even though they died out of memory because they requested more memory
>>> than available", shouldn't the OS see that any memory used previously as
>>> useless and can it not reclaim that for use with the next job/program on
>>> that machine.
>>>
>>> On every machine that I have run into this problem the out put of
>>> /proc/meminfo shows that Active memory is used up the amount shown in the
>>> free command and limits my further runs.
>>>
>>> This is driving me insane and making me feel stupid knowing that OS is
>>> smart enough to handle this, then what am I missing here to understand?
>>> Please advise.
>>>
>>> Appreciate any insight into this.
>>>
>>> Best Regards,
>>> Prem
>>>
>>>
>>>
>>
>>
>>
> Dear Prem
>
> welcome to kernelnewbies :) First of all, please don't do top posting when
> replying. Follow like what I and the rest of list member do.
>
> Btw, looking from the free output, I have a doubt about your statement
> that your first application took 6 GB and secondly it took 1 GB. Assuming
> your application doesn't thing like memory locking in kernel space, i guess
> it takes 20+ GB of RAM.
>
> So, before we go further, could you re run your applications and use ps or
> top to see both the VSIZE and RSS they take ?
>
> Regarding memory claiming, yes after app is killed (using any ways
> possible: ctrl-c, sending kill/term/quit signal, OOM etc), any memory
> allocated by this task are freed. It happen on both active and inactive
> pages
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150924/30613ab6/attachment.html