Гипотеза

Сокращение периода, когда серверный процесс, обрабатывающий SQL-запрос к системе управления базами данных (СУБД), сталкивается с событием ожидания, напрямую влияет на скорость выполнения запроса. Чем меньше времени процесс простаивает в ожидании, тем быстрее завершается SQL-запрос.

При многократном повторении запросов, минимизация времени ожидания приводит к увеличению количества выполненных запросов за единицу времени. В конечном итоге, это позволяет предоставить клиенту больший объем полезной информации за тот же период. Таким образом, снижение задержек в обработке SQL-запросов ведет к повышению общей производительности системы.

PG_HAZEL : Мониторинг и анализ производительности СУБД PostgreSQL

Доказательство гипотезы

Общая основа для доказательства

Любой SQL-запрос, выполняемый серверным процессом СУБД, проходит через два типа фаз:

1. Активная обработка (CPU Bound): Процессор выполняет вычисления — парсинг запроса, построение плана выполнения, соединение таблиц, сортировку данных и т.д.

2. Ожидание (I/O Bound или Wait Events): Процесс приостанавливает выполнение и ждет наступления какого-либо события. Ключевые виды ожиданий:
   Дисковый ввод/вывод (I/O): Ожидание чтения данных с диска ( страницы с данными, индексы) или записи журналов (например, Transaction Log).
   Блокировки (Locking): Ожидание, пока другая транзакция освободит нужную блокировку на строку или таблицу.
   Сетевые задержки (Network): Ожидание получения следующего пакета данных от клиента или отправки ему результатов.
   Ожидание ресурсов CPU (CPU Queue): Процесс готов к выполнению, но все ядра процессора заняты другими процессами.

Общее время выполнения запроса (T_total) можно выразить формулой:
T_total = T_active + T_wait
где:

• T_active — совокупное время активной обработки на CPU.

• T_wait — совокупное время всех событий ожидания.

Доказательство части 1: Влияние на скорость выполнения одного запроса

Утверждение: Сокращение периода ожидания напрямую влияет на скорость выполнения запроса.

Доказательство:

1. Логическое рассуждение:
   Из формулы T_total = T_active + T_wait следует, что T_total является функцией от T_wait. Если значение T_wait уменьшается (при прочих равных условиях, т.е. T_active остается неизменным), то значение T_total также уменьшается. Уменьшение T_total и есть увеличение скорости выполнения запроса. Это прямое и линейное следствие.

2. Математическая формализация:
   Пусть T_total_1 = T_active + T_wait_1
   После оптимизации (например, добавление индекса для уменьшения времени ожидания чтения с диска) время ожидания сокращается: T_wait_2 < T_wait_1
   Время активной обработки может незначительно измениться (например, процессорное время на обход индекса может немного вырасти), но в большинстве сценариев оптимизации ожидания это изменение пренебрежимо мало или даже отрицательно (новый индекс эффективнее). Предположим, T_active ~ const.
   Следовательно: T_total_2 = T_active + T_wait_2 < T_active + T_wait_1 = T_total_1
   Вывод: Время выполнения запроса T_total_2 строго меньше T_total_1.

3. Практическое подтверждение (Архитектура СУБД):
   Все современные СУБД (Oracle, SQL Server, PostgreSQL, MySQL) имеют встроенные механизмы диагностики — Мониторинг ожиданий (Wait Event Statistics). Администраторы баз данных используют запросы к системным представлениям (например, sys.dm_os_wait_stats в SQL Server или pg_stat_activity в PostgreSQL), чтобы выявить основные wait events для медленных запросов.
   Пример: Если главный тип ожидания — IO (ожидание чтения данных с диска), его сокращение путем добавления оперативной памяти (чтобы кэшировать данные) или добавления более быстрых SSD-дисков всегда приводит к ускорению выполнения целевого запроса. Это эмпирически проверяемый и доказуемый факт.

Заключение по части 1:

Гипотеза верна. Время ожидания является прямой аддитивной составляющей общего времени отклика запроса. Его сокращение напрямую уменьшает общее время выполнения.

Доказательство части 2: Влияние на пропускную способность (throughput)

Утверждение: Минимизация времени ожидания приводит к увеличению количества выполненных запросов за единицу времени.

Доказательство:

1. Логическое рассуждение и аналогия:
   Представьте себе дорогу с единственной заправкой (единый ресурс — дисковая подсистема). Если одна машина (запрос) долго стоит на заправке (ждет I/O), она создает пробку. Машины сзади нее также вынуждены ждать. Если время заправки каждой машины сократить, пропускная способность заправки (диска) возрастет, и за час через пункт пропуска проедет больше машин (запросов).

2. Математическая модель (Теория массового обслуживания):
   Сервер БД можно смоделировать как систему массового обслуживания (СМО) с ограниченным числом каналов (работников — CPU ядер, дисковых контроллеров).
   Производительность системы (Throughput) — количество успешно обслуженных заявок (запросов) в единицу времени.
   Ключевой параметр, влияющий на производительность — Время обслуживания заявки, которое, как мы доказали в части 1, равно T_active + T_wait.
   Формулы для СМО (например, для многоканальной системы с ожиданием) показывают, что пропускная способность напрямую зависит от времени обслуживания одной заявки. Чем меньше время обслуживания, тем выше пропускная способность системы.
   Throughput ∝ 1 / T_total (Пропускная способность обратно пропорциональна времени выполнения запроса).

3. Формализация:
   Пусть N — количество идентичных запросов, которые необходимо выполнить.
   Общее время на выполнение всех N запросов в системе без параллелизма: T_system = N * T_total = N * (T_active + T_wait)
   Количество запросов, выполняемых в секунду (Throughput): R = N / T_system = 1 / (T_active + T_wait)
   Если T_wait уменьшается, знаменатель уменьшается, а значение R (throughput) — увеличивается.
   Следствие: За фиксированный промежуток времени T (например, 1 секунда), количество выполненных запросов будет равно R * T = T / (T_active + T_wait). Сокращение T_wait приводит к увеличению этого числа.

4. Практическое подтверждение (Сценарий с блокировками):
   Рассмотрим конкурентный доступ.
   Было: Запрос A устанавливает эксклюзивную блокировку на строку и выполняет долгую операцию (T_wait для других запросов велико из-за ожидания LCK_M_X). Десятки других запросов, желающих прочитать эту строку, выстраиваются в очередь и ждут.
   Стало: Запрос A оптимизирован и выполняется быстрее (сокращается его T_active и, что важно, время удержания блокировки). Он быстрее освобождает ресурс.
   Результат: Время ожидания T_wait для каждого из запросов в очереди резко сокращается. Общая система справляется с той же рабочей нагрузкой за меньшее время, либо успевает обработать больше запросов за то же время. Клиент получает больший объем полезной информации за тот же период.

Заключение по части 2:

Гипотеза верна. Сокращение времени ожидания не только ускоряет один запрос, но и уменьшает contention (борьбу за ресурсы) в системе. Это высвобождает ресурсы (CPU, диски, блокировки) для обработки других запросов, что приводит к увеличению общей пропускной способности (throughput) системы.

Итоговое заключение

Обе части гипотезы являются не просто предположениями, а фундаментальными принципами устройства высокопроизводительных систем. Они доказываются через:

1. Аддитивность времени выполнения запроса.

2. Обратную зависимость пропускной способности от времени выполнения отдельной задачи.

3. Эмпирические данные, получаемые через инструменты мониторинга ожиданий СУБД.

4. Принципы теории массового обслуживания.

Таким образом, основная задача оптимизации производительности БД часто сводится именно к выявлению и сокращению ключевых событий ожидания (wait events).

Продолжение

PG_HAZEL : Следствие из гипотезы корреляционного анализа ожиданий СУБД PostgreSQL.

В качестве иллюстрации к статье

PG_HAZEL : Реализованные "know-how"

Глубокий сбор статистики по SQL-запросам. Для высоконагруженных систем "Орешник" обеспечивает детальный сбор статистики выполнения ( calls, rows) и ожиданий (wait_event_type, wait_event) для каждого отдельного запроса. Это даёт бесценную информацию для точечной оптимизации самых ресурсоёмких операций.

Реализация раздельной стратегии сбора статистических данных по SQL запросам

PG_HAZEL : Стратегии сбора данных уровня SQL-запросов

Процесс-1 - cбор исходных данных статистики SQL-запросов, одновременно со сбором данных по СУБД.Процесс-2 - агрегация и сглаживание накопленных данных по отдельным SQL-запросам.

Практическая реализация

• Количество ядер CPU : 192

• Размер RAM: 1TB

• Объем уникальных SQL запросов в минуту : ~500

• Операционная скорость : 5 - 8 000 000

• Ожидания СУБД : 200 - 400 000 000

Представлен комплекс pg_hazel "Орешник": революционные know-how для предиктивного анализа и обеспечения высокой доступности PostgreSQL

📅 Дата публикации: 17 сентября 2025 года

📍 Место: Россия

Разработчики проекта pg_hazel "Орешник" (https://dzen.ru/kznalp) представляют уникальный программный комплекс, предназначенный для глубинного мониторинга и анализа производительности высоконагруженных систем управления базами данных (СУБД) PostgreSQL. Решение включает в себя ряд эксклюзивных технологий (know-how), которые радикально меняют подход к обеспечению стабильности и предсказуемости работы критически важных баз данных.

В эпоху, когда простои и лаги в работе БД напрямую влияют на бизнес-показатели, традиционный мониторинг, отслеживающий лишь общие метрики, уже недостаточен. Комплекс "Орешник" предлагает проактивный и корреляционный анализ, выявляя проблемы на стадии их зарождения и точно определяя первопричину.

Ключевые решённые технологические задачи (know-how):

1. Интеллектуальное удаление выбросов в исходных данных. Алгоритмы "Орешника" автоматически фильтруют аномальные значения, возникающие из-за кратковременных скачков нагрузки или ошибок сбора. Это обеспечивает высокую достоверность исходных данных для последующего анализа и исключает ложные срабатывания.

2. История изменения метрик производительности и ожиданий. Система сохраняет не только текущее состояние, но и полную историю всех ключевых метрик СУБД (LWLocks, IPC, IO и т.д.) . Это позволяет проводить ретроспективный анализ и точно определять, в какой момент и при каких условиях началась деградация производительности.

3. Индикатор снижения производительности как стартовое событие для инцидентов. Комплекс в реальном времени вычисляет репрезентативные показатели производительности СУБД. При их отклонении от нормы система автоматически может инициирует процесс создания инцидента в Service Desk, позволяя инженерам начать расследование до того, как проблема отразится на пользователях.

4. Глубокий сбор статистики по SQL-запросам. Для высоконагруженных систем "Орешник" обеспечивает детальный сбор статистики выполнения ( calls, rows) и ожиданий (wait_event_type, wait_event) для каждого отдельного запроса. Это даёт бесценную информацию для точечной оптимизации самых ресурсоёмких операций.

5. Статистический анализ метрик ОС (vmstat, iostat). Анализ не ограничивается данными СУБД. Система строит динамические статистические модели по метрикам операционной системы (загрузка CPU, очереди диска, потребление памяти), выявляя аномалии и тренды на уровне всего сервера.

6. Корреляционный анализ ожиданий СУБД и метрик ОС. Это ключевое ноу-хау комплекса. "Орешник" автоматически находит корреляции между событиями ожидания внутри PostgreSQL (например, ожидание записи на диск) и показателями ОС (например, высокая очередь записи на iostat). Это в разы ускоряет диагностику, позволяя однозначно ответить на вопрос: "Проблема в неоптимальном запросе или в медленном диске?".

Цитата руководителя проекта:
«Наш опыт эксплуатации кластеров PostgreSQL под экстремальными нагрузками показал, что стандартные инструменты мониторинга часто показывают лишь следствие, а не причину проблемы. Мы создали "Орешник" как систему, которая мыслит как опытный администратор БД. Она не просто фиксирует факт падения производительности, а предупреждает о нём заранее и сразу выдаёт гипотезу о корневой причине, экономя часы и дни на расследование. Наши know-how в области корреляционного анализа — это настоящий прорыв в предиктивной аналитике для СУБД».

О проекте pg_hazel "Орешник":
Проект посвящён разработке и внедрению передовых методов мониторинга, анализа и обеспечения отказоустойчивости кластеров PostgreSQL. Решения проекта основаны на глубоком практическом опыте и предназначены для использования в высокодоступных и высоконагруженных системах, где стабильность работы БД является критически важной для бизнеса.

Для получения дополнительной информации посетите:
https://dzen.ru/kznalp

Контакты для СМИ

Имя: Сунгатуллин Ринат Раисович

Телефон: +7 927 245 80 49

Email: kznalp@yandex.ru

Веб-сайт: https://dzen.ru/kznalp

Вопрос

Какие значения метрики vmstat могут являться причиной роста ожиданий СУБД PostgreSQL?

Ответ

⚙️ 1. Высокое значение wa (I/O wait)

Что показывает:

• Процент времени, когда процессоры простаивают в ожидании завершения операций ввода-вывода (I/O).

Причины роста ожиданий СУБД:

• Медленная дисковая подсистема (например, высокая задержка записи/чтения).

• Интенсивные операции записи WAL (Write-Ahead Log) или чтения больших данных.

• Недостаточная производительность хранилища (например, перегруженные диски RAID или облачные диски с ограниченным IOPS).

Связь с PostgreSQL:

Рост wa часто коррелирует с ожиданиями типа IO в PostgreSQL (например, datafile read, wal write) .

📊 2. Высокие значения bi (blocks in) и bo (blocks out)

Что показывают:

• Количество блоков, читаемых (bi) и записываемых (bo) с диска в секунду.

Причины роста ожиданий СУБД:

• Активная работа с большими объемами данных (например, полное сканирование таблиц, интенсивная запись WAL).

• Неэффективные запросы, вызывающие чрезмерный I/O.

Связь с PostgreSQL:

Высокие bi/bo могут указывать на проблемы с ожиданиями BufferPin или IO в PostgreSQL .

💻 3. Низкое значение id (idle time) при высоком us (user time) или sy (system time)

Что показывает:

• us: Время выполнения пользовательских процессов (например, вычисления в PostgreSQL).

• sy: Время выполнения системных вызовов (например, управление памятью, планировщик ОС).

Причины роста ожиданий СУБД:

• Высокая нагрузка на CPU из-за сложных запросов (агрегации, JOINs).

• Конкуренция за ресурсы CPU (например, из-за параллельных процессов).

• Резкий рост sy может указывать на проблемы с системными вызовами (например, частое переключение контекста).

Связь с PostgreSQL:

Это может коррелировать с ожиданиями CPU в PostgreSQL или блокировками (например, LWLock) .

🔄 4. Рост значения b (processes sleeping)

Что показывает:

• Количество процессов, находящихся в состоянии ожидания (например, из-за I/O или блокировок).

Причины роста ожиданий СУБД:

• Процессы PostgreSQL ждут завершения I/O-операций или освобождения блокировок.

• Высокая конкуренция за ресурсы (диск, память, CPU).

Связь с PostgreSQL:

Прямо указывает на процессы, которые могут быть заблокированы в состоянии waiting в pg_stat_activity .

💾 5. Аномалии с swpd (swap used) и si/so (swap in/out)

Что показывают:

• Использование swap-памяти и активность обмена с диском.

Причины роста ожиданий СУБД:

• Нехватка оперативной памяти (например, из-за большого shared_buffers или неоптимизированных запросов).

• Активное использование swap приводит к резкому росту I/O-ожиданий.

Связь с PostgreSQL:

Может вызывать ожидания, связанные с памятью (например, buffer read) или общим замедлением из-за свопинга .

📈 6. Сочетание высокого wa с низким id и высокими bi/bo

Интерпретация:

• Это классический признак I/O-bound системы, где диск становится узким местом.

Пример:

Если wa постоянно превышает 20-30%, а id близок к 0, это указывает на перегруженность дисковых подсистем .

💎 Рекомендации по анализу:

Пороговые значения:

1. wa > 10-15% часто указывает на проблему с I/O.

2. us + sy > 80% может сигнализировать о нехватке CPU.

3. si/so > 0 — тревожный признак нехватки памяти.

Эти метрики помогают быстро определить тип проблемы (I/O, CPU, память) и начать углубленный анализ именно тех компонентов, которые вызывают ожидания в СУБД.

🚨 Пример из практики:

В PG_HAZEL : Определение причин инцидента производительности СУБД описывается инцидент, где рост wa в vmstat сопровождался увеличением времени записи на дисках /data и /wal, что прямо коррелировало с ростом ожиданий типа IO в PostgreSQL.

Дополнительные материалы

Анализ и аудит состояния инфраструктуры сервера СУБД с точки зрения связи производительности СУБД и состояния операционной системы.

Задача

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

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

VMSTAT : Корреляция и причинно-следственная связь роста CS и снижения производительности СУБД PostgreSQL

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

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

...

Вывод

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

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

1. Процесс инициирует ожидание: Сеанс PostgreSQL в процессе выполнения запроса достигает точки, где он не может продолжить работу без какого-то ресурса.
   Пример 1: Ему нужна страница данных с диска. Он инициирует операцию I/O и добровольно переходит в состояние сна (sleep), ожидая её завершения. Это регистрируется как wait event DataFileRead.
   Пример 2: Он пытается изменить строку, но другая транзакция удерживает на ней блокировку. Сеанс вынужденно переходит в состояние сна, ожидая освобождения блокировки. Это регистрируется как wait event lock.

2. Реакция планировщика задач ОС: Когда процесс PostgreSQL переходит в состояние сна (добровольно или вынужденно), он отдает свой квант времени процессора. Планировщик задач ОС фиксирует это и производит переключение контекста (cs), чтобы отдать освободившееся процессорное время другому готовому к выполнению процессу (например, другому сеансу БД или процессу самой ОС).

3. Результат: Таким образом, каждое ожидание внутри PostgreSQL (кроме ожидания CPU) приводит к тому, что процесс будет "усыплен", и ОС будет вынуждена выполнить переключение контекста, чтобы не простаивать. Чем больше сеансов одновременно находятся в состоянии ожидания, тем чаще ОС приходится переключаться между ними и другими процессами — рост cs.

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

📅 Дата публикации: 15 сентября 2025 года
📍 Место: Россия

Новая веха в мониторинге и диагностике производительности PostgreSQL

Комплекс PG_HAZEL представляет собой инновационное решение для глубокого анализа производительности СУБД PostgreSQL. Этот инструмент сочетает в себе методы статистического анализа, мониторинга в реальном времени и причинно-следственного моделирования, что позволяет точно определять корневые причины инцидентов производительности и прогнозировать потенциальные сбои.

PG_HAZEL использует методы корреляционного анализа для установления взаимосвязей между:

• Метриками ОС (iostat, vmstat, использование CPU, памяти, дискового I/O).

• Ожиданиями СУБД PostgreSQL (типы ожиданий IO, IPC, LWLock, и др.).

• Показателями производительности СУБД (операционная скорость, ожидания СУБД, индикатор деградации производительности СУБД).

💡 Ключевые особенности PG_HAZEL

1. Тактический и оперативный анализ
   PG_HAZEL работает на тактическом уровне, анализируя влияние отдельных SQL-запросов на производительность СУБД. Он идентифицирует запросы, которые оказывают наибольшее негативное воздействие, и связывает их с конкретными типами ожиданий (IO, IPC, LWLOCK).

2. Многомерный анализ производительности
   PG_HAZEL интегрирует данные из различных источников, включая метрики ОС (iostat, vmstat), события ожидания PostgreSQL и статистику выполнения SQL-запросов. Это позволяет построить единую модель производительности и количественно оценить вклад каждого фактора в общую производительность СУБД.

3. Планируемое направление развития : причинно-следственный анализ и прогнозное моделирование, визуализация и интерактивные дашборды
   Используя методы причинности по Грэнджеру и байесовские сети, комплекс поможет выявляет не просто корреляции, а реальные причинно-следственные связи между метриками. Например, он может определить, что рост времени отклика диска (await) вызывает увеличение времени ожидания ввода-вывода в PostgreSQL, что приводит к деградации производительности. Используя методы ARIMA и машинного обучения возможно будет прогнозировать инциденты производительности СУБД PostgreSQL , таких как исчерпание дискового пространства или достижение критической нагрузки на CPU. Это позволит администраторам СУБД заранее принимать превентивные меры.
   Тепловые карты(heatmaps) корреляций и дашборды, позволят быстро выявлять аномалии и анализировать их в контексте всех метрик.

🚀 Практическое применение

PG_HAZEL уже успешно применяется для анализа инцидентов производительности в реальных условиях.

Кроме того, комплекс используется для нагрузочного тестирования, помогая определить предельные значения нагрузки, которые СУБД может выдержать без деградации производительности.
📈 Преимущества подхода

Раннее обнаружение проблем

Анализ метрик ОС позволяет выявлять потенциальные проблемы до их воздействия на производительность СУБД:

• Прогнозирование исчерпания дискового пространства

• Выявление растущей нагрузки на CPU и память

• Обнаружение деградации производительности дисковых подсистем

Снижение времени восстановления

Точное определение корневой причины инцидентов значительно сокращает время восстановления:

• Четкое разграничение проблем ОС и проблем СУБД

• Возможность фокусирования на реальной причине, а не симптомах

📊 Примеры использования:

1.Рост ожиданий типа IO в PostgreSQL:

В ходе анализа инцидента производительности PG_HAZEL выявил, что наибольшая корреляция наблюдается между ожиданиями типа IPC и снижением операционной скорости СУБД. Это указало на проблему взаимодействия между процессами, что позволило администраторам быстро устранить причину.

2.Рост времени отклика дисков в iostat:

1. Начало инцидента: Рост утилизации CPU и значений iowait в метриках ОС

2. Корреляционный анализ: Выявление высокой корреляции между:
   - Ростом времени ожидания записи для устройств хранения (/data и /wal)
   - Снижением производительности СУБД
   - Ростом ожиданий типа IO в PostgreSQL

3. Заключение: Первичной причиной являлись проблемы на уровне дисковых подсистем

💬 Цитата разработчика

«PG_HAZEL — это не просто инструмент мониторинга, а экспертная система, которая превращает разрозненные метрики в понятные и осуществимые предложения. Наша цель — сделать диагностику производительности PostgreSQL максимально автоматизированной и точной».

🔮 Планы развития

В ближайших планах развития PG_HAZEL — разработка и внедрение методов причинно-следственного анализа и прогнозного моделирования.

📌 О компании

Разработчик PG_HAZEL специализируется на создании решений для мониторинга и анализа производительности СУБД PostgreSQL.

Наша миссия — помогать компаниям поддерживать высокую производительность и надежность их баз данных.

📞 Контакты для СМИ

Для получения дополнительной информации обращайтесь:
Имя: Сунгатуллин Ринат Раисович
Телефон: +7 927 245 80 49
Email: kznalp@yandex.ru
Веб-сайт: https://dzen.ru/kznalp

💎 Заключение

PG_HAZEL устанавливает новый стандарт в мониторинге и диагностике производительности PostgreSQL. Его способность объединять данные из различных источников, выявлять корневые причины проблем и прогнозировать инциденты делает его незаменимым инструментом для администраторов баз данных и IT-специалистов.

Для получения более подробной информации посетите https://dzen.ru/kznalp.

PG_HAZEL : комплексное решение для мониторинга и анализа производительности СУБД PostgreSQL.

PG_HAZEL : Определение причин инцидента производительности СУБД

Наибольшая корреляция между ожиданиями СУБД и типом ожиданий IO.

ALARM: более 50% наблюдений - Отклик на запись свыше 5мс

Вопрос

Какое событие является первичным - рост ожиданий чтения/записи в метрике iostat(проблемы устройства) или рост ожиданий типа IO в СУБД PostgreSQL ?

Ответ

Отличный и очень правильный вопрос, который затрагивает самую суть диагностики проблем с производительностью в связке СУБД-жесткий диск.

Короткий ответ: Первичным почти всегда является рост ожиданий чтения/записи в iostat (проблемы на уровне устройства). Рост ожиданий ввода-вывода (I/O wait) в PostgreSQL — это уже следствие этой проблемы.

Продолжение и подробности: PG_HAZEL + IOSTAT : Определение причин инцидента производительности СУБД