3

In the Redis documentation it clearly states that vm.overcommit_memory should be set to 1 to ensure background saving newer fails: http://redis.io/topics/faq

HOWEVER

In postgresql documentation it says, that vm.overcommit_memory should be set to 2 to avoid the post master process does not get killed by the oom killer: http://www.postgresql.org/docs/9.3/static/kernel-resources.html

Now, this is of cause contradictory. What should I do?

My redis db's have a limit of 20GB. The server has 252GB physical RAM. Postgresql rarely uses more than 100GB physical ram.

PS: I'm on ubuntu 14, Redis 3.0 and Postgresql 9.3

Niels Kristian
  • 358
  • 1
  • 3
  • 13

1 Answers1

4

You may go for the Redis recommendation, as the PostgreSQL packages for Ubuntu already implement the approach mentioned in the documentation against an ill-advised OOM kill of the postmaster process.

It's just after the section you're refering to in the doc. Excerpt from Linux Memory Overcommit

Another approach, which can be used with or without altering vm.overcommit_memory, is to set the process-specific oom_score_adj value for the postmaster process to -1000, thereby guaranteeing it will not be targeted by the OOM killer. The simplest way to do this is to execute

echo -1000 > /proc/self/oom_score_adj

in the postmaster's startup script just before invoking the postmaster. Note that this action must be done as root, or it will have no effect; so a root-owned startup script is the easiest place to do it. If you do this, you may also wish to build PostgreSQL with -DLINUX_OOM_SCORE_ADJ=0 added to CPPFLAGS. That will cause postmaster child processes to run with the normal oom_score_adj value of zero, so that the OOM killer can still target them at need.

On Ubuntu 14, the pg_ctlcluster script that starts a postgres instance has this:

   # have the postmaster start with increased OOM killer protection; 9.1 and
    # later has builtin support for resetting the adjustment of child processes
    if ($action eq 'start' && $version >= '9.1') {
        if (-w '/proc/self/oom_score_adj') {
            open F, '>/proc/self/oom_score_adj';
            print F "-900\n";
            close F;
        }
    }

so it assigns a fixed -900 to the postmaster's OOM score,

and /usr/lib/postgresql/9.3/bin/pg_config pg_config --cflags says:

-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -pie -I/usr/include/mit-krb5 -DLINUX_OOM_SCORE_ADJ=0 -fno-omit-frame-pointer -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g

So the postmaster should never be selected by the OOM killer, but child backend process (one per connection) can.

Daniel Vérité
  • 3,045
  • 16
  • 19