4 ms·
I know this is not a popular / mainstream position, but I managed a very large fleet of systems this way: - no system swap - enough memory for core system ser
by lokar 5mo ago
I know this is not a popular / mainstream position, but I managed a very large fleet of systems this way:
- no system swap
- enough memory for core system services set aside in a cgroup for them to use
- by default, all prod service binaries load all code pages into ram at start, and lock them in (no paging out code pages at runtime)
- if needed (rare) services can mount some swap in their own cgroup, but very much discouraged
You need to know how much ram you are going to use, and actually stick to that. Very little is wasted in practice, and you don't have to deal with OOMs all the time. Everything is much more predictable.
- xyzzy_plugh 5mo agoI agree with your perspective. I certainly agree that swap can be invaluable at times, and is generally a mistake for your run-of-the-mill production services. It's a nice approach particularly because all OOMs become actionable: there's a bug in a service or a limit is wrong or traffic is changing in an unexpected way. Systems built this way end up being extremely reliable in my experience. It's an uphill battle both ways though and not everyone is up for that experience.
- tosti 5mo agoHave you disabled swap in the kconfig entirely? If not, is your vm.swapiness 0? How do you deal with overcommit? Did you replace malloc with a more strict implementation?