4 ms·
> generally no swap in production. This is a bad policy. The problem is that it breaks Linux's overcommit logic. Many applications allocate huge chunks of virt
by nwallin 7y ago
> generally no swap in production.
This is a bad policy. The problem is that it breaks Linux's overcommit logic. Many applications allocate huge chunks of virtual memory far in excess of what they actually use. Due to the magic of virtual memory, this doesn't get mapped to physical memory until it's actually used.
The trouble is that there's no mechanism in any programming language I'm aware of that allows the OS to retcon an allocation. The only tool the kernel has at its disposal is the oom killer. So if you allocate too much, and you have swap disabled, the oom killer has to step in and kill something even if you're only using half your ram.
This is bad enough, but in addition to this, you have vfs cache to worry about. If you have 64GB ram, your applications are using 40GB, and you have 22GB cache, you and I might assume you have 24GB free, but the OS only sees 2GB free, and a few allocations might trigger the oom killer if they happen faster than the vfs can dump cache. (which is surprisingly slow) With swap, this isn't a big deal, because the pages don't actually get assigned until they are used, which happens later, so the vfs has plenty of time to evict.
The point of swap isn't to give you more memory. It's so the OS can keep its promises about memory allocation and overcommitting.
- nailer 7y ago> So if you allocate too much, and you have swap disabled, the oom killer has to step in and kill something even if you're only using half your ram. You can allocate all the memory you want, the OOM killer only steps in when you actually use all the the memory.