В документации Redis четко указано, что vm.overcommit_memory должен быть установлен на 1 чтобы гарантировать сбой фонового сохранения новых: http://redis.io/topics/faq
ТЕМ НЕ МЕНИЕ
В документации postgresql говорится, что vm.overcommit_memory должен быть установлен на 2 чтобы избежать того, чтобы почтовый мастер-процесс не был убит убийцей oom: http://www.postgresql.org/docs/9.3/static/kernel-resources.html
Теперь это противоречиво. Что я должен делать?
Мои redis db имеют ограничение в 20 ГБ. На сервере 252 ГБ физической памяти. Postgresql редко использует физическую оперативную память объемом более 100 ГБ.
PS: я использую ubuntu 14, Redis 3.0 и Postgresql 9.3
Вы можете воспользоваться рекомендацией Redis, так как пакеты PostgreSQL для Ubuntu уже реализуют подход, упомянутый в документации, против опрометчивого OOM-уничтожения процесса postmaster.
Это сразу после раздела, на который вы ссылаетесь в документе. Отрывок из Перегрузка памяти Linux
Другой подход, который можно использовать с изменением или без изменения vm.overcommit_memory, заключается в установке значения oom_score_adj для конкретного процесса для процесса postmaster равным -1000, тем самым гарантируя, что он не станет целью убийцы OOM. Самый простой способ сделать это - выполнить
эхо -1000> / proc / self / oom_score_adj
в сценарии запуска postmaster непосредственно перед вызовом postmaster. Обратите внимание, что это действие должно быть выполнено от имени пользователя root, иначе оно не будет иметь никакого эффекта; поэтому сценарий запуска, принадлежащий пользователю root, - самое простое место для этого. Если вы это сделаете, вы также можете захотеть собрать PostgreSQL с -DLINUX_OOM_SCORE_ADJ = 0, добавленным в CPPFLAGS. Это заставит дочерние процессы postmaster работать с обычным нулевым значением oom_score_adj, так что убийца OOM может по-прежнему нацеливаться на них при необходимости.
В Ubuntu 14 pg_ctlcluster сценарий, запускающий экземпляр postgres, имеет следующее:
# 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;
}
}
поэтому он назначает фиксированный -900 на оценку OOM почтмейстера,
и /usr/lib/postgresql/9.3/bin/pg_config pg_config --cflags говорит:
-g -O2 -fstack-protector --param = ssp-buffer-size = 4 -Wformat -Werror = безопасность-формат -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 = стандартный -g
Так что postmaster никогда не должен выбираться убийцей OOM, но дочерний внутренний процесс (по одному на соединение) может.