Re: top and allocation issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 3/3/2011 2:26 PM, Michael D. Berger wrote:
> On Thu, 03 Mar 2011 15:03:34 -0500, Stephen Harris wrote:
>
>
>>
>> /proc/sys/vm/overcommit_memory
>> (or sysctl vm.overcommit_memory)
>>
>> > From the kernel Documentation:
>>
>> This value contains a flag that enables memory overcommitment.
>>
>> When this flag is 0, the kernel attempts to estimate the amount of free
>> memory left when userspace requests more memory.
>>
>> When this flag is 1, the kernel pretends there is always enough memory
>> until it actually runs out.
>>
>> When this flag is 2, the kernel uses a "never overcommit" policy that
>> attempts to prevent any overcommit of memory.
>>
>> This feature can be very useful because there are a lot of programs that
>> malloc() huge amounts of memory "just-in-case" and don't use much of it.
>>
>> The default value is 0.
>>
>
> I just wrote a sequence of values (kk % 256) and (after changing
> to unsigned char) read back successfully.  I did see some action
> in top.
>
> Now given my numbers, it would seem that I am "overcommitted".
> Leaving the flag you mention at 0 (which it is), do I run a
> risk of a later failure?

Since there are other processes running, each one usually don't know how 
overcommitted the system is - or might be soon (what if several copies 
of this program are running?).  And it's all virtual so you aren't 
really out of memory until you are out of swap.  Then the kernel will 
kill something at random.

-- 
   Les Mikesell
    lesmikesell@xxxxxxxxx


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux