Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)

Мониторинг ожиданий в PostgreSQLИльдус Курбангалиев

Ссылка на презентацию

https://goo.gl/M005wM

Мониторинг ожиданий• отслеживание событий ожидания и построение их профиля (времени и количества) для идентификации "узких" мест в системе

Где и зачем это нужно?

• высоконагруженные конкурентные системы

• enterprise базы данных должны иметь встроенный мониторинг. Oracle имеет wait интерфейс из коробки, это также упрощает миграцию

• информация по состоянию системы в любой момент времени в production системе с минимальным оверхедом

Типы ожиданий

• IO• Сеть• Процессор• Локи• и другие...

Типы ожиданий в Postgres• Heavyweight locks• Lightweight locks (LWLocks)• Latch• Input / output• Network• Spinlocks• CPU

Инструменты• Встроенные представления

(pg_locks, pg_stat_activity)• pg_stat_statements• pg_stat_kcache• SystemTap• perf• gdb

Минусы• отдельную задачу выполняют хорошо, но не дают полную картину

• внешние по отношению к Postgres (perf)

• иногда требуют нетривиальных знаний от DBA (gdb)

pg_stat_wait

• профайлинг• история• трассировка

Профайлингb1=# SELECT * FROM pg_stat_wait_profile WHERE event_name = 'WALWriteLock' LIMIT 1;

-[ RECORD 1 ]------------ pid | 1804 class_id | 1 class_name | LWLocks event_id | 8 event_name | WALWriteLock wait_time | 8719 wait_count | 6

Процесс Postgres c pid=1804 провел в локе WALWriteLock wait_time микросекунд wait_count раз

Время по классам ожиданий

Наиболее частые LWLock• ProcArrayLock (создание снапшотов)

• WALWriteLock (запись WAL файлов)

• локи буферного менеджера

Время по локам

BufferPartitionLock

Неизвестно время наступления событий (нужно привязывать ко времени выгрузки)

Точность измерения

Возможность строить графики в реальном времени

Плюсы-минусы профайлинга

История событийb1=# SELECT * FROM pg_stat_wait_history; -[ RECORD 1 ]----------------------------- pid | 1809 sample_ts | 2015-10-29 04:58:53.85285-04 class_id | 3 class_name | Storage event_id | 0 event_name | SMGR_READ wait_time | 10299 p1 | 1663 p2 | 16384 p3 | 12214 p4 | 0 p5 | 1

История событийb1=# SELECT * FROM pg_stat_wait_history; -[ RECORD 1 ]----------------------------- pid | 1809 sample_ts | 2015-10-29 04:58:53.85285-04 class_id | 3 class_name | Storage event_id | 0 event_name | SMGR_READ wait_time | 10299 p1 | 1663 p2 | 16384 p3 | 12214 p4 | 0 p5 | 1

Тип события

Oid базы данных и таблицы

Много дополнительных параметров (для storage событий вплоть до блока записи)

Может пропускать события (сэмплинг)

Содержит время события

Содержит ограниченное количество событий

Плюсы-минусы истории

Трассировкаterminal 1: $ psql b1

terminal 2: $ ps ax | grep '[p]ostgres.*b1.*' | awk '{print $1}' 1066

$ psql b1 > select pg_start_trace(1066, '/tmp/f.trace')

terminal 1: b1=# CREATE TABLE t1 AS SELECT i, i*10 AS i1 FROM generate_series(1,10) i; SELECT 10

Вывод трассировкиterminal 2:$ tail -f /tmp/f.trace stop 2015-07-10 10:03:35.603458-04 Networkstart 2015-07-10 10:03:35.603464-04 Network READ 0 0 0 0 0stop 2015-07-10 10:03:44.099587-04 Networkstart 2015-07-10 10:03:44.100401-04 Storage READ 1663 16384 1259 2 0stop 2015-07-10 10:03:44.100424-04 Storagestart 2015-07-10 10:03:44.102549-04 Network WRITE 0 0 0 0 0stop 2015-07-10 10:03:44.102573-04 Networkstart 2015-07-10 10:03:44.102582-04 Network READ 0 0 0 0 0stop 2015-07-10 10:05:33.029975-04 Networkstart 2015-07-10 10:05:33.030205-04 Storage READ 1663 16384 2691 0 28stop 2015-07-10 10:05:33.030233-04 Storagestart 2015-07-10 10:05:33.030246-04 Storage READ 1663 16384 1255 0 50stop 2015-07-10 10:05:33.03026-04 Storage

Видно все события по запросу

Точность значений

Большой оверхед

Использовать можно только на отдельных запросах

Плюсы-минусы трассировки

Устройство pg_stat_wait

Сбор истории

OverheadТестовая конфигурация:

• Intel(R) Xeon(R) CPU [email protected], 24 cores

• RAM 24 GB• pgbench -S 500 ~ 1.6 Gb

Избегаем влияния дисковой подсистемы:• fsync off• tmpfs

pg_stat_wait выключен

transaction type: SELECT only scaling factor: 500 query mode: simple number of clients: 96 number of threads: 4 duration: 300 s number of transactions: 39349816 latency average: 0.732 ms tps = 131130.859559 tps = 131153.752204

pg_stat_wait включен

transaction type: SELECT only scaling factor: 500 query mode: simple number of clients: 96 number of threads: 4 duration: 300 s number of transactions: 39172607 latency average: 0.735 ms tps = 130574.626755 tps = 130600.767440

Итоги теста• Минимальный оверхед - 0.42 %• Выключив историю, можно получить еще более низкий оверхед

• Тест синтетический, оверхед будет другим в реальных системах

Продвижение в PostgreSQL

Целевая версия - PostgreSQL 9.6

Этапы:

• Рефакторинг легковесных локов

• Поле в pg_stat_activity

• Профайлинг в ядре Postgres

Open source

• Ссылка на презентациюhttps://goo.gl/M005wM

• Ссылка на исходный кодhttps://goo.gl/M0GrFI

Вопросы?

КонтактыИльдус Курбангалиев[email protected]