Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных

Промышленный подход
к тюнингу PostgreSQL:
эксперименты над базами
данных

О докладчике
○ Опыт Postgres с 2005 (РСУБД — с 2001)
○ Сo-founder/CTO нескольких компаний (везде — Postgres)
○ Co-founder #RuPostgres (1900+ человек на Meetup, 2-е место в мире)
○ ПК различных конференций (BackendConf, Highload++, etc) – с 2007

PostgreSQL-консалтинг в SF Bay Area

PostgreSQL-консалтинг в SF Bay Area
Postgres.ai – платформа для Postgres DBA,
автоматизация тех задач,
которые ещё не автоматизированы
«облаками»

О докладe
В докладе не будет:

О докладe
● «серебряных пуль», волшебных настроек, универсальных рецептов;

О докладe
● хардкорных «внутренностей».

О докладe
А что будет?

О докладe
● оптимизация с помощью экспериментов: принципы, идеи и инструменты, которые
можно применять на практике;

О докладe
● оптимизация с помощью экспериментов: принципы, идеи и инструменты, которые
можно применять на практике;
● опыт использования в разных компаниях, от маленьких стартапов до компаний-
«единорогов»

Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных

Сигналы о проблемах (alerts)
наблюдения «вручную»

Наиболее популярные средства для анализа запросов «в целом»:

● pg_stat_statements
○ нет экземпляров
запросов
○ нет планов

○ нет экземпляров
запросов
○ нет планов
● log analysis (pgBadger)
○ требует поддержки
○ не «realtime»
○ обычно нет планов (есть, если auto_explain)
○ часто неполноценная картина
(log_min_duration_statement >> 0)

4 способа улучшить производительность:

1. Тюнинг конфигурации Postgres

2. Добавить/удалить индексы

3. Изменить SQL-запрос / схему БД

4. Нарастить ресурсы (CPU, RAM, disks)

1. Тюнинг конфига Postgres
2. Индексы

1. Тюнинг конфига Postgres
2. Индексы
DBA-эксперт пропускает многие шаги
«Чёрная магия»!

Почитали умные статьи или посты в блогах. Возникла идея:
Значение default_statistics_target (100) слишком мало.
Давайте поменяем на 1000!
...Отличная идея!
...Сделано — уже в production!

Проверим с помощью экспериментов!

Окружение
Объект (БД)
Нагрузка
(workload)
Изменение
(delta)

default_statistics_target2 года спустя: проверка с помощью эксперимента, значения 100 и 1000:

ДО: default_statistics_target = 100 ПОСЛЕ: default_statistics_target = 1000

Промотаем немного вниз...

default_statistics_target
Эта группа запросов стала намного
медленнее после изменения!
Решили с помощью:
“ALTER TABLE/INDEX … ALTER COLUMN SET
STATISTICS …“
на конкретном столбце

Большое количество развитых решений CI/CD

Ещё один пример
аэродинамическая труба

Детальный анализ
автоматизации

Nancy CLI — фундамент «лаборатории БД»

Nancy CLI сегодня
● Open source: https://gitlab.com/postgres-ai-team/nancy
Список параметров: https://gitlab.com/postgres-ai-team/nancy/blob/master/help/nancy_run.md

● Где можно запускать:
○ --run-on localhost: любая машина с MacOS, Debian/Ubuntu или RHEL/Centos)
○ --run-on aws: удалённый запуск на временных AWS EC2 (споты, рекомендуется i3)

● Где можно запускать:
○ --run-on localhost: любая машина с MacOS, Debian/Ubuntu или RHEL/Centos)
○ --run-on aws: удалённый запуск на временных AWS EC2 (споты, рекомендуется i3)
● Поддерживаемые версии Postgres:
○ 9.6
○ 10
○ 11

● «Объект»:
○ --db-dump: дамп / sql-файл
○ --db-local-pgdata: копия PGDATA
○ --db-pgbench: БД, сгенерированная с помощью pgbench

● «Объект»:
○ --db-dump: дамп / sql-файл
○ --db-local-pgdata: копия PGDATA
○ --db-pgbench: БД, сгенерированная с помощью pgbench
● «Нагрузка» (workload):
○ --workload-custom-sql: в произвольный SQL, в один поток;
○ --workload-real: эмуляция «реальной» нагрузки с помощью pgreplay
(требуются логи с «прода»), многопоточно. Можно задавать «скорость»
(--workload-real-replay-speed)
○ --workload-pgbench: эмуляция нагрузки, “crafted workload”

● Что проверяем:
○ --delta-sql-do / --delta-sql-undo: DDL (например, новый индекс), изменение
настроек таблиц, произвольные БД-миграции, пересбор статистики (ANALYZE), борьба с
раздутием (bloat) и т.д.
○ --delta-config: изменение одной или нескольких опций конфига PostgreSQL

● Что проверяем:
○ --delta-sql-do / --delta-sql-undo: DDL (например, новый индекс), изменение
настроек таблиц, произвольные БД-миграции, пересбор статистики (ANALYZE), борьба с
раздутием (bloat) и т.д.
○ --delta-config: изменение одной или нескольких опций конфига PostgreSQL
● Что в результате (набор артефактов):
○ Снапшоты pg_stat_*** (pg_stat_statements, pg_stat_kcache, pg_stat_bgwriter и т.д.)
○ Логи Postgres (отдельно: подготовка, проигрывание нагрузки)
○ FlameGraphs / perf cpu
○ «Родная» выдача pgreplay или pgbench
○ Информация о системе
○ [WIP/MR exists] базовые проверки CPU и IO (sysbench)

Технические сложности*
______________________________

log_min_duration_statement = 0

Как оценить поток лога при log_min_duration_statement = 0 (быстро и ничего не меняя!):
https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408 (внимание на комментарии)
Всего ожидаем ~300 kB/s,
~800 записей в лог в секунду

log_destination = syslog
logging_collector = off
или
log_destination = stderr
logging_collector = off
или
log_destination = csvlog
logging_collector = on

# Postgres 9.6.10
pgbench -U postgres -j2 -c24 -T60 -rnf - <<EOF
select;
EOF

# Postgres 9.6.10
pgbench -U postgres -j2 -c24 -T60 -rnf - <<EOF
select;
EOF
●
●

● Оцените IOPS и поток записи
● Проверьте свою систему логирования (syslog/journald может замедлять
всё радикально, подумайте о переходе на STDERR, logging collector)
● Если прогнозируемая нагрузка чрезмерно велика (десятки мегабайт и
более), рассмотрите вариант с сэмплированием
( "SET log_min_duration_statement = 0;" в конкретных, случайно
выбранных сессиях)

Альтернативный вариант – “crafted workload”
--workload-pgbench (many thanks Michel Pelletier! @michelp)
Пример:
--workload-pgbench
"-n -c${CPU_COUNT} -j${CPU_COUNT} -T$T
-f /var/lib/postgresql/9.6/main/workload/1_select_posts.sql@6
-f /var/lib/postgresql/9.6/main/workload/2_insert_post_view.sql@60
-f /var/lib/postgresql/9.6/main/workload/3_insert_bot_visit.sql@50
-f /var/lib/postgresql/9.6/main/workload/4_select_post_by_host.sql@2
-f /var/lib/postgresql/9.6/main/workload/5_select_post_by_rare_host.sql@1
-f /var/lib/postgresql/9.6/main/workload/6_select_post_by_category.sql@1
-f /var/lib/postgresql/9.6/main/workload/7_conveyor.sql@6
-f /var/lib/postgresql/9.6/main/workload/8_select_post_fresh.sql@1
...

Поможет «скрафтить нагрузку»:
postgres-checkup – периодическая диагностика здоровья БД
Open source: https://gitlab.com/postgres-ai-team/postgres-checkup
● Комплексный глубокий анализ. Мониторинги этого не делают
● Без вмешательства (лёгкие проверки)
● На наблюдаемые серверы ничего ставить не нужно (разве что
pg_stat_statements, если ещё нет)
Любой «боевой» БД регулярные «чекапы» нужны не меньше, чем бэкапы

Собираем самые “влиятельные” группы запросов — отчёт K003 в
postgres-checkup:

postgres-checkup:
Два снапшота pg_stat_statements,
анализируем разницу основных метрик
Сортировка по total_time

postgres-checkup:
Дифференцируем!
Два раза: по времени (период наблюдения) и
по количеству вызовов в группе
А также смотрим на «удельный вес»
группы, по каждой из метрик

Как именно «крафтить»
Набираем top-N групп,
чтобы было 80+ процентов по total-time
Знание о «доли» группы в общем потоке запросов,
по calls используем, чтобы заполнить XXX
в pgbench … -f group1.sql@XXX

Агрегированные отчёты — K001 и K002, узнаём много интересного
K001 – характеристика всего «потока»
K002 – «классы» запросов:
SELECT, SELECT .. FOR UPDATE,
INSERT и т.д.

Цель оптимизации: на что смотреть — throughput или latency?
Большинство опубликованных бенчмарков (особенно pgbench) ориентированы на
max throughput – максимальное количество транзакций в секунду, max TPS

Цель оптимизации: на что смотреть — throughput или latency?
Большинство опубликованных бенчмарков (особенно pgbench) ориентированы на
max throughput – максимальное количество транзакций в секунду, max TPS
В «обычной» жизни боевые БД не
«ездят» на максимальной
скорости (как и автомобили на
обычных дорогах).
Альтернативный подход:
находить min latency –
минимальное среднее время
отклика

Резюме и советы
● Создайте Database Lab!
○ с использованием Nancy CLI (или соответствующих идей)
○ “Staging on demand” — временные экземпляры, по запросу
○ регулярно готовьте копии боевых БД
○ научитесь эмулировать нагрузку
(по логам / pgreplay или «крафтовая нагрузка» с pgbench)
● На любой любое изменение, на любой вопрос — эксперименты над БД
● Прицел на min latency
● Используйте исходники Постгреса, используйте поиск
(https://github.com/postgres/postgres или http://gitlab.com/postgres/postgres)
● Проверяйте здоровье своих БД регулярно (postgres-checkup)

@postgresmen
75
Nancy CLI:
https://gitlab.com/postgres-ai-team/nancy
postgres-checkup:
https://gitlab.com/postgres-ai-team/
postgres-checkup

Кое-что из «режиссёрской версии»

seq_page_cost
GitLab.com: random_page_cost = 1.5 and seq_page_cost = 1
Decision was made to switch to seq_page_cost = 4
DB experiments with Nancy CLI were made to check was this decision good in
terms of performance.
Results:
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/4835#note_106669373
– in general, SQL performance improved ~40%
WIP here, it is an open question, why is it so.

PostgreSQL Documentation “19.5. Write Ahead Log”
https://www.postgresql.org/docs/current/static/runtime-config-wal.html

shared_buffers
postila.ru,
Real workload (5 min),
61 GB RAM (ec2 i3.2xlarge),
DB size: ~500GB
Various shared_buffers
values
shared_buffers = 15GB (25%)

pgbench/pgreplay — на той же машине, что и Postgres
или обязательно отдельно?

FlameGraphs/perf
(thanks Victor Yagofarov!
https://github.com/postgres-ai/nancy/pull/159)

FlameGraphs/perf
(thanks Victor Yagofarov!
https://github.com/postgres-ai/nancy/pull/159)
«Вклад» pgbench всего 6%

PostgreSQL Documentation “19.5. Write Ahead Log”
https://www.postgresql.org/docs/current/static/runtime-config-wal.html
Just conduct DB experiment with Nancy CLI,
use --keep-alive 3600 and compare!

Главное:
● Эксперименты БД — переход от «чёрной магии» к промышленным
методам и решениям, основанным на данных
● Staging DB — как можно ближе к production
● Лучше иметь много “staging DB”. Ещё лучше — создавать по запросу
● Используйте готовые open source решения для того, чтобы знать о
своей БД и нагрузке как можно больше

Входящие:
1. Среда
“железо”, ОС, ФС,
версия Postgres, конфигурация

Входящие:
1. Среда
2. Объект
Некоторая БД (например, “клон прода”)

Входящие:
1. Среда
2. Объект
3. Нагрузка
Некоторый набор SQL-запросов

Входящие:
1. Среда
2. Объект
3. Нагрузка
4. Изменение (может быть несколько значений)
Некоторое изменение конфига Postgres
или, например, новый индекс

Входящие:
1. Среда
2. Объект
3. Нагрузка
Результат:
1. Summary
лучше или хуже, в целом?

Входящие:
1. Среда
2. Объект
3. Нагрузка
Результат:
1. Summary
2. Артифакты
любые полезные подробности

Входящие:
1. Среда
2. Объект
3. Нагрузка
Результат:
1. Summary
2. Артифакты
любые полезные подробности
3. Подробный анализ SQL-запросов
каждая группа: лучше или хуже?
+ гистограммы:

Возможно ли посредством существующих решений?
● Docker
● pgreplay
● pg_stat_***
● auto_explain
● pgBadger (with JSON output)
● AWS EC2 spot instances
— Необходимые “строительные блоки” уже существуют

Возможно ли посредством существующих решений?
● Docker
● pgreplay
● pg_stat_***
● auto_explain
● pgBadger (with JSON output)
● AWS EC2 spot instances
— Необходимые “строительные блоки” уже существуют
Nancy CLI: эти (и не только) блоки, интегрированные в единое решение
https://github.com/postgres-ai/nancy

How to automate database optimization using ecosystem tools and AWS?
Analyze:
● auto_explan
● pgBadger to parse logs, use JSON output
● pg_query to group queries better
● pg_stat_kcache to analyze FS-level ops
Configuration:
● annotated.conf, pgtune, pgconfigurator, postgresqlco.nf
● ottertune
Suggested indexes (internal “what-if” API w/o actual execution)
● (useful: pgHero, POWA, HypoPG, dexter, plantuner)
Conduct experiments:
● pgreplay to replay logs (different log_line_prefix, you need to handle it)
● EC2 spot instances
Machine learning
● MADlib
pgBadger:
● Grouping queries can be implemented better (see pg_query)
● Makes all queries lower cased (hurts "camelCased" names)*
● Doesn’t really support plans (auto_explain)*
pgreplay and pgBadger are not friends,
require different log formats
*)
Fixed/improved in pgBadger 10.0

AI-based cloud-friendly platform to automate database administration
96
Steve
AI-based expert in capacity planning and
database tuning
Joe
AI-based expert in query optimization and
Postgres indexes
Nancy
AI-based expert in database experiments.
Conducts experiments and presents
results to human and artificial DBAs
https://Postgres.ai

AI-based cloud-friendly platform to automate database administration
97
Steve
AI-based expert in capacity planning and
database tuning
Joe
AI-based expert in query optimization and
Postgres indexes
Nancy
AI-based expert in database experiments.
Conducts experiments and presents
results to human and artificial DBAs
https://Postgres.ai

Исходники: https://github.com/postgres-ai/nancy/tree/master/docker
Образ: https://hub.docker.com/r/postgresmen/postgres-nancy
Внутри:
● Ubuntu 16.04
● Postgres (9.6, 10, 11)
● postgres_dba на случай ручного “дебаггинга” https://github.com/NikolayS/postgres_dba
● log_min_duration_statement = 0
● pg_stat_statements включены, с track_io_timing = on
● auto_explain опционально
● pgreplay
● pgBadger
● FlameGraph (perf cpu) https://github.com/postgres-ai/nancy/pull/159

● plain text pg_dump
○ restoration is very slow (1 vcpu utilized)
○ “logical” – physical structure is lost (cannot experiment with bloat, etc)
○ small (if compressed)
○ “snapshot” only
● pg_dump with either -Fd (“directory”) or -Fc (“custom”):
○ restoration is faster (multiple vCPUs, -j option)
○ “logical” (again: bloat, physical layout is “lost”)
○ small (because compressed)
○ “snapshot” only
● pg_basebackup + WALs, point-in-time recovery (PITR), possibly with help from WAL-E, WAL-G, pgBackRest
○ less reliable, sometimes there issues (especially if 3rd party tools involved - e.g. WAL-E & WAL-G don’t support
tablespaces, there are bugs sometimes, etc)
○ “physical”: bloat and physical structure is preserved
○ not small – ~ size of the DB
○ can “walk in time” (PITR)
○ requires warm-up procedure (data is not in the memory!)
● AWS RDS: create a replica + promote it
○ no Spots :-/
○ Lazy Load is tricky (it looks like the DB is there but it’s very slow – warm-up is needed)
● Snapshots
● Ideas for serialization
○ Stop Postgres / rsync “back” or re-copy locally on NVMe / start Postgres

● Prepare the EC2 instance(s) in advance and keep it
● Prepare EBS volume(s) only (perhaps, using an instance of the different
type) and keep it ready. When attached to the new instance, do warm-up
● Resource re-usage:
○ reuse docker container
○ reuse EC2 instance
○ serialize experimental runs serialization (DDL Do/Undo; VACUUM FULL; cleanup)
● Partial database snapshots (dump/restore only needed tables)
● Filesystem snapshots to have few-second resets
(examples: https://events.yandex.ru/lib/talks/4402/,
https://heapanalytics.com/blog/engineering/testing-database-changes-right-way)

● ZFS/XFS snapshots to revert PGDATA state within seconds
● FlameGraphs (perf) – DONE https://github.com/postgres-ai/nancy/pull/159
● Support GCP
● More artifacts delivered: pg_stat_kcache, etc
● nancy describe to print the summary + top-N queries – DONE
● nancy describe to print the “diff” for 2+ reports (the summary + numbers for top-30 queries, ordered by
by total time based on the 1st report) – DONE
● Postgres 11 – DONE
● pgbench -i for database initialization – DONE
● pgbench to generate multithreaded synthetic workload – DONE
● Workload analysis: automatically detect “N+1 SELECT” when running workload
● Better support for the serialization of experimental runs
● Better support for multiple runs https://github.com/postgres-ai/nancy/pull/97
○ interval with step – WIP
○ gradient descent
● Provide costs estimation (time + money) – DONE
● Go
Feedback/contributions welcome
https://github.com/postgres-ai/nancy

Problem: a developer doesn’t have access to production.
Nancy works with production data/workload.
What about permissions and data protection?
Possible solutions:
● Option 1: allow using Nancy CLI only to those who already have access
production (DBAs, SREs, DBREs)
● Option 2: obfuscate data when preparing a DB clone (no universal
solution yet, TODO)
● Option 3: allow access only to GUI, hide/obfuscate parameters (TODO)

Issues:
1. Single runs is not enough (fluctuations) – must repeat
2. “Before”/”after” runs on 2 different machines / EC2 nodes – “not fair” comparison
(defective hardware, throttling)
Solutions (ideally: combination of them):
● Sequential runs
● 4+ iterations of each experimental run
● “Baseline benchmark” https://github.com/postgres-ai/nancy/issues/94

Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных

More Related Content

What's hot (20)

Similar to Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных (20)

More from Nikolay Samokhvalov (20)

Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных