Верно, был не прав. Сам компилятор никак не влияет и все моменты которые обсудили в https://postgrespro.com/list/thread-id/2634776 надо детальнее изучать и исправлять. И про memory barrier и про фряху и прочее.
Тогда может и приземлится PGO/LTO в PG. :) Спасибо большое за комментарий!
Для конечного пользователя это всё таки одна база данных, даже одна таблица, размером в петабайт. Но и верно что ресурсно это разбросано на 7 серверов, как с точки зрения дисков, так и с точки зрения процессоров.
14 серверов и 2ПБ vs 7 серверов и 1ПБ мы конечно не сравнивали, в теории конечно можно конечно оптимистично говорить что будет похожее, но уверен что там тоже будут интересные погружения в rabbit holes. Как минимум чем больше нод, тем больше интерконнектов на каждой ноде и т.п.
Такие OLTP базы есть, в основном это высоконагруженные системы, где данные прилетают массово. К примеру платежи, посылки, realtime rating и charging и прочие. Во многих таких системах важно хранить данные за долгие годы.
По некоторой инфе есть в РФ инстансы на GreenPlum-е с 6 петабайтами данных (не знаю что за природа базы, но это даже не self-hosted, а на арендованных серверах).
Можно конечно пилить на несколько баз, но зачем - это только усложняет доступы. Надо менеджить уже не одну единицу, а несколько.
Бекапы делаются инкрементальные, конечно не надо каждый час и день делать полную копию. Раз в месяц сделать полный бекап за сутки возможно, а дальше только собирать инкременты. Это рабочая стратегия.
Суть простая - такие базы существуют, их мало, но они есть.
Хотели поисследовать это как и LTO, и знаем что на простых тестах это даёт некоторый процент выйгрыша. Но вот в базах данных зачастую производительность задаётся не только оптимильным набором инструкций, но ещё сложность алгоритмов обработки информации и пределами масштабирования на горячих данных (блокировках). Поэтому PGO/LTO - вещи хорошие, со своими минусами и багами (PGO насколько помню вносит требование что расширения тоже должны быть собраны таким же или особым способом), но лучше boost производительности дают именно улучшения кода с точки зрения алгоритмов и lock-free вещей.
Тогда fine tuning нам даже и не пришло в голову делать - задача не стояла так. Надо бы конечно покрутить планами, со стороны утилиты мы точно используем расширенный протокол. Скорее всего generic слишком дорогой, вот он и постоянно кастомы строит. Можно попробовать конечно force_generic. Думаешь стоит?
Вот это ещё одна загадка, до которой мы не успели докапаться на том оборудовании. В целом на других тестах мы не наблюдали такой большой разницы.
Более того, в случаи с межсерверным обращением, утилизация процессора увеличивается на промежуточном сервере на 50%, что тоже неожиданно. По диску разницы не вижу, там одинаковый набор читался. И явно по сети не вижу проблем.
Мы повторим тесты на своём оборудовании и разберемся. Не могу сказать что это ошиюка архитектуры, вполне возможно что это ошибка установки, настроек, релиза или в другом любом рандомном месте. Задача заведена и попробуем её сделать в ближайшее время.
Хорошо конечно без многоверсионности, но современная армия разработчиков настолько привыкла к режиму изоляции Read Committed, что другого ничего и слышать не хочет (не все, есть и любители Repeatable Read). Вот версионнирование и нужно чтобы делать Read Committed/Repeatable Read.
По поводу хранения версий - так без этого никак, надо откуда получать данные из прошлого. В Оракле - это UNDO сегмент, в PostgreSQL - это несколько версий строк.
Vacuum бесспорно вещь неприятная. Но его можно научиться готовить, хотя серебряной пули увы нет.
В PostgresPro Multimaster использует 3PC (ещё одна фаза добавляется из-за RAFT-а).
И да: в этом случаи будет распределенный deadlock, поскольку при коммитах транзакций (а они обе дойдут беспрепятственно до коммита) изменения попробуют зареплицироваться между нодами и поймают блокировки. И тогда сработает deadlock detector. Но можно deadlock-а избежать через параметр multimaster.deadlock_prevention : https://postgrespro.ru/docs/enterprise/13/multimaster#MTM-DEADLOCK-PREVENTION . Это быстрее работает чем ожидание дедлока и его разрешение.
Другими словами в итоге либо будет 1 COMMIT+1ROLLBACK или 2 ROLLBACK-а
Понимаю эту боль. Когда всё разъехалось - это адовая боль.
Но если получится сломать PostgresPro Multimaster (виртуалка с ним выше доступна в самой статье), то прошу дать знать. Не говорю, что это сделать нельзя, но заложенный 3PC в него выглядит пока довольно прочно и в эксплуатации с проблемами к нам не приходили.
На Slave-е можно только читать. Там нельзя создать даже временной таблицы. А иногда хочется создать временные таблицы при формировании временного отчёт.
Моё личное ощущение что мультимастер прекрасен свой отказоустойчивостью:
Не надо думать где реплика а где мастер и городить балансировщики аля HAProxy
Не надо переживать за недоступность сервиса пока реплика будет превращаться в мастер при failover/switchover
Не надо думать в каком порядке обновлять базы и как обновлять. Особенно с учётом major upgrade
Два события похоже что связаны, но стоит разобраться что это. Обычно в dmesg сваливается информация о краше, одна строчка. На неё бы взглянуть. Наверно лучше в личку :)
Частый DDL для временных таблиц в любом случаи зло. Это и посылка сообщений об инвалидациях (даже fast_truncate посылает инвалидацию) и замусоривание таблиц системного каталога (от этого увы никуда не деться). Стоит отметить что внутри ядра PostgreSQL инвалидации нужны не только для того, чтобы информировать другие подключения, но ещё к примеру откатить изменения системного каталога в текущем процессе при ROLLBACK-е.
ZFS CoW снепшот атомарен, моментален, не вызывает деградации производительности и не требует больших расходов. Гарантии есть.
В чём плюс такой схемы с ZFS снепшотам, что можно восстановиться на любой момент времени. Выбирается точка во времени, откатывается на снепшот перед точкой, а потом добираются WAL-ы которые лежат в следующем снепшоте. И делается recovery.
А и про бекапы - снепшоты инкрементально отправляются в СРК или на реплику ZFS-а через zfs send/receive. То есть можно держать 100500 снепшотов в СРК, а на мастере хранить за последние сутки.
А вот реплика - это не совсем безкап ибо она не позволяет восстановиться на точку в прошлом. Если кто-то дропнул таблицу или зашифровал ключевые блоки, то реплика окажется также поломанной.
Симптомы бывают одни, а реально болит в совсем другом месте. И да, много проблем решается обновлением того или иного. Но чтобы найти что обновлять (а вариантов тут может быть слишком много включая железо), придётся разобраться в деталях происходящего. На первый взгляд описание тикета ZFS не имеет ничего общего с симптомами в PostgreSQL, а вот как оно вышло.
Верно, был не прав. Сам компилятор никак не влияет и все моменты которые обсудили в https://postgrespro.com/list/thread-id/2634776 надо детальнее изучать и исправлять. И про memory barrier и про фряху и прочее.
Тогда может и приземлится PGO/LTO в PG. :) Спасибо большое за комментарий!
Для конечного пользователя это всё таки одна база данных, даже одна таблица, размером в петабайт. Но и верно что ресурсно это разбросано на 7 серверов, как с точки зрения дисков, так и с точки зрения процессоров.
14 серверов и 2ПБ vs 7 серверов и 1ПБ мы конечно не сравнивали, в теории конечно можно конечно оптимистично говорить что будет похожее, но уверен что там тоже будут интересные погружения в rabbit holes. Как минимум чем больше нод, тем больше интерконнектов на каждой ноде и т.п.
Такие OLTP базы есть, в основном это высоконагруженные системы, где данные прилетают массово. К примеру платежи, посылки, realtime rating и charging и прочие. Во многих таких системах важно хранить данные за долгие годы.
По некоторой инфе есть в РФ инстансы на GreenPlum-е с 6 петабайтами данных (не знаю что за природа базы, но это даже не self-hosted, а на арендованных серверах).
Можно конечно пилить на несколько баз, но зачем - это только усложняет доступы. Надо менеджить уже не одну единицу, а несколько.
Бекапы делаются инкрементальные, конечно не надо каждый час и день делать полную копию. Раз в месяц сделать полный бекап за сутки возможно, а дальше только собирать инкременты. Это рабочая стратегия.
Суть простая - такие базы существуют, их мало, но они есть.
Хотели поисследовать это как и LTO, и знаем что на простых тестах это даёт некоторый процент выйгрыша. Но вот в базах данных зачастую производительность задаётся не только оптимильным набором инструкций, но ещё сложность алгоритмов обработки информации и пределами масштабирования на горячих данных (блокировках). Поэтому PGO/LTO - вещи хорошие, со своими минусами и багами (PGO насколько помню вносит требование что расширения тоже должны быть собраны таким же или особым способом), но лучше boost производительности дают именно улучшения кода с точки зрения алгоритмов и lock-free вещей.
О, а pg_hint_plan так умеет делать? Было бы прикольно
Тогда fine tuning нам даже и не пришло в голову делать - задача не стояла так. Надо бы конечно покрутить планами, со стороны утилиты мы точно используем расширенный протокол. Скорее всего generic слишком дорогой, вот он и постоянно кастомы строит. Можно попробовать конечно force_generic. Думаешь стоит?
Вот это ещё одна загадка, до которой мы не успели докапаться на том оборудовании. В целом на других тестах мы не наблюдали такой большой разницы.
Более того, в случаи с межсерверным обращением, утилизация процессора увеличивается на промежуточном сервере на 50%, что тоже неожиданно. По диску разницы не вижу, там одинаковый набор читался. И явно по сети не вижу проблем.
Мы повторим тесты на своём оборудовании и разберемся. Не могу сказать что это ошиюка архитектуры, вполне возможно что это ошибка установки, настроек, релиза или в другом любом рандомном месте. Задача заведена и попробуем её сделать в ближайшее время.
Хорошо конечно без многоверсионности, но современная армия разработчиков настолько привыкла к режиму изоляции Read Committed, что другого ничего и слышать не хочет (не все, есть и любители Repeatable Read). Вот версионнирование и нужно чтобы делать Read Committed/Repeatable Read.
Верно, в PostgresPro Multimaster используется PAXOS, не RAFT. Я ошибся в своём комментарии выше.
Репликация синхронная, 2PC накладывает свои расходы. Это как раз описано в третьей части данной серии статей: https://habr.com/ru/companies/postgrespro/articles/793158/
По поводу хранения версий - так без этого никак, надо откуда получать данные из прошлого. В Оракле - это UNDO сегмент, в PostgreSQL - это несколько версий строк.
Vacuum бесспорно вещь неприятная. Но его можно научиться готовить, хотя серебряной пули увы нет.
В PostgresPro Multimaster использует 3PC (ещё одна фаза добавляется из-за RAFT-а).
И да: в этом случаи будет распределенный deadlock, поскольку при коммитах транзакций (а они обе дойдут беспрепятственно до коммита) изменения попробуют зареплицироваться между нодами и поймают блокировки. И тогда сработает deadlock detector. Но можно deadlock-а избежать через параметр
multimaster.deadlock_prevention: https://postgrespro.ru/docs/enterprise/13/multimaster#MTM-DEADLOCK-PREVENTION . Это быстрее работает чем ожидание дедлока и его разрешение.Другими словами в итоге либо будет 1 COMMIT+1ROLLBACK или 2 ROLLBACK-а
Понимаю эту боль. Когда всё разъехалось - это адовая боль.
Но если получится сломать PostgresPro Multimaster (виртуалка с ним выше доступна в самой статье), то прошу дать знать. Не говорю, что это сделать нельзя, но заложенный 3PC в него выглядит пока довольно прочно и в эксплуатации с проблемами к нам не приходили.
На Slave-е можно только читать. Там нельзя создать даже временной таблицы. А иногда хочется создать временные таблицы при формировании временного отчёт.
Моё личное ощущение что мультимастер прекрасен свой отказоустойчивостью:
Не надо думать где реплика а где мастер и городить балансировщики аля HAProxy
Не надо переживать за недоступность сервиса пока реплика будет превращаться в мастер при failover/switchover
Не надо думать в каком порядке обновлять базы и как обновлять. Особенно с учётом major upgrade
del
"Problem sovled!"
Апечатки по Фрейду!
Два события похоже что связаны, но стоит разобраться что это. Обычно в dmesg сваливается информация о краше, одна строчка. На неё бы взглянуть. Наверно лучше в личку :)
Частый DDL для временных таблиц в любом случаи зло. Это и посылка сообщений об инвалидациях (даже fast_truncate посылает инвалидацию) и замусоривание таблиц системного каталога (от этого увы никуда не деться). Стоит отметить что внутри ядра PostgreSQL инвалидации нужны не только для того, чтобы информировать другие подключения, но ещё к примеру откатить изменения системного каталога в текущем процессе при ROLLBACK-е.
Конечно же. Спасибо большое! Текст поправил.
ZFS CoW снепшот атомарен, моментален, не вызывает деградации производительности и не требует больших расходов. Гарантии есть.
В чём плюс такой схемы с ZFS снепшотам, что можно восстановиться на любой момент времени. Выбирается точка во времени, откатывается на снепшот перед точкой, а потом добираются WAL-ы которые лежат в следующем снепшоте. И делается recovery.
А и про бекапы - снепшоты инкрементально отправляются в СРК или на реплику ZFS-а через zfs send/receive. То есть можно держать 100500 снепшотов в СРК, а на мастере хранить за последние сутки.
А вот реплика - это не совсем безкап ибо она не позволяет восстановиться на точку в прошлом. Если кто-то дропнул таблицу или зашифровал ключевые блоки, то реплика окажется также поломанной.
Симптомы бывают одни, а реально болит в совсем другом месте. И да, много проблем решается обновлением того или иного. Но чтобы найти что обновлять (а вариантов тут может быть слишком много включая железо), придётся разобраться в деталях происходящего. На первый взгляд описание тикета ZFS не имеет ничего общего с симптомами в PostgreSQL, а вот как оно вышло.