oom killer - это не бекграунд и не процесс, это функция ядра "выбрать жертву и убить, когда не хватает памяти"

и кстати вот: $ ps ax | grep -i oom 684 ? S 0:00 [oom_reaper]

ну, это не киллер, это рипер :)

https://lwn.net/Articles/666024/

это тред ядра, который начинает разбирать память приложения, которое надо убить через -9, даже если оно повисло на неотменяемом сисколле

@Komzpa получается, segfault невозможен при исчерпании процессом физической памяти и swap'а?

если это не так, то я хотел бы, чтобы мне показали этот путь исполнения :)

сегфолтов в постгресе и без oom хватает

Опытным путем установлено, что если постгрес запущен по через pg_ctl без ключика -c (--core-files), то вы хоть заиграйтесь лимитами - корок нет и неизвестно. Странно, но я данный факт в wiki чегой-то не наблюдаю. Плохо смотрю?

Эта опция сама проставляет ulimit. Это можно проследить в коде: src/bin/pg_ctl/pg_ctl.c:810

Причём тут выставление юлимитов?

Причём тут выставление юлимитов?

хм... установка лимита на размер core - вызов setrlimit c опцией RLIMIT_CORE

Ещё раз: без выставления этой опции ты можешь заиграться с юлимитами на уровне системы вусмерть. Но корку ты не получишь. Мало того! pg_ctl-ю на юлимит, выставленный в системе глубоко плевать, как показывает практика.

Проверяется данное утверждение просмотром соответствующего файлика в /proc.

Ещё раз: без выставления этой опции ты можешь заиграться с юлимитами на уровне системы вусмерть. Но корку ты не получишь. Мало того! pg_ctl-ю на юлимит, выставленный в системе глубоко плевать, как показывает практика.

Не знаю как у вас, но у себя на маке корки получаю без этой опции...

Не знаю как у вас, но у себя на маке корки получаю без этой опции...

Какая прелесть! Так и повеяло чем-то родным и до боли близким. :(

Какая прелесть! Так и повеяло чем-то родным и до боли близким. :(

У тебя тоже был мак, на котором ты мог получать любые корки?

А что, на многих маках используется постгрес?

Причём тут выставление юлимитов?

при том что корку пишет ОС, и это управляется ulimit-ом. Да, плохо смотришь. Без '-c' они пишутся, если стоят правильные ulimit-ы

хотя, сейчас подумал, я почти из всех скриптов дергаю непосредственно постргес, а не pg_ctl. Он гипотетически может и перетирать ulimit-ы

хотя, сейчас подумал, я почти из всех скриптов дергаю непосредственно постргес, а не pg_ctl. Он гипотетически может и перетирать ulimit-ы

Ну не знаю, на моем ноуте не перетирает)

Стас, без -c "Max core file size" равно нулю в /proc/$pid/limits, независимо от того, что написано в /etc/security/limits.conf Я с этим хорошо так нахлебался, когда с Астрой развлекался.

в сессии ставь ulimit

Стас, без -c "Max core file size" равно нулю в /proc/$pid/limits, независимо от того, что написано в /etc/security/limits.conf Я с этим хорошо так нахлебался, когда с Астрой развлекался.

Мб дело в астре?

при том что корку пишет ОС, и это управляется ulimit-ом. Да, плохо смотришь. Без '-c' они пишутся, если стоят правильные ulimit-ы

Эт оптимистычны подход. В новомодных Linux'ах есть например такая система https://wiki.ubuntu.com/Apport#Crash_interception

в сессии ставь ulimit

В какой сесси, если я запускаю ПГ штатным системным способом?

Т.е. либо по через инит-скрипты, либо по через системд, хвала его создателю?

В какой сесси, если я запускаю ПГ штатным системным способом?

в той сессии, где pg_ctl запускается

В какой сесси, если я запускаю ПГ штатным системным способом?

да е моё, у тебя система не проставила ulimit-ы, хрен знает почему. Как из этого следует что без pg_ctl -c не получишь корки?

Т.е. либо по через инит-скрипты, либо по через системд, хвала его создателю?

/etc/security/limits.conf ?

Эт оптимистычны подход. В новомодных Linux'ах есть например такая система https://wiki.ubuntu.com/Apport#Crash_interception

Ну во-первых, эта приблуда есть только в убунте, а в большинстве остальных дистров будет systemd-coredump. А во-вторых, там написано, что даже при нулевом лимите она все равно соберёт дамп :)

Ну не все пользуются systemd. Кто-то принципиально сидит на последних версиях с init.d

/etc/security/limits.conf ?

test@webdeb:~$ grep -v "^\($\|#\)" /etc/security/limits.conf root soft core unlimited root hard core unlimited * soft core unlimited * hard core unlimited test@webdeb:~$ grep "^Max core file size" /proc/{345,708}/limits /proc/345/limits:Max core file size 0 unlimited bytes /proc/708/limits:Max core file size unlimited unlimited bytes 345 - это постмастер; 708 - это tail -f лога ПГ от имени системного пользователя - владельца ПГ.

После правки лимитс.конф сервачок перезапускался.

Ребята, для primary key нужно выставлять unique constraint или это тавтология?

Это тавтология.

Ага, спасибо

Ключ в таблице именно потому и называется ключом, что он однозначно определяет запись таблицы.

Ну я тоже так думал, просто в итернете часто в примерах выставляют unique для primary ключа в примерах

Этих ключей может быть далеко не один. Но вот примари - он таки да, единственный и неповторимый. :)

Интернеты - оне такие, да...

Интернеты - оне такие, да...

ну я подумал, может фишка такая :)

test@webdeb:~$ grep -v "^\($\|#\)" /etc/security/limits.conf root soft core unlimited root hard core unlimited * soft core unlimited * hard core unlimited test@webdeb:~$ grep "^Max core file size" /proc/{345,708}/limits /proc/345/limits:Max core file size 0 unlimited bytes /proc/708/limits:Max core file size unlimited unlimited bytes 345 - это постмастер; 708 - это tail -f лога ПГ от имени системного пользователя - владельца ПГ.

Соответственно, корки получить от данного инстанса весьма проблематично.

test@webdeb:~$ grep -v "^\($\|#\)" /etc/security/limits.conf root soft core unlimited root hard core unlimited * soft core unlimited * hard core unlimited test@webdeb:~$ grep "^Max core file size" /proc/{345,708}/limits /proc/345/limits:Max core file size 0 unlimited bytes /proc/708/limits:Max core file size unlimited unlimited bytes 345 - это постмастер; 708 - это tail -f лога ПГ от имени системного пользователя - владельца ПГ.

Ты выше написал, что без pg_ctl -c корку не получишь. Я возражаю именно против этого. На нормальной системе limits.conf достаточно. Если почему-то ОС не реагирует на limits.conf, то pg_ctl тут не виноват. ОС так же может и игнорить ulimit/setrlimit и тогда и '-c' не поможет

а что из этого ты создавал?

ничего. оно в списке маячит

а что из этого ты создавал?

принцип Тараса Бульбы)

после работы с EMS sql manager появилось

Отпишитесь по результатам.

Значит, на мастере все более-менее. А слейвы как падали каждые 5-10 минут, так и падают.

overcommit memory 2

overcommit ratio от 70 до 80

Значит, на мастере все более-менее. А слейвы как падали каждые 5-10 минут, так и падают.

пересоздавайте через pg_basebackup

Значит, на мастере все более-менее. А слейвы как падали каждые 5-10 минут, так и падают.

А у вас на слейвах какая нагрузка, кроме рековера?

А у вас на слейвах какая нагрузка, кроме рековера?

На мастере падения раз в два часа, т.к. нагрузка в основном на три слейва

Примерно 4к транзакций на одной ноде.

В пике до 7к

А с памятью на слейвах так же, как на мастере?

А с памятью на слейвах так же, как на мастере?

На мастере 256, а на слейвах 320.

И тоже 82Гб используется, как на праймари?

Настройки overcommit одинаковые

И тоже 82Гб используется, как на праймари?

Там чуть побольше около 107

Но на слейвах ещё HugePages

Ну тогда надо брать gdb и смотреть корки. Другого способа диагностики я не знаю...

А shared_buffers какой у вас?

ERROR: S client not available

pgbouncer используете? Или другой пул коннектов?

А shared_buffers какой у вас?

60 на мастере, 90 на слейвах

pgbouncer используете? Или другой пул коннектов?

PGPool 3.5.5

Попробуйте на одном из слейвов поставить размер shared_buffers 75% от RAM

Т.е. либо по через инит-скрипты, либо по через системд, хвала его создателю?

systemd не учитывает limits.conf. Надо в юнит ставить

Игорь, у меня аналогичная картина была и на системах с init-ом.

Ща погуглил - таки да, есть такая безобразия на системд. Штопаный разврат, нет в мире щастья, а в жЫзни совершенства.

с init давно не встерачался в этом плане

Ребята, извините за глупый вопрос, но как поставить pg_pathman? Его нужно клонировать и внутри папки выполнить make?

Ребята, извините за глупый вопрос, но как поставить pg_pathman? Его нужно клонировать и внутри папки выполнить make?

там же инструкция есть в readme

Значит, на мастере все более-менее. А слейвы как падали каждые 5-10 минут, так и падают.

Есть свиги?

там же инструкция есть в readme

Мой вопрос касается самого первого пункта этой инструкции

Ребята, извините за глупый вопрос, но как поставить pg_pathman? Его нужно клонировать и внутри папки выполнить make?

привет! да, только в make нужно указать USE_PGXS=1 и PG_CONFIG=/путь/к/pg_config

привет! да, только в make нужно указать USE_PGXS=1 и PG_CONFIG=/путь/к/pg_config

Спасибо! Сейчас попробую

(путь к pg_config нужен только, если его нет в PATH)

Есть свиги?

У нас уже 8 вечера, решил оставить до завтра. В любом случае, огромное спасибо за советы, завтра утром будет продолжение эксперимента.

Здравствуйте

Можете посоветовать решение для postgresql read write splitting?

чтобы запросы на запись шли на мастер, а на слейв только чтение

@Komzpa получается, segfault невозможен при исчерпании процессом физической памяти и swap'а?

возможен: https://gist.github.com/akopytov/28bbbb50e07b65e9d0f2479317f41894

но это на single-node машине с выключенным swap. на NUMA машине и со свопом ответ на вопрос ещё менее однозначный

нет. это синхронная операция, выполняющаяся на page fault, когда не нашлось новых страниц

я утром несколько торопился и, признаюсь, не очень внятно формулировал мысли. моя мысль в том, что oom killer действует чаще асинхронно по отношении к pagefault-ам, происходящим в каждом конкретном процессе. например, если postgresql выделил больше памяти, чем доступно в системе, то с включенным overcommit с большой вероятностью он будет убит не при собственном pagefault-е, а в какой-то произвольный момент времени. просто потому, что какому-то другому процессу в системе понадобилась память

возможен: https://gist.github.com/akopytov/28bbbb50e07b65e9d0f2479317f41894

это segfault, вызванный неправильной работой с malloc

это segfault, вызванный неправильной работой с malloc

это segfault вызванный тем, что malloc() возвращает NULL

что возможно с выключенным оверкоммитом, что и демонстрирует мой пример

это segfault вызванный тем, что malloc() возвращает NULL

ну да, надо как бы проверять на NULL

началось всё с обсуждения того, что segfault может быть вызван нехваткой памяти с дефолтным значением overcommit. и что приложения (включая postgres) редко обрабатывают этот конкретный случай всегда корректно

другое дело, что во многих случаях это может не иметь смысла

нет памяти - нельзя ничего сделать, поэтому abort(), например

началось всё с обсуждения того, что segfault может быть вызван нехваткой памяти с дефолтным значением overcommit. и что приложения (включая postgres) редко обрабатывают этот конкретный случай всегда корректно

разыменование NULL поинтера - это UB