On Sat, Aug 1, 2009 at 4:08 PM, Dan Borlovan<[email protected]> wrote: > Catalin Muresan wrote: > >> ce e in fisierele astea? >> >> /proc/sys/vm/overcommit_memory >> /proc/sys/vm/overcommit_ratio > > N-ai avut curaj sa-l intrebi pe gogu? > > Going in the wrong direction > > Since 2.1.27 there are a sysctl VM_OVERCOMMIT_MEMORY and proc file > /proc/sys/vm/overcommit_memory with values 1: do overcommit, and 0 > (default): don't. Unfortunately, this does not allow you to tell the kernel > to be more careful, it only allows you to tell the kernel to be less > careful. With overcommit_memory set to 1 every malloc() will succeed. When > set to 0 the old heuristics are used, the kernel still overcommits. > > Going in the right direction > > Since 2.5.30 the values are: 0 (default): as before: guess about how much > overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise > about the overcommit - never commit a virtual address space larger than swap > space plus a fraction overcommit_ratio of the physical memory. Here > /proc/sys/vm/overcommit_ratio (by default 50) is another user-settable > parameter. It is possible to set overcommit_ratio to values larger than 100. > (See also Documentation/vm/overcommit-accounting.)
Ce ma interesa in mesajul meu este nu sa dezactivez overcommitul ci sa inteleg de ce mecanismul oom-killer intra in actiune desi swap-ul nu este utilizat deloc. Singura chesti care ar putea interfera ar fi driverul de ballooning (vmmemctl) din vmware tools. Masina unde am problem este un VMware ESX. Iar memoria este overcommitted. Cred ca am gasit ce cautam: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003586 > > -- > Dan Borlovan > Datagroup Int > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
