Am Sun, 19 Feb 2017 13:53:49 +0100 schrieb Helmut Jarausch <jarau...@skynet.be>:
> Hi, > > sometime I have some memory hungry ebuilds in the background, when I > start (e.g.) Chromium which needs very much memory if you have a lot > of open tabs. > > In that case my system nearly freezes. I cannot even kill chrome. > What can I do in that case. (Remote login doesn't work either) > > Can I have any additional program (like Chromium) die if there is > not enough memory. You may want to switch to the deadline scheduler and see if it improves things. For my setup, it did (bcache involved). But I'm pretty sure my usage pattern is a bit different, I'm emerging in a tmpfs (I have 16 GB of RAM), so every big ebuild probably forces data going to swap. Actually, all my three hard disks have a 10 GB swap partition in front with same priority. The file system itself is cached through bcache, so it should be mostly decoupled (this means, put swap to mostly idle disks). But I was still seeing extensive freezes until I switched to the deadline scheduler. Kernel 4.10, which brings write-back throttling, will probably help also (and maybe I can switch back to CFQ then to benefit from ioprio again). The problem is something like buffer bloat known from networking: Writes queue up in a long queue, and even small writes will block your applications. CFQ tends to build really long such queues while it tries to maintain "fairness". Deadline instead tries to service write requests as fast as possible after a short timeout (which can be configured in sysfs). Even then, a huge queue can still pile up, so I suggest you reduce dirty_background_bytes to a sane value (the default percent values really don't play well with amounts of RAM installed today): vm.dirty_background_bytes = 134217728 This makes processes with dirty data block much earlier and should reduce the queue. You may want to lower it even more and see how your system behaves. There's a chance that these shorter queues can be written before the whole system blocks (because dirty_bytes is exhausted). At least it should reduce the time until the system becomes responsive again. I think that swap space is there and is cheap to use most of the time, so you should encourage your system to use it and use it early (prefer caching over parking dead memory blocks in RAM). The problem comes when your system is already stalled by other IO - which apparently is the case most of the time when the system needs to start using swap. The only fix is to keep the IO queues short. The knobs mentioned above should help you with that. -- Regards, Kai Replies to list-only preferred.
