PG_EXPECTO 5.1: Влияние vm.swappiness=1 на производительность PostgreSQL⁠⁠

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

Настоящее исследование посвящено экспериментальной проверке общепринятой рекомендации по снижению параметра 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 не нашла экспериментального подтверждения. Производительность системы определялась другими факторами.