4 ms·
A particularly bad case of the OOM killer making a mistake is in-memory databases. If some other process is using lots of memory, but still less that the DB, it
by lucian1900 13y ago
A particularly bad case of the OOM killer making a mistake is in-memory databases. If some other process is using lots of memory, but still less that the DB, it'll get killed for no good reason anyway.
- derefr 13y agoOne would hope that any machine hosting an in-memory database has gobloads of RAM and not much else to do. :) [Still, this is what replication is for! "In-memory database" is only a scary concept if you don't have any hot slaves.]
- lucian1900 13y agoOne might have 2/3 of memory used, with well known database size growth. Then a runaway process could use 1/3 of memory, cause trouble, but it's still the DB that gets killed. This isn't disastrous of course (replication + snapshots + redis aof), but still annoying.
- derefr 13y agoAnother thing you can do, in this case, is to enable swap system-wide, then put just the database process into a cgroup with memory.swappiness = 0. Thus, the database itself will never degrade due to spilling to disk, but all other processes might. But if it's a DB box, that won't precisely matter.
- mitchty 13y agoWouldn't another option be to setup hugepages for the db and then just have the db process use hugepages? They'll never swap out and bonus less memory used. (note transparent huge pages have only brought me pain so far)