Rich Freeman wrote: > 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. >
I have noticed the OOM killing the wrong thing as well. In a way, how does it know what it should kill really??? After all, the process using the most memory may not be the problem but another one, or more, could. I guess in most cases the one using the most is the bad one but it may not always be the case. I'm not sure how OOM could determine that tho. Maybe having some setting like you mentions would help. It's a thought. A while back I had issues with Firefox getting hoggy on memory. One or two websites would just make it go nuts. I block all that crypto mining crap tho. Still, it would normally take a couple GBs when a lot of tabs are open but when those sites got a hold of it, it could swell to 5, 6, 8GBs or more in fairly short order. Thing is, at times OOM would kill the whole GUI not just Firefox. I'd be back at a login screen. Of course, when it does that, it not only kills firefox, it kills firefox running other profiles, Seamonkey and any other programs running within the GUI. As you say, it doesn't always do the "right thing" when it starts killing processes. I don't recall ever actually running out of memory when emerging. I know what the big packages are and set tmpfs to be on spinning rust for those. Of course, after the upgrade, I think only LOo is on that. I'm not sure why, but when LOo updates, so does either Firefox or Seamonkey and sometimes both. Given their size, they end up trying to compile together. That can take up some space on tmpfs if in memory instead of spinning rust. Then there is that HUGE qt package. O_O While I see swap as a necessary evil, I only want it used on very rare occasions. The OOM tool just doesn't get it right. Me killing the offender in htop does tho. BTW, Firefox stopped doing the memory hog thing so bad a few upgrades ago. I never did figure out exactly what it was that triggered that. :/ Dale :-) :-)
