On Sat, Feb 29, 2020 at 9:13 AM Dale <rdalek1...@gmail.com> wrote: > > Runaway processes is one reason I expanded my memory to 32GBs. It gives > me more wiggle room for portage to be on tmpfs. >
That is my other issue. 99% of the time the OOM killer is preferred when this happens versus having the system just grind to a complete halt. Either way some service is going to stop working, but at least with the OOM killer it probably will only be one service. OOM doesn't always kill the right thing, but it happens so infrequently I haven't bothered to address this. Setting limits on VM use on each service would of course be a good idea. Also, you can tune OOM priority as well for any process. With systemd these are unit config settings. I haven't looked at openrc recently but certainly you can just edit the init.d script to set these if there isn't just a config option. I've found OOM guessing wrong is more of an issue when you have a lot of medium-sized processes vs one large one. If one process is using 10GB of RAM and goes haywire it is very likely that this is the one OOM-killer will go after. On the other hand if you're building with make -j16 and you hit some really intensive part of a build and you get 16 processes demanding half a GB each then it is more likely that the OOM killer will first target some service that is RAM-hungry but not usually a problem, because it is using more than any one of the gcc processes. I wonder if you can make OOM-killer cgroup-aware. Services are generally in separate cgroups while make would all be in another, so if it looked at total use of the cgroup and not the individual process then it would weigh something that forks heavily a lot higher. -- Rich
