waits monitoring in postgresql
TRANSCRIPT
Мониторинг ожиданий в PostgreSQLИльдус Курбангалиев
Мониторинг ожиданий• отслеживание событий ожидания и построение их профиля (времени и количества) для идентификации "узких" мест в системе
Где и зачем это нужно?
• высоконагруженные конкурентные системы
• 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
Вопросы?
