Redis e Postgresql na mesma máquina: vm.overcommit_memory =?

Question

Na documentação do Redis, ele afirma claramente que vm.overcommit_memory deve ser definido como 1 para garantir que a recuperação em segundo plano falhe: link

NO ENTANTO

Na documentação do postgresql, diz que vm.overcommit_memory deve ser definido como 2 para evitar que o processo de pós-masterização não seja morto pelo oom killer: link

Agora, isso é de causa contraditória. O que devo fazer?

Meu banco de dados redis tem um limite de 20 GB. O servidor tem 252 GB de RAM física. O Postgresql raramente usa mais de 100 GB de memória física.

PS: Eu estou no Ubuntu 14, no Redis 3.0 e no Postgresql 9.3

    

Answer 1

Você pode optar pela recomendação do Redis, já que os pacotes PostgreSQL para o Ubuntu já implementam a abordagem mencionada na documentação contra uma falha do processo postmaster mal-informado.

É logo após a seção que você está se referindo no documento. Excerto de Overcommit de memória do Linux

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.

No Ubuntu 14, o script pg_ctlcluster que inicia uma instância postgres tem isto:

   # 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;
        }
    }

por isso atribui um -900 fixo à pontuação OOM do postmaster,

e /usr/lib/postgresql/9.3/bin/pg_config pg_config --cflags dizem:

-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

Portanto, o postmaster nunca deve ser selecionado pelo invasor OOM, mas o processo de back-end filho (um por conexão) pode.