Как ускорить работу PostgreSQL

[mishamota]

Было бы интересно узнать как менялся медианный latency запросов при реализации каждой из рекомендаций.

[tas]

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

• Деление таблицы на партиции (секционирование). Вот здесь была информация по увеличению скорости https://habr.com/ru/company/otus/blog/452280/) в 11 версии PG. Сейчас уже 15 версия PG и в ней это работает еще лучше...

• В догонку к предыдущему пункту еще можно добавить ILM концепцию хранения данных. Заключается она в том, что вы наиболее нагруженные таблицы храните на наиболее быстрых носителях.

Эти 2 шага увеличат скорость в разы, а в некоторых случаях на порядки. А ведь на них можно не останавливаться...

[EvgenyVilkov]

Однако то что вы пишите и так очевидно. Эка невидаль - секции дадут буст! Если журналы и горячие данные положить на быстрые диски или использовать страйпинг то будет быстрее, "внезапно"

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

[velipre_xella]

Хотел спросить, почему PostgreSQL 9.5.7 - такая версия старая? Но вовремя заметил, что это перевод.

Представленные параметры конфигурации оптимизированы под транзакционные рабочие нагрузки (системы онлайн-банкинга, сервисы продажи авиабилетов и другие приложения, специализирующиеся на обработке больших объёмов транзакционных баз данных)

В реальности, насколько часто PG используется для таких важных OLTP-систем, как банкинг? Я думал, они в подавляющем большинстве на Оракеле, и процесс миграции на PG только начинается. ЦФТ что-то писали такое.

[geniyoctober]

В мировом финтехе вариаций реально много, так что такой кейс даже не редкий.
В плане рекомендаций - они применимы, ничего, что тесты на 9.5.7.

[RuslanHamhoev]

Нет уже в Ubuntu 20 такого параметра kernel.sched_migration_cost_ns. И read ahead для современных SSD не поможет. Статья сильно устарела, очевидно.

[edo1h]

вы неправы, очень даже может влиять.
вот вам вполне современный samsung pm9a3

root@rescue / # dd if=/dev/nvme0n1 of=/dev/null iflag=direct bs=4M status=progress count=1000
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 0.752474 s, 5.6 GB/s
root@rescue / # dd if=/dev/nvme0n1 of=/dev/null iflag=direct bs=4k status=progress count=100000
337100800 bytes (337 MB, 321 MiB) copied, 1 s, 337 MB/s
100000+0 records in
100000+0 records out
409600000 bytes (410 MB, 391 MiB) copied, 1.2121 s, 338 MB/s

разница в скорости линейного чтения блоками 4КБ и 4МБ в 16 раз (!!!)
другое дело, есть сомнения, что для постгреса этот readahead нужен.

[SWATOPLUS]

<сарказм>Как ускорить PostgreSQL? Заменить его на Postgres Pro. Он же быстрый мощный, а самое главное российский.</сарказм>

[piratarusso]

Очередная попытка найти секретный параметр, который резко повысит что-там в базе завершилась тем, чем и должна была завершиться. Его просто нет. Большая часть того, что можно действительно сделать для повышения производительности приложений можно сделать на этапе проектирования базы данных. Кое-что можно поправить при опытной эксплуатации, добавить индексы и оптимизировать самые тяжёлые запросы.