Серия «СУБД PostgreSQL»

Теоретическая часть и рекомендация нейросети

📉 Гипотеза по уменьшению shared_buffers

Для данной OLAP-нагрузки и текущей конфигурации сервера снижение размера shared_buffers с 4 ГБ до 1-2 ГБ, с одновременным увеличением work_mem, приведет к росту общей производительности системы. Основная цель — не просто уменьшить кэш БД, а перенаправить высвободившуюся оперативную память на выполнение операций в памяти и ослабить нагрузку на подсистему ввода-вывода.

Параметры операционной системы

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 30

vm.dirty_background_ratio = 10

vm.vfs_cache_pressure = 100

vm.swappiness = 10

read_ahead_kb = 4096

Нагрузка на СУБД в ходе экспериментов

Эксперимент-1: shared_buffers = 4GB + work_mem=32MB

work_mem

----------

32MB

shared_buffers

----------------

4GB

Эксперимент-2: shared_buffers = 2GB + work_mem=256MB

work_mem

----------

256MB

shared_buffers

----------------

2GB

Корреляционный анализ ожиданий

Операционная скорость

Среднее снижение операционной скорости при shared_buffers=2GB(work_mem=256MB) составило 38.38%.

Ожидания типа IO

Среднее увеличение ожиданий типа IO при shared_buffers=2GB(work_mem=256MB) составило 22.70%.

Ожидания типа IPC

Среднее снижение ожиданий типа IPC при shared_buffers=2GB(work_mem=256MB) составило 4.78%.

Производительность подсистемы IO(IOPS) для файловой системы /data

Среднее снижение IOPS при shared_buffers=2GB(work_mem=256MB) составило 3.29%.

Пропускная способность подсистемы IO(MB/s) для файловой системы /data

Среднее снижение пропускной способности(MB/s) при shared_buffers=2GB(work_mem=256MB) составило 313.74%.

Сводный отчет по влиянию параметров shared_buffers и work_mem на производительность инфраструктуры при OLAP-нагрузке

1. Общие характеристики нагрузки

• Нагрузка соответствует OLAP-сценарию (аналитические запросы, большие объёмы данных).

• В обоих экспериментах наблюдался рост нагрузки (Load average увеличился с 5 до 22).

• Параметры экспериментов:
  Эксперимент-1: shared_buffers = 4GB, work_mem = 32MB
  Эксперимент-2: shared_buffers = 2GB, work_mem = 256MB

2. Влияние на производительность ввода-вывода (I/O)

Эксперимент-1 (4GB / 32MB)

• Высокий I/O wait (wa): 100% наблюдений с wa > 10%.

• Корреляция ожиданий IO и записи (bo): высокая (0.6533), система ограничена производительностью записи на диск.

• Состояние процессов (b): слабая корреляция с ожиданиями IO (0.2611), количество процессов в состоянии непрерываемого сна не возрастает значительно.

• Отношение прочитанных блоков к изменённым: 177.98, подтверждение OLAP-нагрузки.

Эксперимент-2 (2GB / 256MB)

• Высокий I/O wait (wa): 97.27% наблюдений с wa > 10%.

• Корреляция ожиданий IO и записи (bo): высокая (0.6719), система также ограничена записью.

• Состояние процессов (b): очень высокая корреляция с ожиданиями IO (0.8774), процессы всё чаще переходят в состояние непрерываемого сна (ожидание диска).

• Отношение прочитанных блоков к изменённым: 268.01, нагрузка ещё более ориентирована на чтение.

Сравнение

• Уменьшение shared_buffers с 4GB до 2GB привело к усилению корреляции между ожиданием IO и блокированными процессами.

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

3. Влияние на использование оперативной памяти (RAM)

Эксперимент-1 (4GB / 32MB)

• Свободная RAM: менее 5% в 100% наблюдений.

• Свопинг (swap in/out): используется незначительно (в 9.01% и 1.8% наблюдений соответственно).

Эксперимент-2 (2GB / 256MB)

• Свободная RAM: менее 5% в 100% наблюдений.

• Свопинг: не используется (0% наблюдений).

Сравнение

• Оба эксперимента показывают критически низкое количество свободной RAM.

• Свопинг практически отсутствует, что может указывать на эффективное использование файлового кэша ОС.

4. Влияние на эффективность кэширования (Shared buffers)

Эксперимент-1 (4GB / 32MB)

• Hit Ratio: 55.36% (критически низкий).

• Корреляция hit/read: очень высокая (0.9725), кэширование связано с большим чтением с диска.

Эксперимент-2 (2GB / 256MB)

• Hit Ratio: 38.58% (ещё ниже, критически низкий).

• Корреляция hit/read: очень высокая (0.8698), аналогичная картина.

Сравнение

• Уменьшение shared_buffers с 4GB до 2GB привело к снижению Hit Ratio на ~16.78%.

• В обоих случаях кэширование недостаточно эффективно для данной нагрузки.

5. Влияние на загрузку центрального процессора (CPU)

Эксперимент-1 (4GB / 32MB)

• Корреляция LWLock и user time: очень высокая (0.9775).

• Корреляция LWLock и system time: очень высокая (0.9092).

• Очередь процессов (r): превышение числа ядер CPU в 16.22% наблюдений.

• System time (sy): не превышает 30% (все наблюдения).

Эксперимент-2 (2GB / 256MB)

• Корреляция LWLock и user time: очень высокая (0.8574).

• Корреляция LWLock и system time: высокая (0.6629).

• Очередь процессов (r): превышение числа ядер CPU в 3.64% наблюдений.

• System time (sy): не превышает 30% (все наблюдения).

Сравнение

• В Эксперименте-1 выше корреляция LWLock с системным временем, что может указывать на большее количество системных вызовов и переключений контекста.

• Очередь процессов (r) чаще превышает число ядер CPU в Эксперименте-1, но в обоих случаях это не является критичным.

6. Выводы по влиянию параметров

• Уменьшение shared_buffers с 4GB до 2GB:
  Привело к снижению Hit Ratio (с 55.36% до 38.58%).
  Усилило корреляцию между ожиданием IO и блокированными процессами.
  Не вызвало существенных изменений в использовании свопинга и свободной RAM.

• Увеличение work_mem с 32MB до 256MB:
  Не компенсировало снижение эффективности кэширования при уменьшении shared_buffers.
  Не привело к значительным изменениям в поведении CPU и очереди процессов.

• Общий характер нагрузки (OLAP) подтверждается высоким отношением чтения к записи и сильной зависимостью производительности от операций ввода-вывода.

Сводный отчет по влиянию параметров shared_buffers и work_mem на производительность подсистемы IO диска vdd для OLAP-нагрузки

1. Общая характеристика инфраструктуры и экспериментов

• Диск данных: vdd (100 ГБ, LVM-том 99 ГБ, точка монтирования /data)

• Конфигурация сервера:
  8 CPU ядер
  8 ГБ RAM
  Отдельные диски для WAL (/wal) и логов (/log)

• Параметры сравнения:
  Эксперимент 1: shared_buffers = 4 ГБ, work_mem = 32 МБ
  Эксперимент 2: shared_buffers = 2 ГБ, work_mem = 256 МБ

• Продолжительность тестов: ≈110 минут каждый

2. Количественные показатели производительности подсистемы IO

2.1. Средние значения по экспериментам

Эксперимент 1 (shared_buffers=4GB, work_mem=32MB):

• Средняя утилизация диска: 90-94% → 80% (снижение к концу теста)

• Средний IOPS: ≈3500 операций/сек

• Средняя пропускная способность: ≈130 МБ/с → 180 МБ/с (рост к концу)

• Среднее время ожидания чтения: 9-14 мс

• Среднее время ожидания записи: 6-7 мс

• Средняя длина очереди: ≈43

• Средняя загрузка CPU на IO: ≈24%

Эксперимент 2 (shared_buffers=2GB, work_mem=256MB):

• Средняя утилизация диска: 93-97% (стабильно высокая)

• Средний IOPS: ≈3400 операций/сек

• Средняя пропускная способность: ≈139 МБ/с → 95-149 МБ/с (колебания)

• Среднее время ожидания чтения: 10-19 мс

• Среднее время ожидания записи: 7-10 мс

• Средняя длина очереди: ≈33 → 61 (рост)

• Средняя загрузка CPU на IO: ≈28% → 9% (снижение)

3. Качественные характеристики нагрузки

3.1. Характер ограничения производительности

Эксперимент 1:

• Тип ограничения: Пропускная способность диска

• Корреляция скорость-MB/s: Очень высокая (0.8191)

• Корреляция скорость-IOPS: Слабая (0.4128)

• Вывод: Производительность определяется объемом передаваемых данных

Эксперимент 2:

• Тип ограничения: Количество операций ввода-вывода

• Корреляция скорость-IOPS: Очень высокая (0.9256)

• Корреляция скорость-MB/s: Слабая (0.1674)

• Вывод: Нагрузка чувствительна к количеству IO операций

4. Влияние изменения параметров на поведение системы

4.1. Динамика изменения показателей во времени

Эксперимент 1 (shared_buffers=4GB):

• Утилизация диска снижается с 94% до 80% к концу теста

• Пропускная способность растет с 132 МБ/с до 180 МБ/с

• Загрузка CPU на IO снижается с 28% до 18%

• Стабильные показатели IOPS и времени отклика

Эксперимент 2 (shared_buffers=2GB):

• Высокая и стабильная утилизация диска (93-97%)

• Колебания пропускной способности (139 → 95 → 149 МБ/с)

• Значительный рост длины очереди (33 → 61)

• Увеличение времени ожидания чтения (10 → 19 мс)

• Снижение загрузки CPU на IO (28% → 9%)

4.2. Сравнительные изменения при уменьшении shared_buffers и увеличении work_mem

• Утилизация диска: Повысилась и стабилизировалась на высоком уровне

• Время отклика: Увеличилось время ожидания операций чтения

• Длина очереди: Выросла в 1.8 раза к концу теста

• Загрузка CPU на IO: Снизилась в 3 раза

• Характер нагрузки: Сместился с пропускной способности на IOPS-ограниченный режим

• Стабильность пропускной способности: Ухудшилась, появились значительные колебания

5. Выводы о влиянии конфигурации на OLAP-нагрузку

5.1. Конфигурация shared_buffers=4GB, work_mem=32MB:

• Обеспечивает более предсказуемую пропускную способность

• Демонстрирует улучшение производительности в ходе теста

• Оптимальна для операций, требующих последовательного чтения больших объемов данных

• Меньшая длина очереди и время отклика

5.2. Конфигурация shared_buffers=2GB, work_mem=256MB:

• Создает более высокую и стабильную нагрузку на диск

• Приводит к увеличению времени отклика операций

• Смещает характер нагрузки в сторону большего количества мелких операций

• Снижает нагрузку на CPU для операций ввода-вывода

• Увеличивает глубину очереди запросов к диску

Предисловие

В условиях растущих требований к обработке больших данных и аналитическим нагрузкам (OLAP) критически важной становится не только настройка самой СУБД, но и тонкая оптимизация операционной системы, на которой она работает. Однако в современных исследованиях и практических руководствах наблюдается значительный пробел: рекомендации по настройке PostgreSQL часто ограничиваются параметрами самой СУБД, в то время как влияние параметров ядра Linux на производительность базы данных остаётся малоизученной областью.

Данная работа направлена на заполнение этого пробела. Фокус исследования сосредоточен на влиянии параметра ядра Linux vm.vfs_cache_pressure на производительность PostgreSQL под синтетической OLAP-нагрузкой. Этот параметр контролирует агрессивность, с которой ядро освобождает кэш файловой системы (VFS cache), что в теории может напрямую влиять на поведение СУБД, активно работающей с файлами данных.

Исследование носит экспериментальный характер и построено на методологии нагрузочного тестирования с использованием специализированного инструмента pg_expecto. В качестве тестовой среды используется конфигурация, типичная для небольших аналитических серверов: 8 CPU, 8 GB RAM, дисковая подсистема, подверженная ограничениям пропускной способности. Это позволяет смоделировать условия, в которых грамотная настройка ОС может стать ключом к раскрытию дополнительной производительности или, наоборот, источником проблем.

Ценность данной работы заключается в её практической ориентированности. Она предоставляет администраторам баз данных и системным инженерам не только конкретные данные о влиянии настройки, но и методологию анализа комплексного поведения системы (СУБД + ОС) под нагрузкой, выходящую за рамки простого мониторинга TPS (транзакций в секунду).

Предпосылка к исследованию

Отсутствие специализированных исследований: Поиск в научных базах данных (Google Scholar, IEEE Xplore) и технических блогах по запросам "vfs_cache_pressure PostgreSQL performance", "Linux kernel tuning for database workload" не выявил работ, фокусирующихся на экспериментальном изучении данного конкретного взаимодействия. Основная масса материалов предлагает общие советы или рассматривает настройку памяти PostgreSQL в отрыве от тонких параметров ОС.

Задача

Оценить влияние изменения параметра vm.vfs_cache_pressure на производительность СУБД и инфраструктуры при синтетической нагрузке, имитирующей OLAP.

Параметры инфраструктуры

vm.dirty_expire_centisecs=3000

vm.dirty_ratio=30

vm.dirty_background_ratio=10

vm.swappiness=10

read_ahead_kb=4096

Параметры СУБД

shared_buffers = '4GB'

effective_cache_size = '6GB'

work_mem = '32MB'

Нагрузка на СУБД в ходе экспериментов

Отношение прочитанных блоков shared_buffers к измененным блокам shared_buffers (OLAP):

• vm.vfs_cache_pressure = 100 : 177.98

• vm.vfs_cache_pressure = 50 : 184.26

• vm.vfs_cache_pressure = 150 : 172.22

Часть 1 - Общая постановка исследования и результаты производительности СУБД и инфраструктуры.

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

Операционная скорость

Медианные значения операционной скорости:

• vm.vfs_cache_pressure = 100 : 15 154 (baseline)

• vm.vfs_cache_pressure = 50 : 16 185 (-11.27%)

• vm.vfs_cache_pressure = 150 : 15 095 (+8.65%)

Ожидания типа IO

Медианные значения ожиданий типа IO:

• vm.vfs_cache_pressure = 100 : 16 716 (baseline)

• vm.vfs_cache_pressure = 50 : 19 411 (+16,12%)

• vm.vfs_cache_pressure = 150 : 16 762 (+0,27%)

Ожидания типа LWLock

Медианные значения ожиданий типа LWLock:

• vm.vfs_cache_pressure = 100 : 178(baseline)

• vm.vfs_cache_pressure = 50 : 113 (-36,52%)

• vm.vfs_cache_pressure = 150 : 167 (-6,46%)

Производительность подсистемы IO (IOPS) файловой системы /data

Медианные значения IOPS:

• vm.vfs_cache_pressure = 100 : 3 502(baseline)

• vm.vfs_cache_pressure = 50 : 3 479(-0,66%)

• vm.vfs_cache_pressure = 150 : 3 582 (+2,28%)

Пропускная способность подсистемы IO (MB/s) файловой системы /data

Медианные значения MB/s:

• vm.vfs_cache_pressure = 100 : 125(baseline)

• vm.vfs_cache_pressure = 50 : 103(-17,60%)

• vm.vfs_cache_pressure = 150 : 135 (+8,00%)

Часть 2 - Анализ паттернов производительности инфраструктуры

Входные данные для анализа

Сводный отчета по нагрузочному тестированию подготовленный pg_pexpecto по окончании нагрузочного тестирования:

• Метрики производительности и ожиданий СУБД

• Метрики vmstat

• Метрики iostat

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

• Корреляционный анализ метрик vmstat

• Корреляционный анализ метрик iostat

Общий анализ инфраструктуры при разном значении vm.vfs_cache_pressure

1. Влияние на IO-ожидания (wa)

Общая проблема: Во всех трёх экспериментах 100% наблюдений показывают wa > 10%, что свидетельствует о системном ограничении дисковой подсистемы.

Сравнение корреляций при разных значениях vm.vfs_cache_pressure:

vm.vfs_cache_pressure=50:

• Корреляция IO-wa: -0,0772 (отсутствует/отрицательная) ✅

• Корреляция IO-b: 0,0609 (слабая/средняя) ℹ️

• Корреляция IO-bi: 0,3650 (слабая/средняя) ℹ️

• Корреляция IO-bo: 0,2693 (слабая/средняя) ℹ️

vm.vfs_cache_pressure=100:

• Корреляция IO-wa: -0,9020 (отсутствует/отрицательная) ✅

• Корреляция IO-b: 0,2611 (слабая/средняя) ℹ️

• Корреляция IO-bi: 0,2730 (слабая/средняя) ℹ️

• Корреляция IO-bo: 0,6533 (высокая) ⚠️

vm.vfs_cache_pressure=150:

• Корреляция IO-wa: -0,7379 (отсутствует/отрицательная) ✅

• Корреляция IO-b: 0,0000 (отсутствует/отрицательная) ✅

• Корреляция IO-bi: 0,5074 (высокая) ⚠️

• Корреляция IO-bo: 0,5532 (высокая) ⚠️

Вывод: Увеличение vfs_cache_pressure усиливает корреляцию IO-ожиданий с операциями чтения/записи (bi/bo), что указывает на более агрессивное управление кэшем файловой системы.

2. Паттерны использования процессов в состоянии D (непрерываемый сон)

Наблюдаемый феномен:

· При vfs_cache_pressure=50: ALARM по регрессионной линии (R²=0,7, угол наклона 39,83)

· При vfs_cache_pressure=100: R²=0,03, угол наклона 10,38 (норма)

· При vfs_cache_pressure=150: R²=0,00, угол наклона 0,00 (норма)

Объяснение с точки зрения управления кэшем:

• При низком значении vfs_cache_pressure(50) ядро менее агрессивно вытесняет кэш файловой системы

• Это приводит к накоплению большего объёма кэшированных данных

При OLAP-нагрузке с интенсивным чтением это вызывает:

• Более частые блокировки процессов в состоянии D при обращении к диску

• Увеличение времени ожидания из-за конкуренции за IO-ресурсы

При значениях 100 и 150 кэш вытесняется активнее, что снижает конкуренцию и количество процессов в состоянии D

3. Производительность дисковой подсистемы и кэширования

Общие характеристики нагрузки (все эксперименты):

• Соотношение чтения к записи: ~180:1 (типичный OLAP-паттерн)

• Очень высокая корреляция скорости операций с чтением (0,85-0,88)

• Очень высокая корреляция скорости операций с записью (0,98-0,99)

• Система ограничена производительностью диска

Влияние pressure на эффективность shared buffers:

• HIT RATIO shared buffers: 55-58% (критически низкий во всех случаях)

• Корреляция shared_blks_hit - shared_blks_read: 0,96-0,97 (очень высокая)

• Вывод: vfs_cache_pressure практически не влияет на HIT RATIO PostgreSQL, так как shared buffers управляются отдельно от кэша файловой системы

Ключевые выводы по экспериментам

Лучшие показатели у pressure=100:

• Отсутствие роста процессов в состоянии D

• Умеренные корреляции с операциями чтения/записи

• Стабильное поведение системы

Проблемные зоны (все эксперименты):

• Критически низкий HIT RATIO shared buffers (55-58%)

• 100% наблюдений с wa > 10%

• Система ограничена производительностью диска

Рекомендации по оптимизации для OLAP-нагрузки

1. Настройки операционной системы:

Установить vm.vfs_cache_pressure = 100 (компромиссное значение)

Пересмотреть настройки vm.dirty_*:

• Уменьшить vm.dirty_background_ratio с 10 до 5

• Уменьшить vm.dirty_ratio с 30 до 20

• Это снизит латентность записи

Проверить и оптимизировать параметры файловой системы

2. Настройки PostgreSQL для OLAP:

• Увеличить shared_buffers с 4GB до 6GB (при 8GB RAM)

• Увеличить work_mem с 32MB до 128-256MB для сложных сортировок

• Увеличить effective_cache_size до 6-7GB

• Рассмотреть увеличение max_parallel_workers_per_gather с 1 до 2-4

• Установить random_page_cost = 1.0 (если используются SSD)

3. Аппаратные улучшения:

• Рассмотреть переход на более быстрые диски (NVMe SSD)

• Увеличить объём оперативной памяти с 8GB

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

Анализ влияния vfs_cache_pressure на управление RAM

1. Использование оперативной памяти

Общая ситуация:

• Во всех экспериментах свободная RAM < 5% в более 50% наблюдений - это норма для сервера с активной нагрузкой

• Оперативная память практически полностью используется (7-7.2GB из 8GB)

Динамика memory_swpd (использование свопа):

• vfs_cache_pressure=50: Рост с 209 MB до 347 MB (+138 MB за 110 минут)

• vfs_cache_pressure=100: Рост с 260 MB до 328 MB (+68 MB за 111 минут)

• vfs_cache_pressure=150: Рост с 246 MB до 338 MB (+92 MB за 110 минут)

Анализ скорости роста:

• Наиболее медленный рост swpd при vfs_cache_pressure=100 (68 MB за период)

• Наиболее быстрый рост при vfs_cache_pressure=50 (138 MB за период)

• Промежуточный рост при vfs_cache_pressure=150 (92 MB за период)

Стабильность использования памяти:

Наиболее стабильное поведение при vfs_cache_pressure=100:

• Наименьший рост использования свопа

• Плавное изменение memory_swpd без резких скачков

• Более предсказуемое управление памятью

Наименее стабильное поведение при vfs_cache_pressure=50:

• Быстрый рост использования свопа

• Более агрессивное вытеснение данных в своп

2. Свопинг (swap in/out)

Статистика по экспериментам:

vfs_cache_pressure=50:

• swap in: 10% наблюдений

• swap out: 6.36% наблюдений

• Баланс смещен в сторону чтения из свопа

При vfs_cache_pressure=100:

• swap in: 9.01% наблюдений

• swap out: 1.80% наблюдений

• Минимальный объем записи в своп

vfs_cache_pressure=150:

• swap in: 10% наблюдений

• swap out: 11.82% наблюдений

• Наибольший объем записи в своп

Объяснение различий:

1. vfs_cache_pressure=50:

• Низкое давление на кэш файловой системы

• Ядро менее агрессивно освобождает кэш

• Чаще приходится читать из свопа (высокий swap in)

• Относительно низкий swap out - меньше данных вытесняется

2. vfs_cache_pressure=100:

• Оптимальный баланс

• Кэш управляется эффективно

• Минимальный swap out - редко требуется запись в своп

• Умеренный swap in - меньше обращений к свопу

3. vfs_cache_pressure=150:

• Высокое давление на кэш файловой системы

• Ядро агрессивно освобождает кэш

• Высокий swap out - активная запись в своп

• Высокий swap in - частые чтения из свопа

3. Кэширование и dirty pages

Взаимодействие vfs_cache_pressure с настройками vm.dirty_*:

Текущие настройки:

• vm.dirty_ratio=30 (запись блокируется при 30% dirty pages)

• vm.dirty_background_ratio=10 (фоновая запись при 10%)

• read_ahead_kb=4096 (4MB read-ahead)

Влияние pressure на dirty pages:

1. vfs_cache_pressure=50:

• Медленное освобождение кэша

• Больше данных остается в памяти

• Более высокий риск достижения dirty_ratio

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

2. vfs_cache_pressure=100:

• Сбалансированное управление

• Кэш освобождается своевременно

• Меньше риск блокировок из-за dirty pages

• Оптимально для текущих настроек dirty_*

3. vfs_cache_pressure=150:

• Быстрое освобождение кэша

• Меньше данных в кэше файловой системы

• Чаще требуется чтение с диска

• Возможна излишняя агрессивность для OLAP

Оптимальные значения для OLAP-нагрузки:

Для OLAP с большим чтением рекомендуется:

• vfs_cache_pressure=100-120 (компромиссное значение)

• read_ahead_kb=8192-16384 (увеличение для последовательного чтения)

• vm.dirty_background_ratio=5 (более частая фоновая запись)

• vm.dirty_ratio=20 (раньше начинать синхронную запись)

Обоснование:

• OLAP характеризуется последовательным чтением больших объемов данных

• Большой read-ahead улучшает производительность последовательного чтения

• Более низкие dirty_* значения снижают латентность записи

• vfs_cache_pressure=100 обеспечивает баланс между кэшированием и доступной памятью

Анализ влияния vfs_cache_pressure на CPU

1. Нагрузка на CPU

Ключевые наблюдения:

• Все эксперименты показывают очень высокую корреляцию LWLock с user time (0.96-0.98)

• Все эксперименты показывают очень высокую корреляцию LWLock с system time (0.91-0.95)

Распределение CPU времени по экспериментам:

vfs_cache_pressure=50:

• us (user time): 21-61% (среднее ~30%)

• sy (system time): 5-10% (среднее ~7%)

• wa (I/O wait): 17-31% (среднее ~27%)

• id (idle): 12-42% (среднее ~35%)

vfs_cache_pressure=100:

• us (user time): 25-57% (среднее ~35%)

• sy (system time): 5-10% (среднее ~7%)

• wa (I/O wait): 18-29% (среднее ~25%)

• id (idle): 14-41% (среднее ~33%)

vfs_cache_pressure=150:

• us (user time): 22-58% (среднее ~32%)

• sy (system time): 5-10% (среднее ~7%)

• wa (I/O wait): 16-28% (среднее ~24%)

• id (idle): 13-41% (среднее ~34%)

Влияние vfs_cache_pressure:

• User time: Наиболее высокий при pressure=100 (среднее 35%)

• System time: Практически идентичен во всех случаях (~7%)

• I/O wait: Наименьший при pressure=150 (среднее 24%)

• Idle time: Наибольший при pressure=50 (среднее 35%)

Вывод: Увеличение pressure снижает I/O wait, но незначительно увеличивает user time, что указывает на более активную обработку данных приложением.

2. Переключения контекста

Общая картина:

• Высокая корреляция переключений контекста с прерываниями (cs-in) во всех экспериментах (0.95-0.97)

• При vfs_cache_pressure=150 появляется слабая/средняя корреляция cs-sy (0.0244)

Влияние управления кэшем на переключения контекста:

Механизм влияния:

1. vfs_cache_pressure=50:

• Менее агрессивное управление кэшем

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

• Переключения контекста в основном вызваны прерываниями от дисковых операций

2. vfs_cache_pressure=100:

• Сбалансированное управление кэшем

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

• Прерывания остаются основной причиной переключений контекста

3. vfs_cache_pressure=150:

• Агрессивное управление кэшем

• Увеличение системных вызовов для управления памятью

• Появление корреляции cs-sy указывает на рост времени ядра на управление памятью

Объяснение корреляции cs-sy при pressure=150:

Ядро тратит больше времени на:

• Вытеснение страниц из кэша файловой системы

• Управление списками страниц памяти

• Обработку запросов на выделение/освобождение памяти

• Это приводит к увеличению system time и связанных с ним переключений контекста

3. Очередь выполнения (run queue)

Статистика по экспериментам:

vfs_cache_pressure=50:

• Проценты превышения ядер CPU: 7.27%

• Максимальное значение procs_r: 10 процессов

• Более стабильная очередь выполнения

vfs_cache_pressure=100:

• Проценты превышения ядер CPU: 16.22%

• Максимальное значение procs_r: 11 процессов

• Наименее стабильная очередь выполнения

vfs_cache_pressure=150:

• Проценты превышения ядер CPU: 14.55%

• Максимальное значение procs_r: 11 процессов

• Промежуточная стабильность

Анализ стабильности:

Наиболее стабильная очередь при pressure=50:

• Наименьший процент превышения ядер CPU (7.27%)

• Более равномерное распределение нагрузки

• Меньше конкуренции за CPU ресурсы

Наименее стабильная очередь при pressure=100:

• Наибольший процент превышения ядер CPU (16.22%)

• Более выраженная конкуренция за CPU

• Возможные задержки в обработке запросов

Рекомендации по балансировке vfs_cache_pressure

Для конфигурации: 8 CPU ядер, 8GB RAM, OLAP-нагрузка с интенсивным чтением

1. Оптимальный диапазон значений: vfs_cache_pressure = 90-110

Обоснование:

Компромисс между производительностью и стабильностью:

• vfs_cache_pressure=50: лучшая стабильность очереди выполнения, но выше I/O wait

• vfs_cache_pressure=150: ниже I/O wait, но выше нагрузка на ядро (system time)

• vfs_cache_pressure=100: баланс между этими крайностями

2. Сопутствующие настройки для OLAP-нагрузки:

Настройки операционной системы:

• vm.swappiness = 10 (уже установлено, оптимально для серверов)

• vm.dirty_background_ratio = 5 (уменьшить с 10 для более частой фоновой записи)

• vm.dirty_ratio = 20 (уменьшить с 30 для снижения латентности записи)

• read_ahead_kb = 16384 (увеличить для последовательного чтения OLAP)

Настройки PostgreSQL для 8 CPU ядер:

• max_parallel_workers_per_gather = 2-4 (увеличить с 1 для OLAP)

• max_worker_processes = 16 (уже установлено, оптимально)

• max_parallel_workers = 16 (уже установлено, оптимально)

• work_mem = 64-128MB (увеличить с 32MB для сложных сортировок)

Часть 3 - Анализ производительности подсистемы IO для файловой системы /data

Задача

Проанализировать параметра vm.vfs_cache_pressure на производительность подсистемы IO для дискового устройства, используемого файловой системой /data.

Входные данные для анализа

Сводный отчета по нагрузочному тестированию подготовленный pg_pexpecto по окончании нагрузочного тестирования:

• Метрики iostat для дискового устройства vdd

Анализ корреляций и типа нагрузки

vm.vfs_cache_pressure = 100

• Корреляция скорость–IOPS: слабая (0,4128).

• Корреляция скорость–MB/s: очень высокая (0,8191).

• Тип нагрузки: аналитическая/ETL, так как наблюдается высокая зависимость от пропускной способности диска, а не от IOPS.

Ограничивающий фактор: пропускная способность диска (MB/s).

Дополнительные наблюдения:

• Утилизация диска стабильно высокая (89–94%).

• Задержки чтения/записи умеренные (9–14 мс).

• Нагрузка на CPU в режиме ожидания I/O (wa) составляет 18–29%.

vm.vfs_cache_pressure = 50

• Корреляция скорость–IOPS: отрицательная (-0,2879).

• Корреляция скорость–MB/s: очень высокая (0,8017).

• Тип нагрузки: аналитическая/ETL с выраженной зависимостью от пропускной способности диска.

Ограничивающий фактор: пропускная способность диска (MB/s).

Дополнительные наблюдения:

• Утилизация диска близка к максимальной (95–96%).

• Задержки чтения растут со временем (до 16 мс).

• Отрицательная корреляция с IOPS указывает на возможные проблемы с CPU, блокировками или памятью.

• Нагрузка на CPU в режиме ожидания I/O (wa) достигает 31%.

vm.vfs_cache_pressure = 150

• Корреляция скорость–IOPS: слабая (0,5930).

• Корреляция скорость–MB/s: очень высокая (0,9735).

• Тип нагрузки: аналитическая/ETL с сильной зависимостью от пропускной способности диска.

Ограничивающий фактор: пропускная способность диска (MB/s).

Дополнительные наблюдения:

• Утилизация диска стабильно высокая (89–95%).

• Задержки чтения/записи низкие (6–11 мс).

• Нагрузка на CPU в режиме ожидания I/O (wa) снижается к концу теста (до 16%).

Сводные выводы

1. Все три эксперимента показывают схожую картину:

• Производительность ограничена пропускной способностью диска (MB/s), а не IOPS.

• Нагрузка носит аналитический/ETL-характер (последовательное чтение/запись больших объёмов данных).

2. Влияние vm.vfs_cache_pressure:

• Изменение параметра не оказало значительного влияния на тип нагрузки и ограничивающий фактор.

• Наилучшие показатели задержек и утилизации CPU наблюдаются при значении 150.

3. Рекомендации:

• Увеличить пропускную способность дисковой подсистемы .

• Настроить параметры PostgreSQL для аналитических нагрузок (work_mem, maintenance_work_mem, effective_io_concurrency).

• Рассмотреть использование партиционирования таблиц и параллельного выполнения запросов.

Сравнение метрик диска

Средние значения метрик по экспериментам:

vm.vfs_cache_pressure = 50:

• utilization: 95,1%

• r_await: 13,8 мс

• w_await: 6,6 мс

• IOPS: 3 490

• MB/s: 116,1

• aqu_sz: 43,8

• cpu_wa: 27,3%

vm.vfs_cache_pressure = 100:

• utilization: 92,7%

• r_await: 12,5 мс

• w_await: 7,0 мс

• IOPS: 3 513

• MB/s: 129,6

• aqu_sz: 40,5

• cpu_wa: 25,4%

vm.vfs_cache_pressure = 150:

• utilization: 92,7%

• r_await: 9,8 мс

• w_await: 7,3 мс

• IOPS: 3 570

• MB/s: 137,5

• aqu_sz: 33,5

• cpu_wa: 23,6%

Анализ влияния vfs_cache_pressure:

1. Задержки и утилизация диска:
   r_await последовательно снижается с ростом параметра: 13,8 мс (50) → 12,5 мс (100) → 9,8 мс (150)
   w_await незначительно увеличивается: 6,6 мс (50) → 7,0 мс (100) → 7,3 мс (150)
   Утилизация диска максимальна при значении 50 (95,1%), при 100 и 150 стабилизируется на уровне 92,7%
   Наилучшие показатели задержек чтения достигаются при максимальном значении 150

2. Связь с пропускной способностью и IOPS:
   Пропускная способность (MB/s) монотонно растёт: 116,1 (50) → 129,6 (100) → 137,5 (150)
   IOPS также увеличивается: 3 490 (50) → 3 513 (100) → 3 570 (150)
   Наблюдается чёткая тенденция: чем выше vfs_cache_pressure, тем выше производительность по пропускной способности

3. Поведение очереди запросов (aqu_sz):
   Длина очереди последовательно уменьшается: 43,8 (50) → 40,5 (100) → 33,5 (150)
   Это свидетельствует о более эффективной обработке запросов при высоких значениях параметра
   Уменьшение очереди коррелирует со снижением времени ожидания CPU (cpu_wa)

Ключевые выводы:

Увеличение vfs_cache_pressure до 150 даёт наиболее сбалансированные результаты:

• Наименьшие задержки чтения (9,8 мс против 13,8 мс при 50)

• Наибольшая пропускная способность (137,5 MB/s против 116,1 при 50)

• Самая короткая очередь запросов (33,5 против 43,8 при 50)

• Наименьшая нагрузка на CPU в режиме ожидания (23,6% против 27,3% при 50)

Параметр vfs_cache_pressure оказывает существенное влияние на производительность дисковой подсистемы:

• Более высокие значения способствуют более агрессивному освобождению кэша

• Это снижает contention за память и уменьшает задержки

• Однако может незначительно увеличить задержки записи

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

Итог исследования

Проведённое комплексное исследование убедительно демонстрирует, что параметр ядра Linux vm.vfs_cache_pressure оказывает статистически значимое и многогранное влияние на производительность PostgreSQL при OLAP-нагрузке, имитирующей последовательное чтение больших объёмов данных.

Ключевые обобщённые выводы:

1. Тип нагрузки является определяющим: Во всех экспериментах система упиралась в пропускную способность диска (MB/s), а не в IOPS, что характерно для аналитических (OLAP) паттернов с последовательным доступом. Это главный ограничивающий фактор в данной конфигурации.

2. Влияние на кэширование и память:

   Параметр практически не влияет на hit ratio внутреннего кэша PostgreSQL (shared buffers), что подтверждает их независимое управление.

   Однако он существенно влияет на управление кэшем файловой системы (VFS cache) и подкачкой (swap). Более низкие значения (50) приводят к меньшей агрессивности вытеснения кэша, что вызывает более быстрый рост использования свопа и большее количество процессов, блокированных в состоянии ожидания ввода-вывода (D-состояние). Более высокие значения (150) заставляют ядро активнее освобождать кэш.

3. Влияние на производительность диска: Наблюдается чёткая тенденция: с ростом vfs_cache_pressure увеличивается пропускная способность (MB/s) и снижаются задержки чтения (r_await). Наилучшие показатели дисковых операций были достигнуты при значении 150.

4. Влияние на загрузку CPU и стабильность: Значение параметра также влияет на баланс загрузки процессора. Более высокие значения снижают время ожидания ввода-вывода (wa), но могут незначительно повысить системное время (sy) из-за активного управления памятью и привести к менее стабильной очереди выполнения процессов (run queue).

5. Недостатки тестовой конфигурации: Исследование выявило системные проблемы, общие для всех тестов:

   • Критически низкий hit ratio shared buffers (55-58%), указывающий на недостаточный объём оперативной памяти для данной рабочей нагрузки.

   • Постоянно высокий уровень ожидания ввода-вывода (wa > 10%), подтверждающий, что диск является узким местом.

Общие рекомендации для OLAP-нагрузок на PostgreSQL:

• Аппаратные улучшения (более быстрые NVMe SSD, увеличение RAM) имеют высший приоритет для снятия выявленных ограничений.

• Оптимизация ОС: Уменьшение vm.dirty_* соотношений для снижения латентности записи и увеличение read_ahead_kb для ускорения последовательного чтения.

• Оптимизация PostgreSQL: Увеличение shared_buffers, work_mem, effective_cache_size и настройка параметров параллельного выполнения.

Анализ расхождений в рекомендациях: vm.vfs_cache_pressure = 100 vs 150

В исследовании содержится кажущееся противоречие: в Части 2 оптимальным названо значение 100, а в Части 3 — 150. Причина этих разных рекомендаций заключается не в ошибке, а в разном фокусе анализа и приоритетах, которые они отражают. Это наглядная иллюстрация того, что процесс оптимизации — это всегда выбор компромиссного решения из набора альтернатив.

Рекомендация из Части 2: vm.vfs_cache_pressure = 100

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

• Стабильность процессов: Отсутствие аномального роста процессов в состоянии D (блокировка).

• Управление памятью: Наиболее стабильное и предсказуемое использование свопа (наименьший рост).

• Сбалансированность: Умеренные корреляции между метриками, отсутствие экстремальных паттернов.

• Компромисс: Оптимальный баланс между удержанием данных в кэше и их своевременным освобождением.
  Приоритет: Надёжность и предсказуемость долгосрочной работы системы.

Рекомендация из Части 3: vm.vfs_cache_pressure = 150

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

• Производительность диска: Наивысшая пропускная способность (137.5 MB/s) и наименьшие задержки чтения (9.8 мс).

• Эффективность очереди: Самая короткая очередь запросов к диску, что указывает на более эффективную обработку.

• Разгрузка CPU: Наименьшая нагрузка процессора в режиме ожидания I/O (wa).

• Механизм: Агрессивное освобождение кэша снижает конкуренцию (contention) за оперативную память.
  Приоритет: Максимальная скорость обработки данных и минимизация времени выполнения задач.

Заключительный вывод по выбору значения

Обе рекомендации верны в своих контекстах. Выбор между 100 и 150 — это классический инженерный компромисс между «быстро» и «стабильно».

• Для продакшен-среды, где критически важны предсказуемость, стабильность и отсутствие аномалий (внезапные блокировки процессов), следует придерживаться рекомендации vm.vfs_cache_pressure = 100 (или диапазон 90-110).

• Для выделенных ETL-задач или пакетной аналитической обработки, где ключевая цель — минимизировать время выполнения и диск является подтверждённым узким местом, можно обоснованно применить значение vm.vfs_cache_pressure = 150 для получения максимальной пропускной способности, отдавая себе отчёт в потенциально возросшей нагрузке на подсистему памяти ядра.

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

В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы.

Задача

Проанализировать влияние уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД при имитации типа нагрузки "OLTP" в ходе нагрузочного тестирования.

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

sysctl vm.dirty_expire_centisecs

sysctl vm.dirty_ratio

sysctl vm.dirty_background_ratio

sysctl vm.vfs_cache_pressure

cat /sys/block/vdd/queue/read_ahead_kb

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 30

vm.dirty_background_ratio = 10

vm.vfs_cache_pressure = 100

4096

Изменение параметров vm.dirty*

# sysctl -w vm.dirty_ratio=10

vm.dirty_ratio = 10

# sysctl -w vm.dirty_background_ratio=5

vm.dirty_background_ratio = 5

Корреляционный анализ производительности и ожиданий СУБД

Операционная скорость

Среднее снижение операционной скорости, при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 1.33%

Ожидания СУБД

Среднее снижение ожиданий СУБД , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 0.26%

Сравнительный отчет по нагрузочному тестированию: BASELINE vs vm.dirty*

1. Общая характеристика системы в экспериментах

• Тип нагрузки: OLTP (оперативная обработка транзакций).

• Конфигурация СУБД PostgreSQL:
  Версия: PostgreSQL 17.
  Общие буферы (shared_buffers): 4 ГБ.
  Рабочая память (work_mem): 32 МБ.
  Максимальное количество соединений: 1000.
  Настройки autovacuum агрессивные (интервал 1 секунда, масштабный коэффициент 0.01).

• Аппаратная конфигурация:
  CPU: 8 ядер (Intel Xeon Skylake).
  RAM: 8 ГБ.
  Дисковая подсистема: отдельные разделы для данных (/data, 100 ГБ), WAL (/wal, 50 ГБ), логов (/log, 30 ГБ).

2. Сравнительные паттерны ожиданий и производительности СУБД

Эксперимент 1 (базовые настройки):

• Основной тип ожиданий: IO (DataFileRead), доля 100%.

• Корреляция между общими ожиданиями (WAITINGS) и IO: 1.0 (полная линейная зависимость).

• Производительность (SPEED) слабо коррелирует с ожиданиями (коэффициент 0.05).

• Угол наклона линии регрессии для SPEED: положительный (+17.41), производительность росла.

• Угол наклона для WAITINGS: +43.5, ожидания постепенно увеличивались.

• Hit Ratio shared_buffers: ~90.74%, но кэширование слабо влияет на дисковую нагрузку.

Эксперимент 2 (уменьшенные vm.dirty_*):

• Основной тип ожиданий: IO (DataFileRead), доля 100%.

• Корреляция между WAITINGS и IO: 1.0 (полная линейная зависимость).

• Производительность (SPEED) сильно отрицательно коррелирует с ожиданиями (коэффициент -0.91).

• Угол наклона линии регрессии для SPEED: отрицательный (-40.4), производительность снижалась.

• Угол наклона для WAITINGS: +43.56, ожидания продолжали расти.

• Hit Ratio shared_buffers: ~90.73%, паттерн кэширования аналогичен.

Ключевые отличия:

• Во втором эксперименте наблюдалась сильная отрицательная корреляция между SPEED и WAITINGS, что указывает на более выраженное влияние ожиданий на падение производительности.

• Производительность во втором эксперименте снижалась, в то время как в первом — росла.

3. Сравнительные паттерны показателей vmstat/iostat

Общие для обоих экспериментов:

• Высокий процент ожидания IO (wa >10% в 100% наблюдений).

• Количество процессов в состоянии непрерываемого сна (b) превышало количество ядер CPU в 25-50% наблюдений.

• Сильная корреляция между IO и wa (~0.95), а также между IO и b (~0.97).

• Отсутствие своппинга (si/so = 0).

• Свободная память (free) менее 5% в 100% наблюдений.

• Высокая корреляция переключений контекста (cs) и прерываний (in) (~0.95-0.98).

Эксперимент 1:

• Максимальное значение wa: 69%.

• Максимальное значение b: 14 процессов.

• Корреляция SPEED и shared_blks_read: 0.8937 (сильная).

Эксперимент 2:

• Максимальное значение wa: 70%.

• Максимальное значение b: 14 процессов.

• Корреляция SPEED и shared_blks_read: 0.7063 (высокая, но ниже).

• Корреляция SPEED и shared_blks_write: -0.7101 (умеренная отрицательная).

Ключевые отличия:

• Во втором эксперименте наблюдался более выраженный рост b (процессов, ожидающих IO) и wa (времени ожидания IO).

• Зависимость производительности от операций чтения с диска осталась высокой, но несколько снизилась.

4. Итоговый вывод о характерных паттернах производительности и ожиданий СУБД и показателей vmstat/iostat для экспериментов

Единые паттерны для обоих экспериментов:

• Нагрузка имеет явный IO-бутылочное горлышко, связанное с операциями чтения данных (DataFileRead).

• Система испытывает дефицит оперативной памяти для эффективного кэширования (free <5%, но свопинг отсутствует).

• Высокая конкуренция за дисковые ресурсы приводит к росту процессов в состоянии непрерываемого сна (b) и времени ожидания IO (wa).

• Кэш shared_buffers незначительно снижает дисковую нагрузку, что типично для сценариев, где рабочий набор данных превышает доступную память.

• Нагрузка на CPU (us + sy) не является лимитирующим фактором.

Различия между экспериментами:

• Во втором эксперименте снижение производительности (SPEED) происходило более выраженно и было тесно связано с ростом ожиданий (WAITINGS).

• Уменьшение параметров vm.dirty_* не улучшило ситуацию с IO, а в некоторой степени усилило конкуренцию за запись.

Производительность подсистемы IO

IOPS (Производительность IO)

Среднее снижение IOPS , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 0.48%

MB/s (Пропуская способность IO)

Среднее снижение пропускной способности , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 1.34%

Отчет по анализу производительности подсистемы IO для файловой системы /data

Критические проблемы производительности по файловой системе для Эксперимента-1 и Эксперимента-2

Эксперимент-1 (базовые настройки):

• Постоянная 100% загрузка устройства (utilization) во всех наблюдениях

• Очень высокая корреляция между ожиданием IO процессором и загрузкой диска (wa - util: 0.9526)

• Высокая корреляция между объемом памяти для буферов и операциями записи (buff - w/s: 0.8728)

• Очень высокая корреляция между кэшированием и объемом чтения с диска (cache - rMB/s: 0.9545)

• 100% наблюдений с глубиной очереди запросов более 1

• 100% наблюдений с ожиданием IO процессором (wa) более 10%

Эксперимент-2 (уменьшенные vm.dirty параметры):

• Постоянная 100% загрузка устройства (utilization) во всех наблюдениях

• Очень высокая корреляция между ожиданием IO процессором и загрузкой диска (wa - util: 0.8587)

• Слабая/средняя корреляция между буферами и операциями записи (улучшение)

• Очень высокая корреляция между кэшированием и объемом чтения с диска (cache - rMB/s: 0.9827)

• 100% наблюдений с глубиной очереди запросов более 1

• 100% наблюдений с ожиданием IO процессором (wa) более 10%

Анализ корреляций и паттернов нагрузки по файловой системе

Эксперимент-1:

• Сильная прямая зависимость операционной скорости от чтения с диска (0.8937)

• Отрицательная корреляция между операционной скоростью и IOPS (-0.2424)

• Кэширование практически не влияет на дисковую нагрузку (корреляция shared_blks_hit - shared_blks_read: 0.0904)

• Высокий HIT RATIO (90.74%), но низкая эффективность кэширования

Эксперимент-2:

• Сильная прямая зависимость операционной скорости от чтения с диска (0.7063)

• Сильная отрицательная корреляция между операционной скоростью и IOPS (-0.7782)

• Отрицательная корреляция между кэшированием и операциями записи (-0.8629)

• Кэширование практически не влияет на дисковую нагрузку (корреляция shared_blks_hit - shared_blks_read: -0.1094)

Узкие места IO по файловой системе

Эксперимент-1:

• Дисковое устройство является основным узким местом

• Процессы блокируются в ожидании IO (высокий wa, процессы в uninterruptible sleep)

• Неэффективное использование памяти для буферизации и кэширования

• Высокая очередь запросов к диску

Эксперимент-2:

• Дисковое устройство остается основным узким местом

• Процессы продолжают блокироваться в ожидании IO

• Улучшение в корреляциях буферов с операциями записи

• Более выраженная отрицательная корреляция speed-IOPS указывает на дополнительные ограничения не в IO

Характерные паттерны показателей IO

Эксперимент-1:

• Стабильно высокие показатели: utilization=100%, IOPS≈4000, MB/s≈34

• Низкое время отклика на чтение/запись (2-4 мс)

• Постепенный рост длины очереди (aqu_sz: 6→14) и ожидания CPU (wa: 51→69)

• Количество процессов в uninterruptible sleep растет со временем

Эксперимент-2:

• Стабильно высокие показатели: utilization=100%, IOPS≈4000, MB/s≈33-35

• Низкое время отклика на чтение/запись (2-4 мс)

• Постепенный рост длины очереди (aqu_sz: 6→14) и ожидания CPU (wa: 51→70)

• Количество процессов в uninterruptible sleep растет со временем

Сравнение характерных паттернов для Эксперимента-1 и Эксперимента-2

• Оба эксперимента демонстрируют практически идентичные абсолютные показатели производительности IO

• В Эксперименте-2 наблюдается снижение корреляции между буферами и операциями записи

• В Эксперименте-2 усилилась отрицательная корреляция между операционной скоростью и IOPS

• Корреляция между ожиданием IO и загрузкой диска снизилась с 0.9526 до 0.8587

• Корреляция между кэшированием и объемом чтения увеличилась с 0.9545 до 0.9827

• Время отклика на операции чтения/записи осталось низким в обоих случаях

• Паттерн роста длины очереди и ожидания CPU аналогичен в обоих экспериментах

Итоговый вывод о влиянии уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность IO

Уменьшение параметров vm.dirty_ratio/vm.dirty_background_ratio не привело к существенному улучшению производительности подсистемы IO для данной OLTP-нагрузки.

Основные проблемы производительности сохранились в полном объеме: диск остается постоянно перегруженным (100% utilization), процессы блокируются в ожидании IO, сохраняется высокая очередь запросов. Хотя некоторые корреляционные зависимости изменились (улучшилась корреляция буферов с операциями записи, снизилась корреляция wa-util), это не повлияло на ключевые метрики производительности.

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

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

Послесловие

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

Уменьшение параметров грязной памяти — интуитивно понятный шаг для снижения IO-нагрузки. Но что, если он лишь меняет "симптомы", не затрагивая корень проблемы? Итоги нагрузочного тестирования бросают вызов упрощенным подходам к тюнингу.

В статье представлены результаты сравнительного анализа производительности СУБД PostgreSQL под OLAP-нагрузкой. Исследование фокусируется на оценке влияния ключевых параметров виртуальной памяти ядра Linux — vm.dirty_ratio и vm.dirty_background_ratio — на поведение системы, паттерны ожиданий и итоговую эффективность.

Задача

Проанализировать влияние уменьшения значения vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД при имитации типа нагрузки "OLAP" в ходе нагрузочного тестирования.

Параметры инфраструктуры

sysctl vm.dirty_expire_centisecs

sysctl vm.dirty_ratio

sysctl vm.dirty_background_ratio

sysctl vm.vfs_cache_pressure

cat /sys/block/vdd/queue/read_ahead_kb

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 30

vm.dirty_background_ratio = 10

vm.vfs_cache_pressure = 100

4096

Изменение параметров vm.dirty*

# sysctl -w vm.dirty_ratio=10

vm.dirty_ratio = 10

# sysctl -w vm.dirty_background_ratio=5

vm.dirty_background_ratio = 5

Корреляционный анализ производительности и ожиданий СУБД

Операционная скорость

Среднее снижение операционной скорости, при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 26.06%

Ожидания СУБД

Среднее увеличение ожиданий СУБД , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 10.45%

Сравнительный отчет по нагрузочному тестированию: BASELINE vs vm.dirty*

1. ОБЩАЯ ХАРАКТЕРИСТИКА СИСТЕМЫ В ЭКСПЕРИМЕНТАХ

• Оборудование идентично в обоих экспериментах:
  8 ядер CPU (Intel Xeon)
  8 ГБ RAM
  Раздельные дисковые подсистемы: data (100 ГБ), wal (50 ГБ), log (30 ГБ)

• Тип нагрузки: OLAP (аналитические запросы)
  Подтверждается высоким отношением прочитанных блоков к измененным (>150)
  Низкий процент попаданий в shared buffers (~58-59%)
  Доминирование операций чтения с диска

2. СРАВНИТЕЛЬНЫЕ ПАТТЕРНЫ ОЖИДАНИЙ И ПРОИЗВОДИТЕЛЬНОСТИ СУБД

• Эксперимент-1 (базовые настройки):
  Операционная скорость возрастала с углом наклона 40.51
  Общие ожидания возрастали с углом наклона 44.12
  Высокая корреляция между скоростью и ожиданиями (0.75)
  Основные типы ожиданий: IO (корреляция 0.78 с общими ожиданиями) и IPC (корреляция 0.99)
  80% ожиданий IO вызывались операциями DataFileRead

• Эксперимент-2 (уменьшенные vm.dirty_*):
  Скорость возрастала медленнее (угол 38.94)
  Ожидания возрастали медленнее (угол 42.39)
  Корреляция скорости и ожиданий снизилась до 0.65
  Ожидания IO стали отрицательно коррелировать с общими ожиданиями (-0.85)
  IPC-ожидания остались строго коррелированными с общими ожиданиями (1.0)
  Практически исчезли ожидания IO из Pareto-диаграммы

3. СРАВНИТЕЛЬНЫЕ ПАТТЕРНЫ ПОКАЗАТЕЛЕЙ VMSTAT/IOSTAT

• Эксперимент-1:
  Очень высокая корреляция IO-ожиданий СУБД с wa (I/O wait) в vmstat (0.8748)
  Высокая корреляция LWLock-ожиданий с us и sy (0.9277 и 0.8802)
  Умеренная корреляция IO с bi/bo (0.44 и 0.36)
  100% наблюдений с wa > 10%
  100% наблюдений со свободной RAM < 5%

• Эксперимент-2:
  Корреляция IO-ожиданий с wa стала отрицательной (-0.6128)
  Корреляция LWLock с us/sy осталась очень высокой (0.9609 и 0.9288)
  Корреляция IO с bi/bo стала отрицательной или околонулевой
  Сохранилось 100% наблюдений с wa > 10%
  Сохранилось 100% наблюдений со свободной RAM < 5%

4. ИТОГОВЫЙ ВЫВОД О ХАРАКТЕРНЫХ ПАТТЕРНАХ ПРОИЗВОДИТЕЛЬНОСТИ И ОЖИДАНИЙ СУБД И ПОКАЗАТЕЛЕЙ VMSTAT/IOSTAT ДЛЯ ЭКСПЕРИМЕНТОВ

• В обоих экспериментах система демонстрирует паттерны, характерные для OLAP-нагрузки:
  Система ограничена производительностью дисков (чтение и запись)
  Низкая эффективность кэширования (hit ratio ~58-59%)
  Высокое время ожидания ввода-вывода (wa > 10% в 100% наблюдений)
  Потребление почти всей доступной оперативной памяти

• Ключевое различие: в Эксперименте-1 система испытывала сильные IO-ожидания, которые были тесно связаны с общими ожиданиями, тогда как в Эксперименте-2 IO-ожидания перестали быть доминирующим фактором

• В обоих случаях наблюдаются очень высокие корреляции IPC-ожиданий (BufferIo) с общими ожиданиями

• Корреляция переключений контекста (cs) с прерываниями (in) осталась экстремально высокой в обоих экспериментах (~0.96)

5. ИТОГОВЫЙ ВЫВОД О ВЛИЯНИИ УМЕНЬШЕНИЯ ЗНАЧЕНИЯ VM.DIRTY_RATIO/VM.DIRTY_BACKGROUND_RATIO НА ПРОИЗВОДИТЕЛЬНОСТЬ СУБД И ПАТТЕРНЫ ПРОИЗВОДИТЕЛЬНОСТИ, ОЖИДАНИЙ И ИНФРАСТРУКТУРЫ

• Уменьшение параметров vm.dirty_ratio/vm.dirty_background_ratio привело к изменению паттернов ожиданий:
  IO-ожидания перестали коррелировать с общими ожиданиями (корреляция стала отрицательной)
  IPC-ожидания (буферные операции) стали практически единственным источником ожиданий

• Производительность в Эксперименте-2 росла медленнее (меньший угол наклона скорости)

• Система стала менее зависимой от дисковых операций ввода-вывода как источника ожиданий

• Паттерны использования ресурсов ОС изменились:
  Исчезла корреляция между IO-ожиданиями СУБД и метриками bi/bo в vmstat
  Сохранилась высокая нагрузка на CPU (корреляция LWLock с us/sy)

• Изменение параметров виртуальной памяти не устранило фундаментальные ограничения системы:
  Высокое время ожидания ввода-вывода (wa) сохранилось на прежнем уровне
  Проблема нехватки оперативной памяти для кэширования не была решена
  Система осталась ограниченной производительностью дисковой подсистемы.

Производительность подсистемы IO

IOPS (Производительность IO)

Среднее снижение IOPS , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 3.71%

MB/s (Пропуская способность IO)

Среднее снижение пропускной способности , при изменении параметров vm.dirty_ratio/vm.dirty_background_ratio составило 4.22%

Отчет по анализу производительности подсистемы IO для файловой системы /data

Общая характеристика системы

• Период анализа:
  Эксперимент-1 (baseline): 2026-01-20 12:01 — 2026-01-20 13:51
  Эксперимент-2 (настройки vm.dirty): 2026-01-21 09:59 — 2026-01-21 11:48

• Основное устройство хранения: vdd

• Тип нагрузки: Ярко выраженный OLAP-сценарий (аналитическая обработка данных). Подтверждается высоким соотношением операций чтения к записи и паттерном высокой корреляции пропускной способности (MB/s) с операционной скоростью.

Сравнительный отчет по производительности IO

Критические проблемы производительности (общие для обоих экспериментов):

• Устройство постоянно перегружено. Наблюдается 100% случаев, когда загрузка (utilization) превышает 50%, достигая значений 90-97%.

• Высокое время отклика диска. В 100% случаев задержки на чтение (r_await) и запись (w_await) превышают 5 мс (достигая 10-18 мс и 6-7 мс соответственно).

• Хроническая очередь запросов. Средняя длина очереди (aqu_sz) постоянно больше 1, что указывает на скопление невыполненных IO-запросов.

• Процессоры простаивают в ожидании IO. В 100% наблюдений время ожидания процессора на IO (cpu_wa) превышает 10%, достигая 16-32%.

• Крайне низкая эффективность кэширования. Shared buffers HIT RATIO составляет около 58-59%, что указывает на неэффективное использование оперативной памяти для снижения нагрузки на диск.

Анализ корреляций и паттернов нагрузки:

• Эксперимент-1 (baseline):
  Сильная положительная корреляция между ожиданием процессора (wa) и загрузкой диска (util) (0.8021) подтверждает, что процессоры idle из-за медленного диска.
  Очень высокая корреляция между операционной скоростью и пропускной способностью диска (MB/s) (0.9828) — классический признак того, что производительность ограничена пропускной способностью накопителя.
  Корреляция скорости с IOPS отрицательная (-0.1472), что типично для OLAP с большими последовательными чтениями/записями, а не множеством мелких операций.
  Высокие корреляции объема кэша/буферов с операциями чтения (r/s) указывают, что память неэффективно смягчает нагрузку на диск.

• Эксперимент-2 (настройки vm.dirty):
  Корреляция wa и util стала еще выше (0.9229), что усиливает вывод о процессорах, ожидающих диск.
  Корреляция скорости с MB/s осталась очень высокой (0.7574), но немного снизилась по сравнению с baseline.
  Корреляция скорости с IOPS стала слабо положительной (0.6100), что может указывать на небольшие изменения в паттерне запросов.
  Соотношение прочитанных блоков к измененным увеличилось с ~157 до ~202, что указывает на еще более выраженный перекос в сторону операций чтения.

Узкие места IO:

• Основное узкое место в обоих экспериментах: Пропускная способность (throughput) дискового устройства vdd. Система упирается в пределы скорости последовательного чтения/записи (MB/s).

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

Характерные паттерны показателей IO:

• Эксперимент-1 (baseline):
  Utilization: стабильно на уровне 90-95%.
  r_await: колеблется в диапазоне 9-14 мс.
  IOPS: относительно стабилен в районе ~3500-3800.
  MB/s: постепенно возрастает с ~100 до ~180 MB/s к концу периода.
  aqu_sz: высокая и изменчивая (31-47).

• Эксперимент-2 (настройки vm.dirty):
  Utilization: стабильно на уровне 97% в первой половине, затем постепенно снижается до 83%.
  r_await: стабильно высокий (16-18 мс) в первой половине, затем снижается до 12-14 мс.
  IOPS: более стабилен, в основном в диапазоне ~3380-3600.
  MB/s: начинается со ~114 MB/s, демонстрирует более плавный рост до ~184 MB/s.
  aqu_sz: стабильно высокий (54-56 в первой половине, затем снижается до 41-44).

Сравнение характерных паттернов для Эксперимента-1 и Эксперимента-2:

• Во втором эксперименте наблюдалась более стабильная, но изначально более высокая загрузка диска (utilization ~97% vs ~90-95%).

• Средняя длина очереди (aqu_sz) в начале второго эксперимента была значительно выше (54-56 vs 31-47), что указывает на накопление запросов.

• Пропускная способность (MB/s) во втором эксперименте начиналась с более высокого уровня и демонстрировала более плавную динамику роста.

• Время отклика на чтение (r_await) во втором эксперименте в первой половине было стабильно выше (17-18 мс vs 9-14 мс), но снизилось к концу теста.

• Показатель cpu_wa в обоих случаях оставался критически высоким (>16%), что подтверждает неизменность фундаментальной проблемы.

Итоговый вывод о влиянии уменьшения vm.dirty_ratio/vm.dirty_background_ratio на производительность IO

Уменьшение параметров vm.dirty_ratio и vm.dirty_background_ratio привело к изменению паттерна нагрузки, но не решило ключевых проблем производительности подсистемы IO. Наблюдаемые изменения (более стабильные и изначально более высокие показатели утилизации и длины очереди, более плавный рост пропускной способности) указывают на более агрессивную политику сброса "грязных" страниц памяти на диск. Это, однако, не снизило ни задержек дисковых операций, ни времени ожидания процессоров, ни общей перегруженности накопителя. Основное узкое место — ограниченная пропускная способность диска — осталось неизменным, что и определяет общую производительность системы в условиях данной OLAP-нагрузки.

Послесловие

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

Статья представляет собой глубокий сравнительный анализ паттернов производительности PostgreSQL 17 для двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP). Исследование проведено с помощью специализированного комплекса pg_expecto, предназначенного для статистического анализа и нагрузочного тестирования. Этот инструмент позволил не только имитировать сценарии, но и выявить тонкие корреляции между внутренними ожиданиями СУБД (DataFileRead, LWLock) и системными метриками (vmstat, iostat). В статье показано, как под нагрузкой ведут себя ключевые показатели: от hit ratio буферного кэша до времени отклика диска, и определены характерные «узкие места» для каждого типа задач.

ℹ️Это готовый кейс для использования в нагрузочных тестах.

Задача

Определить характерные паттерны производительности/ожиданий СУБД и показателей vmstat/iostat для типов нагрузки OLAP/OLTP в ходе нагрузочного тестирования.

Веса сценариев

scenario1 = 0.7

scenario2 = 0.2

scenario3 = 0.1

Тестовая среда, инструменты и конфигурация СУБД:

• СУБД: PostgreSQL 17

• Инструмент нагрузочного тестирования: pg_expecto

• Тестовая база данных: pgbench (10GB, простая структура)

• CPU = 8

• RAM = 8GB

Нагрузка на СУБД в ходе экспериментов

Операционная скорость

OLAP

OLTP

Корреляционный анализ производительности и ожиданий СУБД

Сравнительный отчет по нагрузочному тестированию: OLAP vs OLTP

1. Общая характеристика системы в экспериментах

Оборудование и конфигурация:

• CPU: 8 ядер (Intel Xeon)

• RAM: 8 ГБ

Дисковая подсистема:

• /data: 100 ГБ (данные)

• /wal: 50 ГБ (WAL)

• /log: 30 ГБ (логи)

• Файловая система: LVM

Настройки PostgreSQL:

• shared_buffers = 4 ГБ

• work_mem = 32 МБ

• max_connections = 1000

• autovacuum настроен агрессивно (naptime=1s)

Тип нагрузки:

• Эксперимент-1 (OLAP): Аналитические запросы, большие чтения, сканирования.

• Эксперимент-2 (OLTP): Транзакционные запросы, короткие операции, интенсивное чтение/запись.

2. Сравнительные паттерны ожиданий и производительности СУБД

Для OLAP (Эксперимент-1):

Основной тип ожиданий: IO (DataFileRead) — 99,75% от всех ожиданий типа IO.

Корреляция ожиданий IO с общими ожиданиями (WAITINGS): 0,78 (высокая).

Операционная скорость (SPEED):

• Рост сильно коррелирует с чтением с диска (корреляция 0,93).

⚠️Hit Ratio shared buffers крайне низкий: 57,72%.

Ключевые запросы:

• scenario1() вызывает 49,67% ожиданий IO.

• scenario2() и scenario3() также вносят значительный вклад.

Для OLTP (Эксперимент-2):

Основной тип ожиданий: IO (DataFileRead) — 100% от всех ожиданий типа IO.

Корреляция ожиданий IO с общими ожиданиями (WAITINGS): 1,0 (полная зависимость).

Операционная скорость (SPEED):

• Почти не растет (R²=0,10), но ожидания растут значительно (R²=0,90).

☑️Hit Ratio shared buffers приемлемый: 90,74%.

Ключевые запросы:

• scenario1() вызывает 79,62% ожиданий IO.

• scenario2() добавляет 12,96%.

3. Сравнительные паттерны показателей vmstat/iostat

Для OLAP:

Память (RAM):

• Свободной памяти < 5% в 100% наблюдений.

• Свопинг (swap in/out) присутствует⚠️, но в небольших объемах.

CPU:

• Высокая корреляция LWLock с user time (0,93) и system time (0,88).

• Очередь процессов (run queue) редко превышает число ядерℹ️.

Диск (IO):

• Высокое время ожидания IO (wa > 10% в 100% наблюдений).

• Корреляция IO с процессами в состоянии D (b) слабая (0,31).

Для OLTP:

Память (RAM):

• Свободной памяти < 5% в 100% наблюдений.

• Свопинг отсутствует☑️.

CPU:

• Высокая корреляция переключений контекста (cs) с прерываниями (in) (0,96) и user time (0,73).

• Очередь процессов не превышает число ядер☑️.

Диск (IO):

• Очень высокое время ожидания IO (wa > 10% в 100% наблюдений).

• Сильная корреляция IO с процессами в состоянии D (b) (0,98).

4. Итоговый вывод о характерных паттернах производительности

Для нагрузки типа OLAP:

Паттерн производительности: Система упирается в дисковый ввод-вывод.

Ключевые индикаторы:

• ⚠️Низкий hit ratio буферного кэша (57,72%).

• Высокая корреляция скорости операций с чтением с диска.

• Большой объем чтений (DataFileRead) и записей (shared_blks_write).

Проблемные точки:

• ⚠️Нехватка оперативной памяти.

• Диск не справляется с объемом чтений.

• ⚠️Высокая нагрузка на CPU из-за LWLock.

Для нагрузки типа OLTP:

Паттерн производительности: Система упирается в дисковые задержки и блокировки процессов.

Ключевые индикаторы:

• Почти полная корреляция ожиданий IO с общими ожиданиями (1,0).

• Высокое время ожидания IO (wa до 69%).

• Растущее количество процессов в состоянии D (b).

Проблемные точки:

• Дисковые операции становятся узким местом.

• Процессы блокируются из-за ожидания IO.

• ⚠️Высокая нагрузка на CPU из-за переключений контекста.

Общие выводы:

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

• Память является ограничивающим ресурсом в обоих случаях.

• Настройки PostgreSQL (shared_buffers, work_mem) требуют оптимизации под конкретный тип нагрузки.ℹ️

Рекомендации:

• Для OLAP: Увеличить shared_buffers, оптимизировать запросы, рассмотреть увеличение RAM.

• Для OLTP: Настроить параметры дискового ввода-вывода, оптимизировать autovacuum, снизить contention.

Отчет подготовлен на основе анализа конфигурации системы и метрик производительности для двух типов нагрузки: OLAP (аналитическая) и OLTP (транзакционная).

Производительность подсистемы IO

Отчет по анализу производительности подсистемы IO для файловой системы /data

Общая характеристика системы

Период анализа:

• Эксперимент OLAP: 2026-01-20 12:01 — 2026-01-20 13:51

• Эксперимент OLTP: 2026-01-20 15:27 — 2026-01-20 17:13

Основные устройства хранения:

• Устройство vdd (100 ГБ) через LVM-том vg_data-LG_data, смонтированное в /data

• Дополнительные устройства: vdc для WAL (/wal), vdb для логов (/log)

Тип нагрузки:

• Четко разделенные сценарии: OLAP (аналитический) и OLTP (транзакционный)

Отчет по типу нагрузки OLAP

Критические проблемы производительности по файловой системе /data

• Очень высокая корреляция (0.8021) между ожиданием процессором IO (wa) и загрузкой диска (util), что указывает на то, что процессы не могут работать из-за ожидания диска

• 100% наблюдений показывают загрузку устройства выше 50%

• 100% наблюдений имеют отклик на чтение и запись свыше 5 мс⚠️

• 100% наблюдений имеют глубину очереди запросов свыше 1⚠️

• Критически низкий Shared buffers HIT RATIO (57.72%)⚠️

Анализ корреляций и паттернов нагрузки по файловой системе /data

• Очень высокая корреляция (0.9095) между объемом памяти для буферов и количеством операций чтения с диска

• Очень высокая корреляция (0.8283) между объемом памяти для кэширования и количеством операций чтения с диска

• Очень высокая корреляция (0.9303) операционной скорости с прочитанными блоками

• Очень высокая корреляция (0.9905) операционной скорости с записанными блоками

• Высокая корреляция (0.9829) между shared_blks_hit и shared_blks_read

Узкие места IO по файловой системе /data

• Производительность ограничена пропускной способностью диска (корреляция скорости с MB/s = 0.9828)

• Высокая задержка операций чтения (r_await от 9 до 14 мс)⚠️

• Высокая средняя длина очереди запросов (aqu_sz от 31 до 47)⚠️

Характерные паттерны показателей IO для OLAP

• Загрузка диска (util): от 83% до 95%

• Задержка чтения (r_await): от 9 до 14 мс

• Задержка записи (w_await): от 6 до 7 мс

• IOPS: от 3,366 до 3,825 операций/сек

• Пропускная способность (MB/s): от 95 до 180 МБ/сек

• Процент времени ожидания CPU (wa): от 16% до 31%

• Отношение прочитанных блоков к измененным: 156.73:1

Отчет по типу нагрузки OLTP

Критические проблемы производительности по файловой системе /data

• Очень высокая корреляция (0.9526) между ожиданием процессором IO (wa) и загрузкой диска (util)

• 100% наблюдений показывают загрузку устройства на уровне 100%

• 100% наблюдений имеют глубину очереди запросов свыше 1

• Возрастающее количество процессов в состоянии uninterruptible sleep (коэффициент детерминации R² = 0.85)

Анализ корреляций и паттернов нагрузки по файловой системе /data

• Очень высокая корреляция (0.8728) между объемом памяти для буферов и количеством операций записи на диск

• Очень высокая корреляция (0.8637) между объемом памяти для буферов и объемом записи на диск

• Очень высокая корреляция (0.9545) между объемом памяти для кэширования и объемом чтения с диска

• Высокая корреляция (0.8937) операционной скорости с прочитанными блоками

• Низкая корреляция (0.0904) между shared_blks_hit и shared_blks_read

Узкие места IO по файловой системе /data

• Производительность не ограничена IO (отрицательная корреляция скорости с IOPS и MB/s)

• Проблемы могут быть связаны с CPU, блокировками или памятью

• Высокий процент времени ожидания CPU (wa) при относительно низких задержках диска

Характерные паттерны показателей IO для OLTP

• Загрузка диска (util): постоянная 100%

• Низкая задержка чтения (r_await): от 2 до 4 мс

• Низкая задержка записи (w_await): постоянная 2 мс

• IOPS: от 3,961 до 4,205 операций/сек

• Пропускная способность (MB/s): от 33 до 35 МБ/сек

• Процент времени ожидания CPU (wa): от 51% до 69%

• Отношение прочитанных блоков к измененным: 33.92:1

• Shared buffers HIT RATIO: 90.74%

Сравнение характерных паттернов для типов нагрузки OLAP и OLTP

Различия в загрузке диска:

• OLAP: загрузка варьируется от 83% до 95%

• OLTP: постоянная загрузка на уровне 100%

Различия в задержках операций:

• OLAP: высокие задержки чтения (9-14 мс), умеренные задержки записи (6-7 мс)

• OLTP: низкие задержки чтения (2-4 мс), очень низкие задержки записи (2 мс)

Различия в пропускной способности:

• OLAP: высокая пропускная способность (95-180 МБ/сек)

• OLTP: низкая пропускная способность (33-35 МБ/сек)

Различия в характере операций:

• OLAP: преобладание операций чтения (соотношение read/write = 156.73:1)

• OLTP: более сбалансированное соотношение операций (соотношение read/write = 33.92:1)

Различия в эффективности кэширования:

• OLAP: низкий hit ratio (57.72%), кэширование связано с большим чтением с диска

• OLTP: высокий hit ratio (90.74%), кэширование практически не влияет на дисковую нагрузку

Итоговый вывод о влиянии типа нагрузки на производительность IO

Тип нагрузки существенно влияет на характер и производительность операций ввода-вывода:

Паттерны доступа к диску:

1. OLAP демонстрирует последовательный доступ с высокой пропускной способностью

2. OLTP показывает случайный доступ с низкой пропускной способностью, но высокой частотой операций

Узкие места производительности:

1. Для OLAP основным ограничением является пропускная способность диска

2. Для OLTP узкие места находятся не в подсистеме IO, а вероятно в CPU, блокировках или других ресурсах

Эффективность использования памяти:

1. OLAP неэффективно использует память для кэширования, что приводит к высокой дисковой нагрузке

2. OLTP эффективно использует кэширование, но это не устраняет проблему высокой загрузки CPU

Характер нагрузки на диск:

1. OLAP создает нагрузку на диск с высокой пропускной способностью и высокими задержками

2. OLTP создает интенсивную нагрузку с низкими задержками, но невысокой пропускной способностью

Влияние на систему:

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

2. Различные паттерны нагрузки требуют разных подходов к мониторингу и анализу производительности

Послесловие

Проведенный анализ наглядно демонстрирует, что даже на идентичном оборудовании OLAP и OLTP нагрузки создают принципиально разные паттерны нагрузки на диск, память и CPU. Понимание этих различий — первый шаг к целевой оптимизации конфигурации и архитектуры.

Продолжение статьи :

PG_EXPECTO 5.1: Влияние vm.swappiness=1 на производительность PostgreSQL

Стандартные рекомендации по влиянию параметра vm.swappiness на производительность СУБД PostgreSQL

Для OLAP-нагрузок в PostgreSQL рекомендуется установить vm.swappiness=1, чтобы минимизировать обращения к медленному диску и обеспечить стабильную производительность при обработке больших данных. Это заставит ядро использовать своп только в крайнем случае, сохраняя рабочие данные в оперативной памяти.

1. Текущая конфигурация памяти:

• RAM: 8 GB

• shared_buffers: 4 GB (50% от RAM - правильно настроено)

• work_mem: 32 MB (адекватно для 22 сессий)

• Остаётся для ОС: ~3.5-4 GB (учитывая кэш файловой системы)

2. Рекомендация: swappiness = 1 (лучший выбор)

Почему именно 1:

• PostgreSQL интенсивно использует файловый кэш - для SELECT-нагрузки это критично

• shared_buffers уже содержит "горячие" данные в управляемой памяти

• Низкое значение предотвращает вытеснение кэша страниц ОС в своп

• При нехватке памяти PostgreSQL сам управляет своими буферами через shared_buffers

Экспериментальная проверка влияния vm.swappiness=1 на производительность СУБД

Операционная скорость

Среднее уменьшение операционной скорости в Эксперименте-2 (vm.swappiness = 1) составило 14.37%⚠️

Анализ причин снижения производительности СУБД PostgreSQL после применения vm.swappiness = 1

Рекомендация vm.swappiness=1 для PostgreSQL, которую часто дают нейросети и многие руководства, основана на общей логике: «меньше свопа — меньше обращений к диску — выше производительность». Однако эксперимент, описанный в статье «PG_EXPECTO 5.1: Влияние vm.swappiness=1 на производительность PostgreSQL», показывает, что в конкретных условиях эта настройка не дала ожидаемого эффекта. Вот ключевые причины, почему это произошло.

🔍 Суть эксперимента

• Конфигурация: PostgreSQL 17, 8 ядер CPU, 8 ГБ RAM, shared_buffers=4 ГБ, нагрузка OLAP (аналитические запросы с большим объёмом чтения).

• Сравнение: Производительность при vm.swappiness=10 и vm.swappiness=1.

• Ожидание: Снижение своппинга должно уменьшить дисковый ввод-вывод и ускорить работу.

📊 Результаты

Диск - «узкое место»

Нагрузка на диск (/data) достигала 100% в обоих экспериментах.
Высокая очередь запросов (aqu_sz) и время ожидания CPU для IO (cpu_wa >50%) указывали на то, что производительность упиралась в диск, а не в память.

Система избегала своппинга

Даже при swappiness=10 ядро Linux предпочитало вытеснять файловый кэш, а не отправлять данные в своп. Поэтому изменение параметра почти не повлияло на поведение подсистемы памяти.

Минимальное влияние на метрики vmstat

Разница между swappiness=10 и swappiness=1 оказалась статистически незначимой: не было существенных изменений в IOPS или пропускной способности.
Небольшие улучшения (например, снижение w_await и глубины очереди) не решили основную проблему — перегруженность диска.

Общий результат

Проведенные эксперименты не подтвердили ожидаемого положительного влияния снижения параметра vm.swappiness на производительность PostgreSQL при интенсивной нагрузке с дефицитом оперативной памяти. Ключевым узким местом в обоих экспериментах стала производительность дисковой подсистемы.

🤔 Почему рекомендация нейросетей не подтвердилась?

Обобщённый характер рекомендаций

Нейросети (и многие руководства) опираются на общие принципы: «для OLAP-нагрузок снизьте swappiness, чтобы удержать данные в RAM». Однако они не учитывают конкретную конфигурацию и узкие места системы.

Условия эксперимента

Дисковая подсистема была перегружена (100% utilization), поэтому даже полное отключение свопа не могло улучшить общую производительность.
Нехватка RAM (8 ГБ при shared_buffers=4 ГБ) приводила к вытеснению файлового кэша, а не к активному своппингу. Из-за этого изменение swappiness практически не меняло картину.

Контекстная зависимость

Эффект от vm.swappiness проявляется только когда система активно использует своп. Если же система избегает своппинга (как в эксперименте) или узким местом является диск, то настройка не даёт заметного выигрыша.

💡 Практические выводы

Не доверяйте слепо общим рекомендациям (в том числе от нейросетей)

Проверяйте их в своей среде.

Диагностируйте узкие места перед тонкой настройкой

Мониторьте iostat, vmstat, pg_stat_activity.
Смотрите на %util, await, cpu_wa, aqu_sz.

Если диск перегружен, сначала оптимизируйте его

• Используйте более быстрые диски (SSD/NVMe).

• Необходима настройка effective_io_concurrency, random_page_cost.

• Рассмотрите увеличение RAM для уменьшения нагрузки на диск.

vm.swappiness стоит снижать только когда

• Наблюдается активный своппинг (si, so в vmstat).

• Дисковая подсистема не является узким местом.

• PostgreSQL работает с большим объёмом данных, которые должны оставаться в RAM.

Краткий сравнительный анализ производительности и ожиданий СУБД

Операционная скорость (SPEED)

Наклон линии регрессии скорости отрицательный в обоих случаях, но в Эксперименте-2 он круче (-26.99 против -23.65), что указывает на более быстрое снижение производительности.

Ожидания СУБД (WAITINGS)

Общий объем ожиданий и их рост во времени практически идентичны в обоих экспериментах (угол наклона ~43.6).
В обоих случаях ожидания почти полностью (коэффициент корреляции ~1.0) состоят из ожиданий ввода-вывода (IO).
Ключевое отличие: в Эксперименте-2 появилась умеренная корреляция ожиданий с IPC (0.86) и LWLock (0.86), которые в первом эксперименте были незначимы.

Типы ожиданий (Wait Events):

Основное событие ожидания в обоих случаях — DataFileRead (более 90% всех ожиданий типа IO).
В Эксперименте-2 дополнительно зафиксированы ожидания типов IPC (BufferIo) и LWLock (XidGen, BufferContent), что отсутствовало в первом эксперименте.

Подробный сравнительный анализ метрик vmstat и выводы по метрикам

procs_r (процессы в run queue)

Одинаково низкие значения (1-3) в обоих экспериментах. Очередь на выполнение не является проблемой.

procs_b (процессы в uninterruptible sleep)

Явная проблема в обоих случаях. Количество процессов, заблокированных в ожидании IO, стабильно растет на протяжении всего теста.
В Эксперименте-1 значение выросло с 5 до 16.
В Эксперименте-2 значение выросло с 5 до 14.
Более 40% наблюдений в обоих тестах — количество заблокированных процессов превышает число ядер CPU (8), что подтверждает серьезные проблемы с подсистемой IO.

memory_swpd (используемый объем свопа)

Эксперимент-1: Незначительный рост с ~220 до ~224 МБ.
Эксперимент-2: Заметный рост с ~205 до ~217 МБ. Хотя объем мал, тенденция к увеличению при swappiness=1 присутствует.

swap_si / swap_so (свопин/аут)

В обоих экспериментах равен 0. Активный свопинг не наблюдался.

memory_free (свободная RAM)

Критически низкий показатель в обоих экспериментах (~130 МБ из 7.5 ГБ, что составляет менее 2%).
100% наблюдений — свободной памяти менее 5%. Система работает на пределе доступной оперативной памяти.

memory_buff / memory_cache (буферы и кеш)

Стабильно высокие значения (кеш ~7 ГБ) в обоих тестах. ОС активно использует свободную память для кеширования дисковых операций, что является нормальным поведением.

io_bi / io_bo (блоки ввода/вывода)

Чрезвычайно высокие значения в обоих экспериментах (bi: с ~26k до ~32k; bo: с ~17k до ~20k).
Наблюдается очень сильная корреляция (>0.87) этих показателей с ожиданиями IO в СУБД. Это подтверждает, что СУБД является основным источником нагрузки на дисковую подсистему.

system_in / system_cs (прерывания / переключения контекста)

Значения стабильны и сопоставимы в обоих тестах. Существенных аномалий не выявлено.

cpu_us / cpu_sy / cpu_id / cpu_wa (распределение времени CPU)

• cpu_wa (время ожидания IO): Основная проблема. В обоих экспериментах занимает 50-70% времени CPU, что указывает на то, что процессор простаивает в ожидании операций дискового ввода-вывода.

• cpu_id (время простоя): Снижается с ~33% в начале до ~10-13% в конце тестов, так как процессор все больше времени ждет IO.

• cpu_us / cpu_sy (пользовательское/системное время): Остаются стабильно низкими (11-12% / 4-5%), что означает отсутствие нагрузки на вычислительные ресурсы со стороны приложения или ядра ОС. CPU не является узким местом.

Ключевые отличия метрик vmstat, влияющих на итоговую производительность СУБД

Динамика memory_swpd

При vm.swappiness=1 наблюдается более выраженный рост использования области свопа (с 205 до 217 МБ), в то время как при значении 10 рост был минимальным (с 220 до 224 МБ). Это указывает на то, что даже при низком значении параметра система под давлением нехватки памяти была вынуждена начать использовать своп.

Уровень procs_b

В конце теста при swappiness=10 было зафиксировано 16 заблокированных процессов, а при swappiness=1 — 14. Хотя разница невелика, в сочетании с другими метриками это указывает на схожую, но несколько менее выраженную пиковую нагрузку на IO во втором эксперименте.

Анализ причин снижения производительности при vm.swappiness=1

Основная (общая) причина

В обоих экспериментах основная причина снижения производительности — критическая нехватка оперативной памяти для рабочего набора данных СУБД. Это приводит к:
Чрезмерной нагрузке на дисковую подсистему (очень высокие io_bi/io_bo, cpu_wa >50%).
Росту числа процессов, заблокированных на операциях ввода-вывода (procs_b).
Прямой зависимости скорости работы СУБД от скорости чтения с диска (корреляция speed и shared_blks_read >0.97).

Специфическое влияние vm.swappiness=1

Установка параметра в 1 должна минимизировать использование свопа. Однако при тотальной нехватке памяти система все равно была вынуждена начать использовать swpd, хотя и менее активно, чем при значении 10.

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

Итог

При vm.swappiness=1 на фоне той же фундаментальной проблемы (нехватка RAM → лавина IO) дополнительно возникла внутренняя contention (конкуренция) в СУБД из-за борьбы за scarce (дефицитную) оперативную память. Это привело к более быстрому и глубокому падению операционной скорости (SPEED) по сравнению с Экспериментом-1, где система могла немного "разгрузить" RAM в своп, потенциально смягчая пиковое давление на shared buffers и внутренние структуры PostgreSQL.

⚖️ Почему swappiness=10 работал лучше

Более сбалансированный подход

При swappiness=10 система могла немного своппингуть неактивные фоновые процессы
Это сохраняло больше файлового кэша для активных операций PostgreSQL

Оптимизация под конкретную нагрузку

OLAP-запросы (70% SELECT) требуют много последовательных чтений
Файловый кэш ОС критически важен для повторных чтений одних и тех же данных
Сохранение этого кэша дало больше преимуществ, чем экономия на своппинге

📈 Основной итог экспериментов:

Нет универсальных настроек

То, что работает для OLTP, может вредить OLAP

Важен контекст bottlenecks:

Если узкое место - диск (как в эксперименте), сохраняйте кэш любой ценой
Если узкое место - память, можно снижать swappiness

Мониторинг обязателен

Без метрик vmstat и iostat нельзя понять реальный эффект

Послесловие

Главный вывод этого исследования прост: не существует универсальных настроек. Производительность PostgreSQL зависит от конкретной конфигурации, нагрузки и узких мест системы. Прежде чем применять рекомендации, проведите тесты в своей среде и опирайтесь на метрики, а не на советы из чатов.

Настоящее исследование посвящено экспериментальной проверке общепринятой рекомендации по снижению параметра vm.swappiness для серверов PostgreSQL . В ходе нагрузочного тестирования на синтетической рабочей нагрузке, имитирующей аналитические запросы, было оценено влияние значений vm.swappiness = 10 и vm.swappiness = 1 на производительность СУБД и инфраструктуры. Результаты выявили неожиданные закономерности, ставящие под сомнение универсальность данной рекомендации.

В статье представлены результаты нагрузочного тестирования PostgreSQL на синтетической рабочей нагрузке, имитирующей аналитические запросы (OLAP). Цель исследования: определить - как снижение параметра vm.swappiness влияет на взаимодействие СУБД с подсистемой ввода-вывода Linux.

Теоретическая часть

🎯 Влияние vm.swappiness на OLAP в PostgreSQL

Высокое значение (например, 60 по умолчанию):

• Эффект: Ядро активно выгружает данные в своп, даже если физическая память не исчерпана.

• Влияние на OLAP: Это может привести к "трешингу" (thrashing) — постоянному обмену данными между RAM и диском. Для OLAP-запросов, которые сканируют огромные наборы данных, это означает катастрофическое падение производительности, так как система тратит время на ввод-вывод, а не на обработку.

Низкое значение (например, 1-10):

• Эффект: Ядро свопирует данные, только когда свободной оперативной памяти практически не осталось. Кэш PostgreSQL (например, shared_buffers) и данные для больших запросов с большей вероятностью останутся в быстрой RAM.

• Влияние на OLAP: Это обеспечивает стабильность для длительных аналитических операций, минимизируя риск внезапных задержек из-за подкачки с диска. Однако слишком низкое значение (0) может привести к неожиданному завершению процесса (OOM Kill) при резком росте нагрузки.

⚙️ Рекомендации по настройке для OLAP

Для серверов PostgreSQL, ориентированных на OLAP-нагрузку, общепринятая рекомендация — снизить значение vm.swappiness.

• Базовое значение: Установите vm.swappiness=1 для минимального использования свопа, но не полного его отключения.

• Альтернатива: В некоторых продакшен-сценариях, особенно на системах с большим объемом RAM, используют значение vm.swappiness=10 как баланс между стабильностью и гибкостью.

• Важное предупреждение: Значение 0 использовать не рекомендуется, так как это может дестабилизировать систему и спровоцировать агрессивное действие OOM Killer (механизма, который завершает процессы при нехватке памяти).

📝 Как применить настройку

Настройка производится через файл /etc/sysctl.conf (для постоянного изменения) или через интерфейс sysctl.

1. Проверьте текущее значение: cat /proc/sys/vm/swappiness

2. Измените значение (временно, до перезагрузки): sudo sysctl -w vm.swappiness=1

3. Сделайте изменение постоянным. Добавьте или измените строку в файле /etc/sysctl.conf vm.swappiness=1

4. После сохранения файла примените изменения: sudo sysctl -p /etc/sysctl.conf

🔍 Дополнительные соображения для OLAP

Настройка vm.swappiness — лишь одна часть оптимизации памяти для OLAP. Не менее важны:

• Достаточный объем RAM: Ключевой фактор для OLAP. Данные должны помещаться в оперативную память для максимальной скорости.

• Параметры PostgreSQL: Увеличьте shared_buffers (до 25-40% от RAM) для кэширования данных и work_mem для сложных сортировок и агрегаций.

• Мониторинг: Следите за метриками swap in/out (например, через vmstat 1) и кэш-попаданий в PostgreSQL, чтобы убедиться в эффективности настроек.

💎 Итог

Для OLAP-нагрузок в PostgreSQL рекомендуется установить vm.swappiness=1, чтобы минимизировать обращения к медленному диску и обеспечить стабильную производительность при обработке больших данных. Это заставит ядро использовать своп только в крайнем случае, сохраняя рабочие данные в оперативной памяти.

Практическая часть: Экспериментальная проверка влияния vm.swappiness=1

Важное изменение в версии 5.1⚠️

Изменены тестовые сценарии scenario-2 и scenario-3.

Веса тестовых сценариев и параметры нагрузочного тестирования

# Веса сценариев по умолчанию

scenario1 = 0.7

scenario2 = 0.2

scenario3 = 0.1

Измененные параметры операционной системы ⚠️

1️⃣Общие параметры производительности

vm.dirty_ratio = 10

vm.dirty_background_ratio = 5

2️⃣Параметры IO-планировщика

[mq-deadline] kyber bfq none

3️⃣Настройки кэширования и буферизации

vm.vfs_cache_pressure = 50

4️⃣Оптимизация параметров файловой системы

/dev/mapper/vg_data-LG_data on /data type ext4 (rw,noatime,nodiratime)

5️⃣Изменение размера буферов для операций с блочными устройствами

read_ahead_kb = 256

Нагрузка на СУБД в ходе экспериментов

Изменение vm.swappiness

Текущее значение

# cat /proc/sys/vm/swappiness

10

Изменение значения

# sysctl -w vm.swappiness=1

vm.swappiness = 1

# vi /etc/sysctl.conf

vm.swappiness = 1

# sysctl -p /etc/sysctl.conf

vm.swappiness = 1

Контроль изменения

# cat /proc/sys/vm/swappiness

1

Эксперимент-1 ( vm.swappiness = 10 )

Эксперимент-2 (vm.swappiness = 1)

Корреляционный анализ производительности и ожиданий СУБД

Операционная скорость

Среднее уменьшение операционной скорости в Эксперименте-2 (vm.swappiness = 1) составило 14.37%

Ожидания СУБД

Среднее увеличение ожиданий в Эксперименте-2 (vm.swappiness = 1) составило 1.03%

Производительность подсистемы IO

Важно - главный предварительный итог

Изменение параметра vm.swappiness = 1 практически не оказывает влияния на метрики производительности подсистемы IO.

IOPS (Производительность IO)

Среднее уменьшение производительности IO в Эксперименте-2 (vm.swappiness = 1) составило 1.96%

MB/s (Пропускная способность IO)

Среднее уменьшение пропускной способности IO в Эксперименте-2 (vm.swappiness = 1) составило 7.16%

Сравнительный анализ производительности и ожиданий СУБД и метрик vmstat

Сравнительный отчет по результатам экспериментов с vm.swappiness

Цель анализа: Оценка влияния параметра vm.swappiness на производительность СУБД PostgreSQL и инфраструктуры при заданной нагрузке.

Контекст:

• Эксперимент 1: vm.swappiness = 10

• Эксперимент 2: vm.swappiness = 1

• Характер нагрузки: Интенсивное чтение данных (OLAP-сценарий). Преобладают операции DataFileRead.

• Конфигурация СУБД: Направлена на агрессивную автоочистку (autovacuum), высокий effective_io_concurrency, раздельные диски для данных и WAL.

• Инфраструктура: 8 CPU, ~7.5 GB RAM, дисковая подсистема LVM.

Сравнение ключевых метрик производительности СУБД

Операционная скорость (SPEED):

• Эксперимент 1: Начальная скорость выше (~611 850). Наблюдается выраженный отрицательный тренд (угол наклона -23.65). Скорость снижается на ~26% к концу теста.

• Эксперимент 2: Начальная скорость ниже (~500 504). Отрицательный тренд также присутствует (угол наклона -26.99), но абсолютное падение скорости меньше (~7%).

• Вывод: В условиях эксперимента снижение swappiness не привело к улучшению максимальной пропускной способности, однако общее относительное падение производительности под нагрузкой было менее выраженным.

Ожидания СУБД (WAITINGS):

• Оба эксперимента демонстрируют:
  Сильный и стабильный рост ожиданий во времени (R² ~0.91, угол наклона ~43.6).
  Практически полную корреляцию общих ожиданий с ожиданиями типа IO (WAITINGS - IO = 1.000).
  80% и более всех ожиданий приходятся на операцию DataFileRead.

• Ключевое различие:
  Эксперимент 1: Ожидания коррелируют с IPC (межпроцессное взаимодействие) и LOCK отрицательно или слабо.
  Эксперимент 2: Появилась заметная положительная корреляция ожиданий с IPC (0.86) и LWLOCK (0.86), что указывает на возросшую конкуренцию за легковесные блокировки и буферы в памяти.

Сравнение метрик инфраструктуры (vmstat) и их корреляция с СУБД

Загрузка CPU и очередь процессов:

• Оба эксперимента:
  Нагрузка на CPU (us + sy) не является проблемой (низкие значения, нет превышения 80%).
  Очередь исполняемых процессов (procs_r) не превышает количество ядер CPU.
  Высокий процент времени ожидания ввода-вывода (cpu_wa): 50-71% в Эксперименте 1, 51-69% в Эксперименте 2.

• Различия: Существенных различий в метриках CPU между экспериментами не выявлено.

Дисковый ввод-вывод (IO):

• Оба эксперимента показывают идентичные проблемы:
  ALARM: Очень высокая корреляция ожиданий СУБД типа IO с cpu_wa (~0.94) и procs_b (~0.98). Это указывает, что процессы СУБД массово переходят в состояние непрерываемого сна (D) из-за ожидания ответа от диска.
  ALARM: Количество процессов в состоянии D (procs_b) стабильно растет и в пике превышает количество ядер CPU в 2 раза.
  ALARM: Соотношение читаемых блоков к записываемым высокое (>2.7), что подтверждает read-intensive (OLAP) характер нагрузки.
  ALARM: Прямая сильная корреляция операционной скорости СУБД с количеством прочитанных с диска блоков (~0.97). Производительность напрямую упирается в скорость чтения с диска.

• Вывод: Параметр swappiness не оказал влияния на профиль и тяжесть проблем с дисковым IO. Система упирается в пределы производительности дисковой подсистемы.

Память (RAM):

• Общая картина в обоих экспериментах:
  ALARM: Свободная оперативная память (memory_free) практически отсутствует (<5% на протяжении >50% наблюдений).
  OK: Своппинг (swap_si, swap_so) не использовался, несмотря на нехватку свободной RAM.
  Значительный объем памяти используется для кэша файловой системы (memory_cache >7 GB).

• Ключевой вывод: Даже при swappiness=10 система не прибегала к своппингу. Нехватка свободной RAM, по всей видимости, компенсировалась активным вытеснением файлового кэша, что усугубляло проблему с дисковым IO, заставляя чаще читать данные с диска.

Итоговый вывод о влиянии vm.swappiness

Для данной конкретной конфигурации (8 CPU, 7.5 GB RAM) и предоставленного характера нагрузки (интенсивное чтение, вызывающее дефицит свободной оперативной памяти):

1. Отсутствие влияния на своппинг: Изменение параметра vm.swappiness с 10 на 1 не привело к качественному изменению поведения системы. В обоих случаях система предпочла не использовать раздел подкачки, даже в условиях хронической нехватки свободной оперативной памяти.

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

3. Изменение профиля конкуренции: Снижение swappiness до 1 привело к появлению статистически значимой корреляции ожиданий СУБД с IPC и LWLOCK. Это косвенно свидетельствует о том, что при более жестком ограничении на использование свопа процессы СУБД активнее конкурировали за структуры данных в оперативной памяти (буферы, легковесные блокировки), однако это не стало новым узким местом по сравнению с дисковым IO.

Общий вывод:

В рамках проведенных экспериментов с интенсивной нагрузкой, вызывающей дефицит оперативной памяти, параметр vm.swappiness не оказал решающего влияния на общую производительность системы и СУБД PostgreSQL. Основным лимитирующим фактором в обоих случаях была производительность дисковой подсистемы. Система в обоих конфигурациях избегала своппинга, выбирая стратегию вытеснения файлового кэша, что лишь усиливало нагрузку на диски. Изменения в поведении СУБД были минимальны и не повлияли на ключевую проблему производительности.

Анализ производительности IO для файловой системы /data

Сравнительный отчет по производительности подсистемы IO для файловой системы /data

Общая характеристика системы

• Аппаратная конфигурация:
  CPU: 8 ядер (x86_64)
  RAM: 7.5 GB
  Диск для /data: vdd → vg_data-LG_data (99 GB LVM)

Критические проблемы производительности по файловой системе /data

• Загрузка диска (utilization): 100% в 100% наблюдений в обоих экспериментах

• Очередь запросов (aqu_sz): постоянно превышает 1 (100% наблюдений)

• Ожидание CPU для IO (cpu_wa): стабильно >50% (в 100% наблюдений)

• Процессы в состоянии ожидания IO (proc_b): регулярно превышают количество ядер CPU (25-50% наблюдений)

• Соотношение чтения/записи: ~2.9:1 (OLAP-сценарий)

Анализ корреляций и паттернов нагрузки по файловой системе /data

• Высокая корреляция cpu_wa и util: 0.94 (Эксп.1) и 0.87 (Эксп.2) — процессы ждут диск

• Отрицательная корреляция cache с операциями чтения/записи: эффективное использование кэша

• Высокая корреляция скорости операций с shared_blks_read: 0.97 — производительность напрямую зависит от чтения с диска

• Слабые/отрицательные корреляции с IOPS и MB/s: производительность не ограничена пропускной способностью или IOPS

Диагностика узких мест IO по файловой системе /data

Сравнение метрик между экспериментами:

• r_await(ms):
  Эксп.1: 1-5 мс (MIN: 1.47, MAX: 5.12)
  Эксп.2: 1-6 мс (MIN: 1.47, MAX: 5.68)
  Изменение: незначительное увеличение максимума во втором эксперименте

• w_await(ms):
  Эксп.1: 1-15 мс (MIN: 1.63, MAX: 14.91)
  Эксп.2: 1-5 мс (MIN: 1.63, MAX: 4.49)
  Изменение: значительное улучшение во втором эксперименте

• aqu_sz (глубина очереди):
  Эксп.1: 6-38 (MIN: 6.07, MAX: 38.36)
  Эксп.2: 6-30 (MIN: 6.07, MAX: 29.88)
  Изменение: снижение максимальной глубины очереди

• proc_b (процессы в uninterruptible sleep):
  Оба эксперимента: регулярно превышают количество ядер CPU
  Эксп.1: 42.99% наблюдений с превышением
  Эксп.2: 42.73% наблюдений с превышением
  Изменение: минимальное улучшение

• cpu_wa(%) (время ожидания CPU для IO):
  Эксп.1: 50-71%
  Эксп.2: 51-69%
  Изменение: незначительное снижение диапазона

• Корреляция speed с IOPS:
  Эксп.1: -0.7012 (отрицательная)
  Эксп.2: -0.7442 (отрицательная)
  Изменение: усиление отрицательной корреляции

• Корреляция speed с пропускной способностью (MB/s):
  Эксп.1: -0.8707 (отрицательная)
  Эксп.2: -0.7820 (отрицательная)
  Изменение: ослабление отрицательной корреляции

Вывод по диагностике узких мест IO:

• Диск /data является узким местом в обоих экспериментах

• Высокая загрузка диска (100%) приводит к образованию очереди запросов

• Процессы проводят значительное время в ожидании IO (cpu_wa >50%)

• Характер нагрузки: OLAP с преобладанием операций чтения

• Проблема не в пропускной способности диска или IOPS

Итоговый вывод о влиянии параметра vm.swappiness

• Минимальное влияние на ключевые метрики: изменение vm.swappiness с 10 на 1 не привело к существенному изменению производительности подсистемы IO

• Незначительные улучшения во втором эксперименте:
  Снижение максимального времени ожидания записи (w_await)
  Уменьшение максимальной глубины очереди запросов (aqu_sz)
  Небольшое снижение времени ожидания CPU для IO (cpu_wa)

• Проблема перегруженности диска сохраняется: в обоих экспериментах наблюдается 100% загрузка диска и высокая очередь запросов

• Характер нагрузки определяет производительность: сценарий с высоким соотношением чтения/записи создает устойчивую нагрузку на диск, которая не может быть компенсирована настройками swappiness в данных условиях

• Результат согласуется с анализом корреляций: в обоих экспериментах выявлено, что узкое место не в IOPS или пропускной способности, а в самой загрузке диска, что делает изменение vm.swappiness неэффективным для решения основной проблемы

Итог

Проведенные эксперименты не подтвердили ожидаемого положительного влияния снижения параметра vm.swappiness на производительность PostgreSQL при интенсивной нагрузке с дефицитом оперативной памяти.

Основные выводы:

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

• Не было зафиксировано значимого улучшения или ухудшения итоговой операционной скорости СУБД. Ключевым узким местом в обоих экспериментах стала производительность дисковой подсистемы.

• Снижение vm.swappiness до 1 привело лишь к косвенному изменению профиля конкуренции за ресурсы в памяти, но это не повлияло на общую картину производительности, ограниченную вводом-выводом.

• Для подсистемы IO изменение параметра также не оказало существенного влияния: проблема 100% загрузки диска и высокой очереди запросов сохранилась при обоих значениях.

Общий вывод:

В условиях конкретной тестовой конфигурации (интенсивное чтение, нехватка RAM, ограниченная дисковая производительность) рекомендация по снижению vm.swappiness для оптимизации нагрузки в PostgreSQL не нашла экспериментального подтверждения. Производительность системы определялась другими факторами.