And after following this advice, you end up with a system that can fail to fork() even when half of the computer's memory is free. This can also turn your once-working server into an unreliable toy.
(Also, see the comments in the original article that talk about vm.overcommit_memory=2 not actually doing what it claims to do...)
I was under the impression that fork() basically set up copy-on-write pages for the child process, and thus if it exec()'ed it would lose all those pages anyways and start fresh. Are those VM settings changing that behavior?
It wouldn't affect the copy-on-write optimization or exec(), it just causes fork() to return an error earlier. 'vm.overcommit_memory = 2' attempts to guarantee that after a fork, all of the copy-on-write-pages can still be dirtied (i.e. causing a copy) without the system running out of RAM.
Good luck making sure that all your running programs use vfork(). And why would they? If you read the man page, it is hardly encouraging:
It is rather unfortunate that Linux revived this specter from the past. The BSD man page states: "This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of vfork() as it will, in that case, be made synonymous to fork(2)."
some apps also use fork and the copy on write behaviour deliberately to implement features. redis uses it to create its backup file (http://redis.io/topics/faq)
>> Redis background saving schema relies on the copy-on-write semantic of fork in modern operating systems: Redis forks (creates a child process) that is an exact copy of the parent. The child process dumps the DB on disk and finally exits.
It's possible to use safely, and the benefits are worth it --- no commit charge problems and no time spent copying page tables. (Even in the memory itself is copy-on-write, you still have to set up the child's address space.)
I'm sick of people cargo-culting ideas like "vfork is bad" without really understanding the issues.
(Also, see the comments in the original article that talk about vm.overcommit_memory=2 not actually doing what it claims to do...)