Комментарии 44
Класс! Это чисто экспериментальные патчи, или в каком-то виде будут внедрены в будущих версиях?
А у вас есть стоядерный сервер?)
я так понимаю это даст прирост на любой среде где количество процессов больше чем количество ядер. Чем плохо?
Этот патч ускорит доступ к часто-используемым страницам в условиях конкрентного доступа. На многоядерных серверах просто увеличивается вероятность данного события.
На самом деле специфика конкретной аппаратной платформы, как оказалось, сильно влияет. Некоторые из оптимизаций, которые дали солидный выигрыш на Power 8, не дают ничего (или дают очень мало) на Intel. Но об этом мы подробно расскажем отдельно.
Сообщество PostgreSQL, по понятным причинам, очень ревностно относится к подобным изменениям. Но обсуждения в pgsql-hackers уже проходят. Пока патчи один за одним улучшают производительность.
Спасибо за статью и за проделанную работу по оптимизации )
Freund должно читаться как «Фройнд».
«Распределенные системы менее гибки, чем монолитные, к тому же они сложнее в эксплуатации и требуют более высокой квалификации персонала.» — вот с этим высказыванием категорически не согласен, на мой взгляд, всё как раз наоборот — обслуживание мэйнфрейма требует специальных знаний, в отличие от сети дешёвых персоналок.
По самому продукту, мне кажется, за средства SQL, расширяемости, надёжности PostGres можно поставить 5-ку, но, как бы, в 2015 (2015, Карл!) году когда даже в десктопах торчат по 6-8 ядер, обрабатывать клиентский запрос ОДНИМ потоком… Мягко говоря, вызывает недоумение. В DWH типичный сценарий — один или несколько пользователей с долгими запросами. Почему клиент IBM с 512 ядрами должен ожидать, пока запрос будет выполняться в 1 поток?????
Далее. Без automatic standby failover это просто несерьёзное решение. Отсутствие партицирования — тоже огромный недостаток. Передайте Андресу: спасибо, конечно, но они там что, в мире одноядерников живут??? :-)
Freund должно читаться как «Фройнд».
«Распределенные системы менее гибки, чем монолитные, к тому же они сложнее в эксплуатации и требуют более высокой квалификации персонала.» — вот с этим высказыванием категорически не согласен, на мой взгляд, всё как раз наоборот — обслуживание мэйнфрейма требует специальных знаний, в отличие от сети дешёвых персоналок.
По самому продукту, мне кажется, за средства SQL, расширяемости, надёжности PostGres можно поставить 5-ку, но, как бы, в 2015 (2015, Карл!) году когда даже в десктопах торчат по 6-8 ядер, обрабатывать клиентский запрос ОДНИМ потоком… Мягко говоря, вызывает недоумение. В DWH типичный сценарий — один или несколько пользователей с долгими запросами. Почему клиент IBM с 512 ядрами должен ожидать, пока запрос будет выполняться в 1 поток?????
Далее. Без automatic standby failover это просто несерьёзное решение. Отсутствие партицирования — тоже огромный недостаток. Передайте Андресу: спасибо, конечно, но они там что, в мире одноядерников живут??? :-)
Спасибо за комментарий!
1. Почему вы заявляете о том, что в PostgreSQL нет партиционирования? Если вам это интересно почитайте про наследование в PostgreSQL.
2. Решений «automatic standby failover» столько же, сколько предложено HA, встроенные инструменты PostgreSQL позвляют это делать. Да, это требует более высокой квалификации от обслуживающего персонала, но в отличие от других комерческих СУБД PostgreSQL предоставляет тут свободу выбора.
1. Почему вы заявляете о том, что в PostgreSQL нет партиционирования? Если вам это интересно почитайте про наследование в PostgreSQL.
2. Решений «automatic standby failover» столько же, сколько предложено HA, встроенные инструменты PostgreSQL позвляют это делать. Да, это требует более высокой квалификации от обслуживающего персонала, но в отличие от других комерческих СУБД PostgreSQL предоставляет тут свободу выбора.
«1. Почему вы заявляете о том, что в PostgreSQL нет партиционирования? Если вам это интересно почитайте про наследование в PostgreSQL.»
Потому что в PostgreSQL нет партиционирования. Ну нет его. Схема, на которую вы указываете, это просто головная боль. Сравните с партицированием в Oracle.
2. хотелось бы multimaster replication with auto failover работающее из коробки, а не набор костылей, не поддерживающий новые версии ядра, не обновляемыей годами, работающий лишь на некоторых ОС и т.п.
3. Как я понял, с Вашей точки зрения в PostGres с обоими пунктами всё «зашибись»?
Потому что в PostgreSQL нет партиционирования. Ну нет его. Схема, на которую вы указываете, это просто головная боль. Сравните с партицированием в Oracle.
2. хотелось бы multimaster replication with auto failover работающее из коробки, а не набор костылей, не поддерживающий новые версии ядра, не обновляемыей годами, работающий лишь на некоторых ОС и т.п.
3. Как я понял, с Вашей точки зрения в PostGres с обоими пунктами всё «зашибись»?
1. В чем головная боль-то? Давайте поконкретнее
2. А еще чего бы вам хотелось? Все-таки standby failover — это одно и это есть в PG сто лет как, а multimaster replication — совсем другое.
3. С моей точки зрения (извините, что вмешиваюсь): по 1 — напишите, что вас не устраивает, т.к. для моих нужд там все зашибись, да; 2 — репликация (в общем смысле, не какой-то конкретный ее вид) — не сильная сторона PG, но в последнее время идет хорошее развитие в этом направлении, хотя и имхо с запозданием на x лет
2. А еще чего бы вам хотелось? Все-таки standby failover — это одно и это есть в PG сто лет как, а multimaster replication — совсем другое.
3. С моей точки зрения (извините, что вмешиваюсь): по 1 — напишите, что вас не устраивает, т.к. для моих нужд там все зашибись, да; 2 — репликация (в общем смысле, не какой-то конкретный ее вид) — не сильная сторона PG, но в последнее время идет хорошее развитие в этом направлении, хотя и имхо с запозданием на x лет
«1. В чем головная боль-то? Давайте поконкретнее»
www.postgresql.org/docs/devel/static/ddl-partitioning.html
потому что админу предлагается создавать все партиции, условия на таблицах, индексы вручную, что, я считаю, тупо. особо радуют «We must redefine the trigger function each month so that it always points to the current partition.», раздельный VAcuum для партиций, да и вообще весь раздел 5.10.6. Caveats.
Если Вам эти все действия в радость (вместо указания ключа и схемы партицирования при создании/модификации таблицы, как в Оракле) — вопросов не имею.
2. извиняюсь за неточность, имел в виду полный цикл standby failover, описанный как STONITH тут
www.postgresql.org/docs/devel/static/warm-standby-failover.html
3. радует, что подвижки идут, но очень уж мизерные.
с другой стороны, я, конечно, понимаю, что никто не держит, пиши свой движок или покупай Оракула за $50k /ядро ))
www.postgresql.org/docs/devel/static/ddl-partitioning.html
потому что админу предлагается создавать все партиции, условия на таблицах, индексы вручную, что, я считаю, тупо. особо радуют «We must redefine the trigger function each month so that it always points to the current partition.», раздельный VAcuum для партиций, да и вообще весь раздел 5.10.6. Caveats.
Если Вам эти все действия в радость (вместо указания ключа и схемы партицирования при создании/модификации таблицы, как в Оракле) — вопросов не имею.
2. извиняюсь за неточность, имел в виду полный цикл standby failover, описанный как STONITH тут
www.postgresql.org/docs/devel/static/warm-standby-failover.html
3. радует, что подвижки идут, но очень уж мизерные.
с другой стороны, я, конечно, понимаю, что никто не держит, пиши свой движок или покупай Оракула за $50k /ядро ))
1. Сделать человеческий партишининг есть в планах, но пока и без этого postgresql не хватает более важных вещей: awr, заморозка планов, трасировка…
Вот буквально вчера был внутренний семинар, где наш разработчик представил рабочее решение по статистике, которая предоставляется для планера и ее миграции в другие инстансы/версии postgresql.
Если не ошибаюсь, на прошлой неделе Юра Журавлев представил уже рабочее решение по прикреплению планов к конкретным запросам и экспорт на другие машины.
2. Нормальный фенсинг дает peacemaker, об этом был один из наших докладов на HL: http://www.slideshare.net/AlekseyChizhkoff/dancing-cluster, скоро будет рекомендованый пакеты. К сожалению, а может быть к счастью, встраивать такое решение в поставку с «базой» такое решение сообщество не пойдет. Дополнительно мы проталкиваем патчи такого рода: failover на уровне протокола клиента, read-only на уровне протокола.
Вот буквально вчера был внутренний семинар, где наш разработчик представил рабочее решение по статистике, которая предоставляется для планера и ее миграции в другие инстансы/версии postgresql.
Если не ошибаюсь, на прошлой неделе Юра Журавлев представил уже рабочее решение по прикреплению планов к конкретным запросам и экспорт на другие машины.
2. Нормальный фенсинг дает peacemaker, об этом был один из наших докладов на HL: http://www.slideshare.net/AlekseyChizhkoff/dancing-cluster, скоро будет рекомендованый пакеты. К сожалению, а может быть к счастью, встраивать такое решение в поставку с «базой» такое решение сообщество не пойдет. Дополнительно мы проталкиваем патчи такого рода: failover на уровне протокола клиента, read-only на уровне протокола.
А pg_partman не?
pg_partman is an extension to create and manage both time-based and serial-based table partition sets. Sub-partitoning is also supported. Child table & trigger function creation is all managed by the extension itself. Tables with existing data can also have their data partitioned in easily managed smaller batches. Optional retention policy can automatically drop partitions no longer needed. A background worker (BGW) process is included to automatically run partition maintenance without the need of an external scheduler (cron, etc) in most cases.
We must redefine the trigger function each month so that it always points to the current partition
Справедливости ради, это относится к их упрощенному примеру. Я еще много лет назад писал чуть более умную функцию (набор функций, точнее), которые и сами партиции создавали, и триггеры для них и т.п. В итоге мейнтенанс сводился к паре джобов в кроне. И кода было совсем немного.
>индексы вручную
кстати можно и так:
кстати можно и так:
postgres=# create table t (i int);
CREATE TABLE
postgres=# create index t_idx_i on t(i);
CREATE INDEX
postgres=# create table child_1_t (like t including indexes) inherits(t);
NOTICE: merging column "i" with inherited definition
CREATE TABLE
postgres=# \d+ child_1_t
Table "public.child_1_t"
Column | Type | Modifiers | Storage | Stats target | Description
--------+---------+-----------+---------+--------------+-------------
i | integer | | plain | |
Indexes:
"child_1_t_i_idx" btree (i)
Inherits: t
3. По поводу заявлений о расширяемости попробуйте, из «5-ку, но, как бы, в 2015»:
- утилизировать Xeon Phi, отправив туда паралельные вычисления
- создать новый тип данных без остановки сервера и описать его на C: индексы, операторы
- искать по схема-лесс данным по индексу через свой язык
1. какие проблемы с Phi? действуйте по образу и подобию
wiki.postgresql.org/wiki/PGStrom
2,3. не имеет существенного для меня значения, не возникало такой необходимости
навскидку, чем бинарное хранение в файловой системе не устраивает для 3?
wiki.postgresql.org/wiki/PGStrom
2,3. не имеет существенного для меня значения, не возникало такой необходимости
навскидку, чем бинарное хранение в файловой системе не устраивает для 3?
PGStrom очень сложная штука с большой кодовой базой, есть мысли, что это не верный путь.
> wiki.postgresql.org/wiki/PGStrom
я не говорил про конкретный проект. вы можете написать небольшой кусок кода, которую обвяжете в функцию, которую вы можете отправить на Phi.
>2,3. не имеет существенного для меня значения
Энтерпрайз до этого еще не дорос.
>чем бинарное хранение в файловой системе не устраивает для 3?
что вы имеете ввиду?
я не говорил про конкретный проект. вы можете написать небольшой кусок кода, которую обвяжете в функцию, которую вы можете отправить на Phi.
>2,3. не имеет существенного для меня значения
Энтерпрайз до этого еще не дорос.
>чем бинарное хранение в файловой системе не устраивает для 3?
что вы имеете ввиду?
> 1. какие проблемы с Phi? действуйте по образу и подобию PGStrom
Не думаю, что для Phi этот образ будет правильным путем.
В отличие от GPU Nvidia, Xeon Phi все время шел от ускорителя в сторону центрального процессора и с последней версии Knights Landing стал полноценным CPU, которому не нужен отдельный управляющий Xeon и медленная шина PCIe для обменов данными.
Следовательно, на мой взгляд, для максимально эффективного его использования параллелизм и использование SIMD инструкций необходимо внедрять на уровень штатного ядра, а не прицеплять сбоку рискуя потерять эффективность на архитектуре, рассчитанной на необходимость копирования данных в память ускорителя, что было нормальным решением при работе через шину и выглядит странно, когда все данные в общей памяти.
Не думаю, что для Phi этот образ будет правильным путем.
В отличие от GPU Nvidia, Xeon Phi все время шел от ускорителя в сторону центрального процессора и с последней версии Knights Landing стал полноценным CPU, которому не нужен отдельный управляющий Xeon и медленная шина PCIe для обменов данными.
Следовательно, на мой взгляд, для максимально эффективного его использования параллелизм и использование SIMD инструкций необходимо внедрять на уровень штатного ядра, а не прицеплять сбоку рискуя потерять эффективность на архитектуре, рассчитанной на необходимость копирования данных в память ускорителя, что было нормальным решением при работе через шину и выглядит странно, когда все данные в общей памяти.
И да, привет от ORA-600 ;)
«Распределенные системы менее гибки, чем монолитные, к тому же они сложнее в эксплуатации и требуют более высокой квалификации персонала.» — вот с этим высказыванием категорически не согласен, на мой взгляд, всё как раз наоборот — обслуживание мэйнфрейма требует специальных знаний, в отличие от сети дешёвых персоналок.
Если говорить про железо и ОС, то я согласен. Но если говорить про кластер БД, который обеспечивает строгую consistency, то один экземпляр БД администрировать намного проще. Но, конечно же, всё зависит от конкретной ситуации.
По самому продукту, мне кажется, за средства SQL, расширяемости, надёжности PostGres можно поставить 5-ку, но, как бы, в 2015 (2015, Карл!) году когда даже в десктопах торчат по 6-8 ядер, обрабатывать клиентский запрос ОДНИМ потоком… Мягко говоря, вызывает недоумение. В DWH типичный сценарий — один или несколько пользователей с долгими запросами. Почему клиент IBM с 512 ядрами должен ожидать, пока запрос будет выполняться в 1 поток?????
Работа над инфраструктурой для параллельного выполнения запросов ведётся уже давно. Лиха беда начало, уже есть первые результаты. И что важно, благодаря механизму Custom Nodes, можно будет различные способы распараллеливания добавлять в виде расширений, на pgconf.eu, например, уже демонстрировалось распараллеливание агрегатов.
Далее. Без automatic standby failover это просто несерьёзное решение.
В постгресе есть все необходимые средства для того, чтобы сверху можно было обеспечить High Availability(HA). Есть несколько «кластерных обвязок», которые обеспечивают HA на основе этих средств. Мы сейчас делаем свою, которая будет отличаться простотой настройки и администрирования, и будем осуществлять для неё вендорскую поддержку.
Отсутствие партицирования — тоже огромный недостаток.
Сейчас в постгресе принято использовать партицирование через наследование, что сопряжено с рядом недостатков. В частности, невозможность hash-партицирования, медленное планирование запросов при большом числе партиций и т.д. Но благодаря механизму Custom Nodes стало возможно обойти эти ограничения не трогая ядро. Мы сейчас работает над своим расширением для партицирования, которое будет лишено этих недостатков.
Спасибо за содержательный комментарий и разумную критику!
Новость про Parallel Seq Scan в, возможно, 9.6 — это круто! Пока приходится запрос разбивать на части вручную, создавая множество соединений с базой.
«В постгресе есть все необходимые средства для того, чтобы сверху можно было обеспечить High Availability(HA)» Нельзя не согласиться. Вот потому и удивляет, что не находят времени из коробки дописать логику failover-ов и heartbeat-ов и для этого приходится писать своё приложение.
«Сейчас в постгресе принято использовать партицирование через наследование» — по сути, никакого управления партицированием нет, всё надо делать вручную, даже обсуждать это не хочется — недостатки перевешивают потенциальные преимущества.
«В постгресе есть все необходимые средства для того, чтобы сверху можно было обеспечить High Availability(HA)» Нельзя не согласиться. Вот потому и удивляет, что не находят времени из коробки дописать логику failover-ов и heartbeat-ов и для этого приходится писать своё приложение.
«Сейчас в постгресе принято использовать партицирование через наследование» — по сути, никакого управления партицированием нет, всё надо делать вручную, даже обсуждать это не хочется — недостатки перевешивают потенциальные преимущества.
>Вот потому и удивляет, что не находят времени из коробки дописать логику failover-ов и heartbeat-ов и для этого приходится писать своё приложение
а отдавать по 50k $ за ядро вас не удивляет? :)
а отдавать по 50k $ за ядро вас не удивляет? :)
>всё надо делать вручную
у вас недостаточный опыт общения с PostgreSQL. откройте для себя экстеншены.
у вас недостаточный опыт общения с PostgreSQL. откройте для себя экстеншены.
Имеется ввиду pg_partman. Про то, что он имеет свои ограничения, мы знаем, работаем над этим. Про результаты на хабр напишем обязательно.
Freund должно читаться как «Фройнд»Точно, друг означает.
но, как бы, в 2015 (2015, Карл!) году когда даже в десктопах торчат по 6-8 ядер, обрабатывать клиентский запрос ОДНИМ потоком…
Уже сейчас можно писать расширения, которые могут пользовать несколько ядер. Hans-Jürgen Schönig скоро выпустит такое расширение (не трогая ядра базы!) для агрегатов, вот его пример:
agg=# SET agg.hash_workers = 1;
SET
Time: 0.269 ms
agg=# SELECT val1,
avg(id),
sum(id),
min(id),
max(id)
FROM t_agg
GROUP BY 1
LIMIT 2;
val1 | avg | sum | min | max
------+----------------------+----------------+-----+---------
34 | 2500014.000000000000 | 12500070000000 | 34 | 4999994
25 | 2500005.000000000000 | 12500025000000 | 25 | 4999985
(2 rows)
Time: 62983.545 ms
agg=# SET agg.hash_workers = 10;
SET
Time: 0.161 ms
agg=# SELECT val1,
avg(id),
sum(id),
min(id),
max(id)
FROM t_agg
GROUP BY 1
LIMIT 2;
val1 | avg | sum | min | max
------+----------------------+----------------+-----+---------
34 | 2500014.000000000000 | 12500070000000 | 34 | 4999994
25 | 2500005.000000000000 | 12500025000000 | 25 | 4999985
(2 rows)
Time: 8265.947 ms
Отсутствие партицирования — тоже огромный недостаток.Да, схему секционирования надо менять, мы этим тоже занялись и даже есть рабочее название проекта «pg_pathman», которые поможет нам генерить только нужные path-ы и передавать их планеры и избежать гигантского оверхеда перебора кучи ненужных планов. Это тоже часть работ по секционированию, но приятно, что она вполне обозримая и уже даст возможность работать с большим количеством разбиений. Возможно, надо будет объединиться с pg_partman.
Передайте АндресуПередал, более того, Андрес приедет зимой на pgconf.ru с докладом по масштабируемости постгреса, так что вы сможете с ним поговорить лично.
Спасибо за интереснейшую статью!
Не могли бы Вы описать подробнее, как вы определяли узкие места?
Не могли бы Вы описать подробнее, как вы определяли узкие места?
Это было не сложно, основные инструменты: perf && gdb:
Про perf вы можете почитать подробнее тут: https://wiki.postgresql.org/wiki/Profiling_with_perf
GDB использовали потому что perf не мог построить за приемлемое граф вызовов, для этого в gdb необходимо вызвать backtrace:
gdb --batch --command=file.script --pid $PID_OF_BACKEND
Про perf вы можете почитать подробнее тут: https://wiki.postgresql.org/wiki/Profiling_with_perf
GDB использовали потому что perf не мог построить за приемлемое граф вызовов, для этого в gdb необходимо вызвать backtrace:
gdb --batch --command=file.script --pid $PID_OF_BACKEND
Отличная работа! Спасибо за статью.
Авторы, не могли бы вы поделиться, пожалуйста, скриптами/командами для наполнения базы для pgbench? И скриптами для тестирования, если такие есть.
Заранее, большое спасибо!
Авторы, не могли бы вы поделиться, пожалуйста, скриптами/командами для наполнения базы для pgbench? И скриптами для тестирования, если такие есть.
Заранее, большое спасибо!
Держите: https://gist.github.com/vadv/b6dc474ded1261a5b643
В gist'е находится часть с необходимым ddl и питоновским скриптом, надстройкой над pgbench.
Результаты тестирования хранятся в базе results.
В gist'е находится часть с необходимым ddl и питоновским скриптом, надстройкой над pgbench.
Результаты тестирования хранятся в базе results.
По поводу предела масштабирования на графике №4 — я бы на вашем месте поигрался бы с affinity (Linux — taskset, AIX — bindprocessor), заставляя планировщик не мигрировать запущенные процессы на другие сокеты. Не уверен что это что-то бы дало, но поиграться стоило.
Мы увеличивали sched_migration_cost в 50 раз. Биндингом на ноды занимался numactl.
Хорошо, то есть какие выводы можно сделать? Архитектура с многопроцессным приложением, работающим через одну разделяемую память плохо работает в NUMA? Надо аллоцировать на каждом NUMА узле свою отдельную память с независимым набором процессов?
По нашим оценкам, в условиях этого теста, NUMA (запускаем все процессы сервера на одной numa-ноде, а память на крайней по растоянию) давала деградацию 10-20%.
И «huge drop in performance when going from 15-cores on1-socket to 30-cores on 2-socket» как описано тут:
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon-2014-locking-final.pdf мы не наблюдали.
Большая часть проблемы — не хардваная, а софтовая — это синхронизация экслюзивного доступа к ресурсу — странице памяти. Эту проблему мы и решали.
И «huge drop in performance when going from 15-cores on1-socket to 30-cores on 2-socket» как описано тут:
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon-2014-locking-final.pdf мы не наблюдали.
Большая часть проблемы — не хардваная, а софтовая — это синхронизация экслюзивного доступа к ресурсу — странице памяти. Эту проблему мы и решали.
Большая часть проблемы — не хардваная, а софтовая — это синхронизация экслюзивного доступа к ресурсу — странице памяти. Эту проблему мы и решали.
Это ИМХО и есть хардварная проблема, мы просто придумали как меньше синхронизироваться т.е. трогать эту проблему.
khizmax отличный цикл статей написал, всем советую для понимания.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL на многоядерных серверах Power 8