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 at gmail.com