Настоящее исследование посвящено экспериментальной проверке общепринятой рекомендации по снижению параметра vm.swappiness для серверов PostgreSQL . В ходе нагрузочного тестирования на синтетической рабочей нагрузке, имитирующей аналитические запросы, было оценено влияние значений vm.swappiness = 10 и vm.swappiness = 1 на производительность СУБД и инфраструктуры. Результаты выявили неожиданные закономерности, ставящие под сомнение универсальность данной рекомендации.
В статье представлены результаты нагрузочного тестирования PostgreSQL на синтетической рабочей нагрузке, имитирующей аналитические запросы (OLAP). Цель исследования: определить - как снижение параметра vm.swappiness влияет на взаимодействие СУБД с подсистемой ввода-вывода Linux.
Глоссарий терминов | Postgres DBA | Дзен
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Теоретическая часть
🎯 Влияние 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.
- Проверьте текущее значение: cat /proc/sys/vm/swappiness
- Измените значение (временно, до перезагрузки): sudo sysctl -w vm.swappiness=1
- Сделайте изменение постоянным. Добавьте или измените строку в файле /etc/sysctl.conf vm.swappiness=1
- После сохранения файла примените изменения: 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.
scenario-2 (INSERT)
scenario-3 (UPDATE)
scenario-1 (SELECT) - без изменений
Веса тестовых сценариев и параметры нагрузочного тестирования
# Веса сценариев по умолчанию
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
settings.txt - конфигурация СУБД и инфраструктуры
1.summary.txt - показатели производительности СУБД и vmstat в ходе эксперимента-1
2.summary.txt - показатели производительности СУБД и vmstat в ходе эксперимента-2
Проанализируй данные по метрикам производительности и ожиданий СУБД , метрикам инфраструктуры vmstat.
Подготовь сравнительный итоговый отчет по результатам анализа производительности СУБД и инфраструктуры.
Подготовь итоговый вывод о влиянии значения параметра vm.swappiness на производительности СУБД и инфраструктуры для данного характера нагрузки и заданных параметров СУБД и операционной системы.
Исключи из отчета рекомендации по оптимизации.
Для построения отчета используй списки , а не таблицы.
Сравнительный отчет по результатам экспериментов с 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) и предоставленного характера нагрузки (интенсивное чтение, вызывающее дефицит свободной оперативной памяти):
- Отсутствие влияния на своппинг: Изменение параметра vm.swappiness с 10 на 1 не привело к качественному изменению поведения системы. В обоих случаях система предпочла не использовать раздел подкачки, даже в условиях хронической нехватки свободной оперативной памяти.
- Несущественное влияние на производительность СУБД: Не было зафиксировано значимого улучшения или ухудшения итоговой операционной скорости (SPEED) СУБД. Основная проблема производительности в обоих экспериментах была одинакова и заключалась в дисковом вводе-выводе, который стал узким местом.
- Изменение профиля конкуренции: Снижение swappiness до 1 привело к появлению статистически значимой корреляции ожиданий СУБД с IPC и LWLOCK. Это косвенно свидетельствует о том, что при более жестком ограничении на использование свопа процессы СУБД активнее конкурировали за структуры данных в оперативной памяти (буферы, легковесные блокировки), однако это не стало новым узким местом по сравнению с дисковым IO.
Общий вывод:
В рамках проведенных экспериментов с интенсивной нагрузкой, вызывающей дефицит оперативной памяти, параметр vm.swappiness не оказал решающего влияния на общую производительность системы и СУБД PostgreSQL. Основным лимитирующим фактором в обоих случаях была производительность дисковой подсистемы. Система в обоих конфигурациях избегала своппинга, выбирая стратегию вытеснения файлового кэша, что лишь усиливало нагрузку на диски. Изменения в поведении СУБД были минимальны и не повлияли на ключевую проблему производительности.
Анализ производительности IO для файловой системы /data
settings.txt - конфигурация СУБД и инфраструктуры
1.io_performance.txt - показатели производительности IO в ходе эксперимента-1
2.io_performance.txt - показатели производительности IO в ходе эксперимента-2
Подготовь сравнительный отчет по результатам анализа производительности подсистемы IO в ходе экспериментов для дисковых устройств, используемых для файловой системы /data
**Общая характеристика системы**
- Тип нагрузки
Состав отчета по файловой системе:
**Критические проблемы производительности по файловой системе**
**Анализ корреляций и паттернов нагрузки по файловой системе**
**Диагностика узких мест IO по файловой системе**
- r_await(ms)
- w_await(ms)
- aqu_sz
- proc_b
- cpu_wa(%)
- Корреляция speed с IOPS
- Корреляция speed с пропускной способностью (MB/s)
- Вывод по диагностике узких мест IO
Подготовь итоговый вывод о влиянии значения параметра vm.swappiness на производительности подсистемы IO для данного характера нагрузки и заданных параметров СУБД и операционной системы.
Исключи из отчета рекомендации по оптимизации.
Для построения отчета используй списки , а не таблицы.
Сравнительный отчет по производительности подсистемы 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% загрузка диска и высокая очередь запросов
- Характер нагрузки определяет производительность: OLAP-сценарий с высоким соотношением чтения/записи создает устойчивую нагрузку на диск, которая не может быть компенсирована настройками swappiness в данных условиях
- Результат согласуется с анализом корреляций: в обоих экспериментах выявлено, что узкое место не в IOPS или пропускной способности, а в самой загрузке диска, что делает изменение vm.swappiness неэффективным для решения основной проблемы
Итог
Проведенные эксперименты не подтвердили ожидаемого положительного влияния снижения параметра vm.swappiness на производительность PostgreSQL при интенсивной нагрузке с дефицитом оперативной памяти.
- Изменение параметра не привело к качественному изменению поведения подсистемы памяти: система в обоих случаях избегала своппинга, предпочитая вытеснять файловый кэш.
- Не было зафиксировано значимого улучшения или ухудшения итоговой операционной скорости СУБД. Ключевым узким местом в обоих экспериментах стала производительность дисковой подсистемы.
- Снижение vm.swappiness до 1 привело лишь к косвенному изменению профиля конкуренции за ресурсы в памяти, но это не повлияло на общую картину производительности, ограниченную вводом-выводом.
- Для подсистемы IO изменение параметра также не оказало существенного влияния: проблема 100% загрузки диска и высокой очереди запросов сохранилась при обоих значениях.
Общий вывод
В условиях конкретной тестовой конфигурации (интенсивное чтение, нехватка RAM, ограниченная дисковая производительность) рекомендация по снижению vm.swappiness для оптимизации нагрузки в PostgreSQL не нашла экспериментального подтверждения. Производительность системы определялась другими факторами.
Итог эксперимента
Откат изменения vm.swappiness к ранее установленному значению 10