Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vm.overcommit_memory=2 is the right setting for servers

ariadne.space

Post reply on HN
Print view View original

51–60 of 150 posts

Re: Vm.overcommit_memory=2 is the right setting for servers

#51

Post by nickelpro »

loeg wrote: post #29
jcalvinowens wrote: post #28

Earlier quoted context omitted.

Because userspace rarely actually faults in all the pages it allocates.

Surely the source of the waste here is the userspace program not using the memory it allocated, rather than whether or not the kernel overcommits memory. Attributing this to overcommit behavior is invalid.

Reading COW memory doesn't cause a fault. It doesn't mean unused literally.

And even if it's not COW, there's nothing wrong or inefficient about opportunistically allocating pages ahead of time to avoid syscall latency. Or mmapping files and deciding halfway through you don't need the whole thing.

There are plenty of reasons overcommit is the default.

Re: Vm.overcommit_memory=2 is the right setting for servers

#52

Post by otabdeveloper4 »

EdiX wrote: post #48

This is completely wrong. First, disabling overcommit is wasteful because of fork and because of the way thread stacks are allocated. Sorry, you don't get exact memory accounting with C, not even Windows will do exact accounting of thread stacks. Secondly, memory is a global resource so you don't get local failures when it's exhausted, whoever allocates first after memory has been exhausted will get an error they mig…

> because of fork and because of the way thread stacks are allocated

For modern (post-x86_64) memory allocators a common strategy is to allocate hundreds of gigabytes of virtual memory and let the kernel handle deal with actually swapping in physical memory pages upon use.

This way you can partition the virtual memory space into arenas as you like. This works really well.

Re: Vm.overcommit_memory=2 is the right setting for servers

#53

Post by LordGrey »

sidewndr46 wrote: post #45
LordGrey wrote: post #3

For anyone not familiar with the meaning of '2' in this context: The Linux kernel supports the following overcommit handling modes 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.…

Do any of the settings actually result in "malloc" or a similar function returning NULL?

malloc() and friends may always return NULL. From the man page:

If successful, calloc(), malloc(), realloc(), reallocf(), valloc(), and aligned_alloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM.

In practice, I find a lot of code that does not check for NULL, which is rather distressing.

Re: Vm.overcommit_memory=2 is the right setting for servers

#54

Post by dasil003 »

dbdr wrote: post #20
LordGrey wrote: post #3

For anyone not familiar with the meaning of '2' in this context: The Linux kernel supports the following overcommit handling modes 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.…

> exceed swap + a configurable amount (default is 50%) of physical RAM Naive question: why is this default 50%, and more generally why is this not the entire RAM, what happens to the rest?

Not sure if I understand your question but nothing "happens to the rest", overcommitting just means processes can allocate memory in excess of RAM + swap. The percentage is arbitrary, could be 50%, 100% or 1000%. Allocating additional memory is not a problem per se, it only becomes a problem when you try to actually write (and subsequently read) more than you have.

Re: Vm.overcommit_memory=2 is the right setting for servers

#55

Post by toast0 »

ycombinatrix wrote: post #19
blibble wrote: post #8

redis uses the copy-on-write property of fork() to implement saving which is elegant and completely legitimate

How does fork() work with vm.overcommit=2? A forked process would assume memory is already allocated, but I guess it would fail when writing to it as if vm.overcommit is set to 0 or 1.

As pm215 states, it doubles your memory commit. It's somewhat common for large programs/runtimes that may fork at runtime to spawn an intermediary process during startup to use for runtime forks to avoid the cost of CoW on memory and mapppings and etc where the CoW isn't needed or desirable; but redis has to fork the actual service process because it uses CoW to effectively snapshot memory.

Re: Vm.overcommit_memory=2 is the right setting for servers

#56

Post by silon42 »

laurencerowe wrote: post #43

Disabling overcommit on V8 servers like Deno will be incredibly inefficient. Your process might only need ~100MB of memory or so but V8's cppgc caged heap requires a 64GB allocation in order to get a 32GB aligned area in which to contain its pointers. This is a security measure to prevent any possibility of out of cage access.

Maybe it should use MAP_NORESERVE ?

Re: Vm.overcommit_memory=2 is the right setting for servers

#57

Post by silon42 »

Tuna-Fish wrote: post #34
silon42 wrote: post #14

Earlier quoted context omitted.

For me, on the desktop, thrashing overload is the most common way the Linux system effectively crashes... (I've left it overnight a few times, sometimes it recovered, but not always). I'm not disabling overcommit for now, but maybe I should.

disabling overcommit does not fix trashing. Reducing the size of your swap does.

Yes, but not fully, it may still thrash on mmaped files (especially readonly ones).

Re: Vm.overcommit_memory=2 is the right setting for servers

#58

Post by sidewndr46 »

LordGrey wrote: post #53
sidewndr46 wrote: post #45

Earlier quoted context omitted.

Do any of the settings actually result in "malloc" or a similar function returning NULL?

malloc() and friends may always return NULL. From the man page: If successful, calloc(), malloc(), realloc(), reallocf(), valloc(), and aligned_alloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM. In practice, I find a lot of code that does not check for NULL, which is rather distressing.

It's been a while but while I agree the man page says that, my limited understanding was the typical libc on linux won't really return NULL under any sane scenario. Even when the memory can't be backed

Re: Vm.overcommit_memory=2 is the right setting for servers

#59

Post by LordGrey »

sidewndr46 wrote: post #58
LordGrey wrote: post #53

Earlier quoted context omitted.

malloc() and friends may always return NULL. From the man page: If successful, calloc(), malloc(), realloc(), reallocf(), valloc(), and aligned_alloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM. In practice, I find a lot of code that does not check for NULL, which is rather distressing.

It's been a while but while I agree the man page says that, my limited understanding was the typical libc on linux won't really return NULL under any sane scenario. Even when the memory can't be backed

I think you're right, but "typical" is the key word. Embedded systems, systems where overcommit is disabled, bumping into low ulimit -v settings, etc can all trigger an immediate failure with malloc(). Those are edge cases, to be sure, but some of them could be applied to a typical Linux system and me, as a coder, won't be aware of it.

As an aside: To me, checking malloc() for NULL is easier than checking a pointer returned by malloc on first use. That's what you're supposed to do in the presence of overcommit.

Re: Vm.overcommit_memory=2 is the right setting for servers

#60

Post by loeg »

blibble wrote: post #46
loeg wrote: post #32

Earlier quoted context omitted.

Can you elaborate on how this comment is connected to the article?

did you read it the article? there's a large section on redis the author says it's bad design, but has entirely missed WHY it wants overcommit

You haven't made a connection, though. What does fork have to do with overcommit? You didn't connect the dots.
Post reply on HN