The database system is in recovery mode

И так примерно пару раз в день

Явных факапов в логах не наблюдается.

Куда копать?

Жуть какая то... Уже думаю не прще ли MS SQL Srv купить...

Ненене :)

The database system is in recovery mode

У вас какое значение vm.overcommit_memory в sysctl.conf ?

У вас какое значение vm.overcommit_memory в sysctl.conf ?

1

Но данный параметр закоменчен

Т.е. по дефолту.

Хм... Это меньше всего, что я ожидал

По дефолту 0 вроде... А какая ось?

Centos7

https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

Дефолт 0

Вообще в постресовой рассылке рекомендуют 2

Только vm.overcommit_ratio не забудте поправить

Прошу прощения, сразу не указал ошибки в логах: Server process was terminated by signal 11: Segmentation fault

Версия Постгреса 9.6.4

И в доке пишут : 17.4.3. Linux Memory Overcommit On Linux 2.6 and later, it is possible to modify the kernel's behavior so that it will not "overcommit" memory. Although this setting will not prevent the OOM killer from being invoked altogether, it will lower the chances significantly and will therefore lead to more robust system behavior. This is done by selecting strict overcommit mode via sysctl: sysctl -w vm.overcommit_memory=2 https://www.postgresql.org/docs/9.3/static/kernel-resources.html

Прошу прощения, сразу не указал ошибки в логах: Server process was terminated by signal 11: Segmentation fault

Погуглите эту ошибку в рассылке и увидите про vm.overcommit_memory=2

Погуглите эту ошибку в рассылке и увидите про vm.overcommit_memory=2

Да, видел, но там было про 9.6.1

@dmitrykremer , у человека постгрес начал падать после обновления. До обновления, насколько я понял, всё было в порядке. Если так - вакуум фулл на весь инстанс, и молиться, чтобы оный вакуум не свалился.

Могу ещё больше подробностей показать, только скажите какие именно))

У меня такая же ошибка была при обновлении 9.4.5 на 9.4.12. Видимо в какой-то момент PG стал более чуствителен к этому параметру

RHEL 6

Стоп, уважаемые коллеги. Оверкоммит - оно же от оомкиллера. А у человека - сегфолт.

Посмотрел, оверкоммит мемори был 1, поставил 2.

Overcommit ratio оставил 50

Я бы не меньше 70 поставил.

У вас кроме постгреса есть на этом хосте что-то?

вы лучше посмотрите на чем сегфолт

На серваке 252гб памяти, из них занято 82

вы лучше посмотрите на чем сегфолт

Простите, как?

смотрите логи

Ratio выставил в 70

https://www.postgresql.org/message-id/20170207135635.1411.1311@wrigleys.postgresql.org

Вчера обновились до 9.6 через pglogical.

DROP EXTENSION pglogical;

После обновления делали?

https://www.postgresql.org/message-id/20170207135635.1411.1311@wrigleys.postgresql.org

Уже читал..

А вот дроп расширения не делал

Они вам зачем уже после обновления?

Они вам зачем уже после обновления?

Уже удалил.

Из прелоад тоже и перезагружайтесь.

кстати, граждане постгресоиды, объясните пожалуйста. вот эти ссылки на номера багов, которые периодически встречаются в pgsql-bugs и надписи "The following bug has been logged on the website" они к чему относятся? на каком вебсайте и где можно весь список посмотреть?

Из прелоад тоже и перезагружайтесь.

Я про это shared_preload_libraries = 'pglogical'

кстати, граждане постгресоиды, объясните пожалуйста. вот эти ссылки на номера багов, которые периодически встречаются в pgsql-bugs и надписи "The following bug has been logged on the website" они к чему относятся? на каком вебсайте и где можно весь список посмотреть?

это сообщения, которые отправляются из этой формы https://www.postgresql.org/account/submitbug/

Я про это shared_preload_libraries = 'pglogical'

Убрал и рестартанул

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

это сообщения, которые отправляются из этой формы https://www.postgresql.org/account/submitbug/

спасибо! т.е. список получить нельзя и багтрекера как тового нет?

DROP EXTENSION pglogical;

какое, однако, "полезное" расширение. Я прям весь из себя умилился, погрузившись в нирвану восторга. :(

спасибо! т.е. список получить нельзя и багтрекера как тового нет?

багтрекера нет. Про список не знаю, возможно где-то есть, но на postgresql.org, насколько знаю нет. Можно только искать в списке рассылки https://www.postgresql.org/list/pgsql-bugs/

багтрекера нет. Про список не знаю, возможно где-то есть, но на postgresql.org, насколько знаю нет. Можно только искать в списке рассылки https://www.postgresql.org/list/pgsql-bugs/

спасибо

какое, однако, "полезное" расширение. Я прям весь из себя умилился, погрузившись в нирвану восторга. :(

Ты наверное в нирвану погружаешся и при DROP EXTENSION multimaster!

Стоп, уважаемые коллеги. Оверкоммит - оно же от оомкиллера. А у человека - сегфолт.

Signal 11 - это попытка доступа к несуществующей памяти. Прямое следствие оверкоммита

Ты наверное в нирвану погружаешся и при DROP EXTENSION multimaster!

Я бы точно в нирвану погрузился. Ибо уровень хэйтинга мультимастера у меня зашкаливает.

спасибо! т.е. список получить нельзя и багтрекера как тового нет?

немного соврал, есть такой сайт https://commitfest.postgresql.org/14/ но это не совсем багтрекер

Чую щас кого-то бомбонет ;)

Signal 11 - это попытка доступа к несуществующей памяти. Прямое следствие оверкоммита

В моей практике попытки доступа к несуществующей памяти заканчивались оомкиллером. А сигнал 11 - это когда попытка несанкционированного доступа в область памяти.

@popovnv не поминай мультимастер всуе. А то я и так больной... :)

В моей практике попытки доступа к несуществующей памяти заканчивались оомкиллером. А сигнал 11 - это когда попытка несанкционированного доступа в область памяти.

На самом деле есть 2 варианта: 1) Память заканчивается, у приходит OOMKiller 2) Приложение обращается к облапсти памяти, которая уже переназначена другому процессу. В результате segfault или SIGSEGV он же signal 11

А вообще, кто-нибудь использовал логическую репликацию для "бесшовного" обновления? Стоит оно того? pg_upgrade -k разве не закрывает 99% случаев?

а как это, "область памяти, которая переназначена другому процессу", если у каждого процесса своё адресное пространство?

А вообще, кто-нибудь использовал логическую репликацию для "бесшовного" обновления? Стоит оно того? pg_upgrade -k разве не закрывает 99% случаев?

Я использовал, даунтайм составил больше, чем в прошлый раз с 9.4 до 9.5 через pg-upgrade

Так что, до 10 буду через pg-upgrade

а как это, "область памяти, которая переназначена другому процессу", если у каждого процесса своё адресное пространство?

Есть ещё разделяемая память

ERROR: S client not available

немного соврал, есть такой сайт https://commitfest.postgresql.org/14/ но это не совсем багтрекер

ok. ну да, это скорее патч трекер

Есть ещё разделяемая память

есть. и как это к ней относится?

Простите, как?

Раскопать core файл оставшийся от процесса и скормить его gdb

Возможно доставить пакет c debug-символами от postgres чтобы core-файл стал понятнее

а как это, "область памяти, которая переназначена другому процессу", если у каждого процесса своё адресное пространство?

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

Раскопать core файл оставшийся от процесса и скормить его gdb

Ты наверно пошутил, да? По умолчанию PG разве создаёт корки!?

а как это, "область памяти, которая переназначена другому процессу", если у каждого процесса своё адресное пространство?

Адресное пространство и выделение памяти - разные операции и разные системные вызовы в ядре. Сначала память выделяется, а потом мапится в адресное пространство процесса. Если сегмент памяти освобожден, а к нему обращаются - обращающийся процесс сегфолтится.

Ты наверно пошутил, да? По умолчанию PG разве создаёт корки!?

Это скорее свойство конкретного сорта Linux'а. Оно не зависит от csegfault'ившегося приложения. Но в современном Linux core-файлы добываются оень через жопу

PG не создаёт корки, потому что никогда не падает

Это скорее свойство конкретного сорта Linux'а. Оно не зависит от csegfault'ившегося приложения. Но в современном Linux core-файлы добываются оень через жопу

Если коротко, то их просто нет ;)

Они есть. Но их надо включать. https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Enabling_core_dumps

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

ну, тут всё верно. и просто большинство софта никак не обрабатывают ошибку записи в память, когда ядру неоткуда взять новую страничку, потому что освобождаемой памяти нет. но не "обращается к области памяти, назначенной другому процессу", как @dmitrykremer говорит.

Они есть. Но их надо включать. https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Enabling_core_dumps

а если их выключить, как дебажить креши? :)

Они есть. Но их надо включать. https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Enabling_core_dumps

Да это понятно! Но кто в здравом уме будет это делать :)

ну, тут всё верно. и просто большинство софта никак не обрабатывают ошибку записи в память, когда ядру неоткуда взять новую страничку, потому что освобождаемой памяти нет. но не "обращается к области памяти, назначенной другому процессу", как @dmitrykremer говорит.

думаю, что @dmitrykremer говорил о физической, а не виртуальной памяти, в этом смысле всё верно

Так и не надо выключать :)

думаю, что @dmitrykremer говорил о физической, а не виртуальной памяти, в этом смысле всё верно

если одному процессу удалось из-за только одного оверкоммита залезть в память другого процесса, то это баг MMU.

должен получиться page fault, и его OS должна обработать, постаравшись замапить страницу

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

Вопрос, когда возникает seqfault, а когда срабатывает oomkiller.

если одному процессу удалось из-за только одного оверкоммита залезть в память другого процесса, то это баг MMU.

не о том речь. ядро обещает выдать физическую память при malloc() (точнее mmap()). которую потом может отдать другим процессам. естественно, страницы физической памяти инициализируются перед тем, как передать другому процессу

должен получиться page fault, и его OS должна обработать, постаравшись замапить страницу

да, то есть если физическую память не получилось замапить, получается segfault. а замапить может не получиться, потому что обещанная физическая память отдана другому процессу.

обещанной памяти могло не существовать в принципе :)

обещанной памяти могло не существовать в принципе :)

и это тоже верно

Вопрос, когда возникает seqfault, а когда срабатывает oomkiller.

oomkiller — это background процесс, задача которого минимизировать segfault-ы, вызванные overcommit-ом

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

https://github.com/torvalds/linux/blob/9967468c0a109644e4a1f5b39b39bf86fe7507a7/mm/oom_kill.c

даже https://github.com/torvalds/linux/blob/9967468c0a109644e4a1f5b39b39bf86fe7507a7/mm/oom_kill.c#L1070

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

это бекграунд процесс в том смысле, что оно действует асинхронно по отношению к user-space процессам. его задача — поддерживать некоторый low water mark, чтобы сегфолты про замапливании страниц происходили реже

A segmentation fault means a program tried to access an invalid or illegal memory address: for example, 0, or a value larger than any valid pointer. A page fault is when a pointer tries to access a page of address space that's currently not mapped onto physical memory, so that the MMU needs to grab it off of disk before it can be used. The former is an illegal condition and the program will generally be aborted; the latter is perfectly normal and the program won't even know about it. https://stackoverflow.com/questions/6950549/segmentation-fault-vs-page-fault

segfault != pagefault

это бекграунд процесс в том смысле, что оно действует асинхронно по отношению к user-space процессам. его задача — поддерживать некоторый low water mark, чтобы сегфолты про замапливании страниц происходили реже

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

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