Hacker News Reader

Comment by kalleboo | Hacker News Reader

Here's a novel way to deal with an out of memory situation caused by slow memory leaks in a long-running server process: start swapping memory that hasn't been touched in literally days or weeks to /dev/null, and pray the process doesn't ever need it again.

View on HN

That's so indescribably worse than just killing that process the mind boggles. Breaking in a simple, predictable, and detectable way vs. corrupting data and hoping (excuse me, "praying") nobody notices.

> vs. corrupting data and hoping (excuse me, "praying") nobody notices.

Well it seems to work for MySQL

Anyway, you wouldn't ever return the nulled data. If the process tries to access the data, THEN you crash it.

Better yet instead of sending it to /dev/null save it on disk and reload it whenever the process needs it again. Oh wait that is how virtual memory works.

This works for an overcommitted load, but the parent talks about a leak. In this case, you'll eventually exhaust swap.

Compressing the memory area used by the leaky process in question would be a gentler and more robust "solution" here. There already exists a Linux kernel module called "zram" [1] with which you can accomplish just that (though you might have to tune your swappiness a bit first).

[1] https://en.wikipedia.org/wiki/Zram

Is pray a syscall?

I'm pretty sure there's a linux kernel module. Obviously it'd be required for my method to work. Might not be doable in FreeBSD (incompatible with the branding).

> Might not be doable in FreeBSD (incompatible with the branding)

Perhaps something more in line with BSD would be a sacrifice(2) syscall? It would pick a random process and...

Reply on news.ycombinator.com