Hacker News new | ask | show | jobs
by grahn 3108 days ago
> As a last resort, the Kernel will deploy OOM killer to nuke high-memory process(es)

Yes! That is exactly what I want to happen!

When the system runs out of RAM, things will generally stop functioning, swap enabled or not. The only question is how you want it to stop functioning when that happens.

In almost every situation, I'll easily take the kernel killing whatever single process it thinks is most appropriate to get rid of, and keep everything else up and running smoothly, over grinding the the entire system to a halt by upping the effective memory access time by orders of magnitude.

Simply put: If everything doesn't fit in memory, then don't try to run everything!

Properly designed software nowadays is designed to be able to crash without corrupting data. As far as I'm concerned, it is almost always preferable to kill and restart instead of giving CPR to processes that don't fit in the working memory.

2 comments

Funny story though, we had a database server get nuked because a client process used too much memory. We hadn't done the tuning correctly and someone decided to run their queries locally. So it was entirely our fault. But mysqld - 220GB, mysql (client) - 30GB, let's nuke the server process.

Lesson learned, make sure you adjust the OOM killer on things like services that use lots of RAM.

I don't want this to happen.

On servers, in almost every situation, I'd rather have the server reboot than have some random process crash and leave the system in a potentially broken state.

On desktops, in every situation, I'd rather have X, my window manager and an emergency terminal pinned to RAM so I can always decide what to kill for myself. (https://github.com/stiletto/angrymlocker helps with setting this up.)

> I'd rather have the server reboot than have some random process crash and leave the system in a potentially broken state.

Set the OOM killer to trigger a reboot? Crawling to a swapping halt is the worst of both worlds, it's like a full system crash but the server never comes back.

Set overcommit policy and malloc would just fail, which is handled in mysql and would abort the query instead of invoking oom killer.

And a crashing service should get restarted, involving journal file recovery which is consistent state.

> Set overcommit policy and malloc would just fail, which is handled in mysql and would abort the query instead of invoking oom killer.

So many things depend on so many gigabytes of overcommit, that seems like a pretty bad way to go about it in the general case.

> And a crashing service should get restarted, involving journal file recovery which is consistent state.

I think you're agreeing with me with this sentence?