так делать нельзя, в общем случае

а так делают. и postgres, я уверен, тоже

много лет назад я написал отладочный код в mysql, позволяющий такие случаи отлавливать и покрывать тесткейсами

а так делают. и postgres, я уверен, тоже

Это не совсем так. Есть память, выделяемая напрямую при помощи malloc, но таких мест мало. Для всего остального используется обвязка palloc, которая умеет вот так: if (ret == NULL) { MemoryContextStats(TopMemoryContext); ereport(ERROR, (errcode(ERRCODE_OUT_OF_MEMORY), errmsg("out of memory"), errdetail("Failed on request of size %zu.", size))); }

Похожая обвязка есть и в mysql. Тем не менее, баги такого типа всплывают до сих пор

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

не очень понятно что это демонстрирует. Можно было сразу ноль разыменовать) Если добавить проверку на null, то сегфолта не будет

Так выше обсудили

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

про баги ок, но утверждение "segfault невозможен при исчерпании процессом физической памяти и swap'а" это не опровергает, так?

@alexey_kopytov ваш случай демонстрирует ошибку разраба, я же всё-таки имел в виду segfault независимо от него

Так ведь возможен?

Ну значит я неправильно понял вопрос

В коде pg проверки как правило стоят после malloc

в коде mysql тоже. "как правило" — ключевые слова

Создавал кластер в /var/, теперь стало мало места. Есть место в хомяке. Я могу как-то перенести старые базы из /var?

Создавал кластер в /var/, теперь стало мало места. Есть место в хомяке. Я могу как-то перенести старые базы из /var?

можешь!

можешь!

ага, я уже нашел)

?

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

Промышленного решения нет. Учите своё приложение r/o запросы посылать на реплику.

Промышленного решения нет. Учите своё приложение r/o запросы посылать на реплику.

Спасибо.

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

Спасибо тебе, друХ! test@webdeb:~$ grep "^Max core file size" /proc/1927/limits Max core file size unlimited unlimited bytes test@webdeb:~$ grep LimitCORE /etc/systemd/system.conf DefaultLimitCORE=infinity test@webdeb:~$ Только не надо в юниты лезть, надо документацию читать. man systemd-system.conf однако! ЗЫ. А те, кто сидит на init-скриптах - страдайте, ага.

Спасибо тебе, друХ! test@webdeb:~$ grep "^Max core file size" /proc/1927/limits Max core file size unlimited unlimited bytes test@webdeb:~$ grep LimitCORE /etc/systemd/system.conf DefaultLimitCORE=infinity test@webdeb:~$ Только не надо в юниты лезть, надо документацию читать. man systemd-system.conf однако! ЗЫ. А те, кто сидит на init-скриптах - страдайте, ага.

для systemd мог бы сразу systemd-coredump поставить

Спасибо тебе, друХ! test@webdeb:~$ grep "^Max core file size" /proc/1927/limits Max core file size unlimited unlimited bytes test@webdeb:~$ grep LimitCORE /etc/systemd/system.conf DefaultLimitCORE=infinity test@webdeb:~$ Только не надо в юниты лезть, надо документацию читать. man systemd-system.conf однако! ЗЫ. А те, кто сидит на init-скриптах - страдайте, ага.

а зачем запускать postgresql через systemd или init? кто права такое дал на проде?

а зачем запускать postgresql через systemd или init? кто права такое дал на проде?

+1

а зачем запускать postgresql через systemd или init? кто права такое дал на проде?

у админа локалхоста с правами все ок

а зачем запускать postgresql через systemd или init? кто права такое дал на проде?

точно, на проде постгрес запускать не надо! :)

точно, на проде постгрес запускать не надо! :)

Прод вообще запускать не надо!

Его же ещё обслуживать необходимо. Ну и всё такое прочее...

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

pgpool?

pgpool?

он умеет сплитить запросы ?

ну да

ну да

Спасибо, буду читать

Посоветуйте плиз что-то под мультимастер или как лучше HA с автофайловером, фэйлбэком? Аля Galera что ли? Пришёл из мира mysql и что-то не разберусь

pgpool? ?

Pgpool же вроде не про это?

2й во всяком случае, если это разное

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

Я попробовал готовое решение с pgpool2+repmgr, но первый же тест провалился, фэйлбэк не проходит

мультимастер... была какая-то шняга - мы ее тестили - но это тихий ужас - еще хуже галеры ?

ну вот когда провалится 10й тест после обработки напильником - тогда и можно будет что-то говорить )

С синхронной репликацией не всё тау просто?

ну мы про мультимастер.. синхронная репликация в режиме одного мастера и слейвов работает чудесно

Но как и в случае с галерой - потеря на записи, я не найду цифры, она существенная? И чем вообще это организовывать

у нас было -35% по скорости ?

на 3х нодах

какой-то из стандартных тестов..tpc-чтото

Смотрю сейчас Stolon как готовое решение, из минусов пока только - не умеет балансировку

ок.. с тебя success story ?

Такой себе с меня рассказчик, я думаю в 2017 есть кому такое рассказывать))

Посоветуйте плиз что-то под мультимастер или как лучше HA с автофайловером, фэйлбэком? Аля Galera что ли? Пришёл из мира mysql и что-то не разберусь

Готовых решений НЕТ. Есть некоторое количество связок на сторонних продуктах. Про мультимастер луТше забыть сразу. Совсем.

Готовых решений НЕТ. Есть некоторое количество связок на сторонних продуктах. Про мультимастер луТше забыть сразу. Совсем.

Понял, спасибо

нету мультимастера в классических sql. и не завезут.

В мускле же есть

Вот, посмотрите, что предлагает коллективный разум: https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

да, я видел это и по каждому отдельно читал. Но читать одно =\

Покрутите пару-другую дней назад по чатЕГу, там Игорь Успенский говорил об одной из связок. Лично я делал в своё время на heartbeat-е (во времена 5-го Деба и 4-й ЦентОСи), видел на corosync+pacemaker.

Покрутите пару-другую дней назад по чатЕГу, там Игорь Успенский говорил об одной из связок. Лично я делал в своё время на heartbeat-е (во времена 5-го Деба и 4-й ЦентОСи), видел на corosync+pacemaker.

ну вопрос больше про репликацию\синхронизацию. heartbeat\corosync же про доступность

https://github.com/zalando/patroni https://github.com/sorintlab/stolon вот сейчас буду тестить, хз что выйдет

В мускуле? мультимастер? Откуда он там?)

В мускле же есть

нету

двухфазный коммит не работает в распределенной системе

это обман, чтобы набрать классы

мультимастер не возможен без арбитра/координатора

паксос позволяет

Это вы про гугл что ли с их Big Table?)

В F1/Spaner paxos для репликации шарда и 2pc для меж-шардовых транзакций, если мне память не изменяет.

мультимастер не возможен без арбитра/координатора

ну вот если бы у Вас в фамилии пару букв поменять, я бы даже спорить не стал, а так поспорю за арбитров - он не всегда необходим

ERROR: S client not available

CRDT (conflict-free replicated data type)?

Расширенный трех-фазный коммит может комитить кворумом.

Очень похожий алгоритм - paxos commit от Лампорта.

а что в этом случае будет с перфомансом?

Мы выясняем вопрос, нужен ли арбитр.

Ответ: ноды сами могут собираться в "мини кластер" и принимать решение кворумом.

аля etcd, consul, zookeeper?

etcd и consul не принимают решение кворумом

принимает решение лидер. Но кворум должен быть

У этих товарище одинаковая архитектура: кворумная репликация от мастера к репликам одних и тех же данных алгоритмом семейства paxos (raft, zab - в принципе изоморфны друг другу)

Двух фазный, трех фазный коммиты - это про изменение несколькими мастерами разных (в общем случае, но может и одних и тех же) данных

Это вы проводите исследование в pgpro мультимастере?

Нет. Его пишут другие ребята (по умнее меня). Я просто болтаю с ними, и почитываю литературу.

ок, спасибо за инфу)

В общем, лучшее - враг хорошего.

Мастер падал вместе со слейвами на одном определенном запросе.

Причина была в новом параметре 9.6 max-paralles-workers-per-gather

У нас был выставлен в 16

При общем количестве ядер 24

Отключив данный параметр, все стало прекрасно.

Теперь вопрос, у кого и как используется данный параметр параллелизма?

Теперь вопрос, у кого и как используется данный параметр параллелизма?

https://postgrespro.ru/docs/postgresql/9.6/parallel-query.html

15.1. Как работают параллельно выполняемые запросы https://postgrespro.ru/docs/postgresql/9.6/how-parallel-query-works.html Используя EXPLAIN, вы можете узнать количество исполнителей, выбранное планировщиком для данного запроса. Когда при выполнении запроса достигается узел Gather, процесс, обслуживающий сеанс пользователя, запрашивает фоновые рабочие процессы в этом количестве. Общее число фоновых рабочих процессов, которые могут существовать одновременно, ограничивается параметром max_worker_processes, так что вполне возможно, что параллельный запрос будет выполняться меньшим числом рабочих процессов, чем планировалось, либо вообще без дополнительных рабочих процессов. Оптимальность плана может зависеть от числа доступных рабочих процессов, так что их нехватка может повлечь значительное снижение производительности. Если это наблюдается часто, имеет смысл увеличить max_worker_processes, чтобы одновременно могло работать больше процессов, либо уменьшить max_parallel_workers_per_gather, чтобы планировщик ожидал их наличия в меньшем количестве.

RTFM в общем.

RTFM в общем.

Т.е. Вы хотите сказать, что max-worker-processes 10 при max-parallel-workers-per-gather 16 это моветон?

Всё зависит от криворукости того кто проектировал схему: какие у вас запросы выполняются и какие применяются блокировки - используйте explain что бы понять почему у вас происходит ожидание освобождения рабочих потоков для КОНКРЕТНОГО запроса.

Я не думаю что мне стоит объяснять как читать документацию и следовать её указаниям.

В целом число worker'ов не обязательно должно равняться количеству ядер умноженному на два - это работает только в случае с thread pool'aми и прочими примитивами в общепринятых многопоточных решениях. В PostgreSQL'e блокировки происходят довольно часто, по разным причинам, по этому при определении оптимального числа Worker'ов нужно брать во внимание особенности работы существующих паралельных запросов.

Отключив данный параметр, все стало прекрасно.

очень странно. хитрые сишные функции в запросе есть?

очень странно. хитрые сишные функции в запросе есть?

Неа

При значении max- parallel-workers-per-gather 4, полет нормальный, уже в течение часа.

оно не должно крешиться при любых сочетаниях этих параметров