PG_HAZEL + CS/VMSTAT : корреляция ожиданий СУБД PostgreSQL и переключений контекста ОС

СУБД как инструмент анализа состояния ОС.

Задача

Экспериментально проверить гипотезу о корреляции и причинно-следственной связи снижения производительности СУБД PostgreSQL и роста количества переключений контекста ОС (показатель cs метрики vmstat).

Гипотеза и теоретическое обоснование

Рост cs/vmstat сильно коррелирует с ожиданиями блокировок (LWLock и heavyweight locks) в PostgreSQL. Эта корреляция не просто совпадение, а прямое указание на то, что снижение производительности вызвано конкуренцией за ресурсы и высокими накладными расходами ОС на переключение между задачами, которые не могут продвинуться из-за этой конкуренции.

В 99% случаев проблем с PostgreSQL первичны именно ожидания внутри СУБД (Locks, I/O). Резкий рост cs в vmstat — это важнейший сигнал и индикатор этих ожиданий на уровне операционной системы, который говорит о том, что процессы не работают, а ждут, и ОС тратит силы на переключения между ними. Поэтому при росте cs нужно сразу смотреть вглубь — на анализ wait events .

Экспериментальное подтверждение

Инцидент производительности СУБД

Дашборд Zabbix

Производительность и ожидания СУБД

Корреляция ожиданий СУБД

Чек-лист CPU

График изменения количества переключений контекста (cs/vmstat)

Анализ ожиданий СУБД

Высокое количество переключений контекста (cs) указывает на то, что операционная система активно переключается между выполнением разных процессов и потоков.

...

• Тяжелые блокировки (Heavyweight Locks): Блокировки на уровне SQL, такие как RowExclusiveLock, ShareLock, ExclusiveLock и особенно AccessExclusiveLock.
• Конкретные ожидания: lock, transactionid.
• Почему корреляция: Если длительная транзакция удерживает AccessExclusiveLock на таблице (например, во время выполнения ALTER TABLE), все другие запросы к этой таблице будут ждать. ОС будет вынуждена переключать контекст с этих ждущих сеансов на другие, увеличивая cs.

SQL запросы вызывающие ожидания типа Lock

История выполнения и ожиданий типа Lock для SQL запроса -1830911979360374060

История выполнения и ожиданий типа Lock для SQL запроса 2629217653828910897

Вывод

Гипотеза о причинно-следственной связи ожиданий СУБД и количестве переключений контекста ОС - подтверждается экспериментально:

Первопричина (в СУБД) -> Ожидание (wait event) -> Реакция ОС -> Рост cs

1. Процесс инициирует ожидание: Сеанс PostgreSQL в процессе выполнения запроса достигает точки, где он не может продолжить работу без какого-то ресурса.
2. Пример 1: Ему нужна страница данных с диска. Он инициирует операцию I/O и добровольно переходит в состояние сна (sleep), ожидая её завершения. Это регистрируется как wait event DataFileRead.
3. Пример 2: Он пытается изменить строку, но другая транзакция удерживает на ней блокировку. Сеанс вынужденно переходит в состояние сна, ожидая освобождения блокировки. Это регистрируется как wait event lock.
4. Реакция планировщика задач ОС: Когда процесс PostgreSQL переходит в состояние сна (добровольно или вынужденно), он отдает свой квант времени процессора. Планировщик задач ОС фиксирует это и производит переключение контекста (cs), чтобы отдать освободившееся процессорное время другому готовому к выполнению процессу (например, другому сеансу БД или процессу самой ОС).
5. Результат: Таким образом, каждое ожидание внутри PostgreSQL (кроме ожидания CPU) приводит к тому, что процесс будет "усыплен", и ОС будет вынуждена выполнить переключение контекста, чтобы не простаивать. Чем больше сеансов одновременно находятся в состоянии ожидания, тем чаще ОС приходится переключаться между ними и другими процессами — рост cs.