Hacker News Reader

Comment by nisa | Hacker News Reader

This is dangerous advice. At least on Ubuntu 16.04 with stock kernel running due to memory pressure into swap kills the systems. Basically everything times out and you can only hard-reboot. Without swap you have an OOM at least something you can recover from. If you need swap just add a little like 1-4gb - because if you have spinning disks 64gb swap won't help you at all because every request to swap is magnitudes more slower. Might be different with NVMe but it's still noticable.

View on HN

Not just ubuntu. We tell our engineers to remove their swap partitions because sometimes the test suite will consume all remaining memory and push into swap. If that happens, pretty much the only thing you can do is a hard poweroff. If you're fast, you can Ctrl+C and only lose a minute or two, but often you're just completely stuck.

Much better to OOM and have the test suite killed early.

Wouldn’t it make much more sense to limit the maximum amount of memory available to something like (system memory-500MB) using CGroups? I know configuring CGroups can be difficult because there is no command line script but it might be worth it if it’s such a common problem with your test suits. An easy way to configure CGroups would be to use docker but that adds a lot of overhead in management (not in performance - but you need to have every dev install docker and test the suit using docker).

I use swap quite a lot, though, I’m not sure what my system moves to swap though. A large portion seems to be inactive google chrome tabs (whenever I open an inactive tab, chrome freezes for a second and I suddenly use ~70MB less swap.

> If that happens, pretty much the only thing you can do is a hard poweroff.

Sounds like a non-swap system/kernel tuning issue - you should still be able to slowly switch to a virtual console or ssh in, etc, and kill the test suite..

Also, most linux distros run without any real usage of user/group resource limiting - setting up these appropriately is useful to limit the overall impact of runaway jobs

Can ulimit help here?

Ulimit is per process, it won't do. vm.overcommit_memory=2 with some setting of vm.overcommit_ratio or bytes will help though.

I'd say overcommit heuristics break applications and cause them to eat too much memory since they don't know when to stop. The only trouble is KVM which for some reason takes double of process space allocated to the VM for no good reason and perhaps memory intensive Java.

You need to tune the latter anyway.

indeed on ubuntu 16.04 64bit, when my chrome has 20+ tabs, some new tab could trigger a memory thrashing, that uses up all the memory and eats up a few GB disk, cpu load jumps up to 10x, the computer basically becomes unusable.

i would rather a OOM kill the chrome process in this case, it wastes less time on me, a re-open of chrome will keep all the histories anyways.

also on embedded system where the RAM is fairly limited, and no hard drive attached, and its storage is measured by MB instead of GB, you simply can not have the swap partition.

I want to run the system without swap actually.

>when my chrome has 20+ tabs

That's not a swap problem, that's a Chrome problem.

It is a swap problem. Swap is supposed to make things work and not stop.

I suppose this is actually a problem of Linux optimistic malloc policy.

Reply on news.ycombinator.com