В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других. В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий. Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.

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

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

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

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

5. Типы ожиданий
• IO
• Сеть
• Процессор
• Локи
• и другие...

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

8. Инструменты
• Встроенные представления
(pg_locks, pg_stat_activity)
• pg_stat_statements
• pg_stat_kcache
• SystemTap
• perf
• gdb

9. Минусы
• отдельную задачу выполняют
хорошо, но не дают полную
картину
• внешние по отношению к
Postgres (perf)
• иногда требуют нетривиальных
знаний от DBA (gdb)

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

11. Профайлинг
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 раз

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

13. Наиболее частые LWLock
• ProcArrayLock (создание
снапшотов)
• WALWriteLock (запись WAL
файлов)
• локи буферного
менеджера

14. Время по локам
BufferPartitionLock

16. Неизвестно время наступления
событий (нужно привязывать ко
времени выгрузки)
Точность измерения
Возможность строить графики в
реальном времени
Плюсы-минусы профайлинга

17. История событий
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

18. История событий
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 базы данных и таблицы

19. Много дополнительных параметров
(для storage событий вплоть до блока
записи)
Может пропускать события (сэмплинг)
Содержит время события
Содержит ограниченное количество
событий
Плюсы-минусы истории

20. Трассировка
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

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

22. Видно все события по запросу
Точность значений
Большой оверхед
Использовать можно только на
отдельных запросах
Плюсы-минусы трассировки

23. Устройство pg_stat_wait

24. Сбор истории

25. Overhead
Тестовая конфигурация:
• Intel(R) Xeon(R) CPU X5675@3.07GHz,
24 cores
• RAM 24 GB
• pgbench -S 500 ~ 1.6 Gb
Избегаем влияния дисковой подсистемы:
• fsync off
• tmpfs

26. 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

27. 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

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

29. Продвижение в PostgreSQL
Целевая версия - PostgreSQL 9.6
Этапы:
• Рефакторинг легковесных локов
• Поле в pg_stat_activity
• Профайлинг в ядре Postgres

30. Open source
• Ссылка на презентацию
https://goo.gl/M005wM
• Ссылка на исходный код
https://goo.gl/M0GrFI

31. Вопросы?

32. Контакты
Ильдус Курбангалиев
i.kurbangaliev@postgrespro.ru