PG_EXPECTO : Изменение vm.dirty_expire_centisecs/vm.dirty_writeback_centisecs

Баланс I/O: сглаживаем пики, повышаем отзывчивость.

Глоссарий терминов | Postgres DBA | Дзен

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Теоретическая часть- vm.dirty_expire_centisecs

Команда проверки: sysctl vm.dirty_expire_centisecs

Целевое значение: 1000-1500 (10-15 секунд)

Обоснование: Время жизни "грязной" страницы. Уменьшение делает запись более частой, но менее объемной("пачками"), что сглаживает нагрузку на диск и снижает пики wa.

vm.dirty_expire_centisecs — настраиваемый параметр в Linux, который определяет, насколько старым может быть «грязный» буфер, прежде чем его необходимо пометить для асинхронной записи. 

Значение параметра выражается в сантисекундах (100-х долях секунды).

Запрос по итогам нагрузочного тестирования

Данные о производительности СУБД и vmstat : (PG_EXPECTO 5.1 + OS tuning : Эксперимент-2(shared_buffers = 4GB))

Проанализируй показатели производительности СУБД и vmstat и дай рекомендации по оптимизации параметра vm.dirty_expire_centisecs

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

На основе анализа предоставленных данных, я выделю ключевую проблему и дам конкретные рекомендации по настройке vm.dirty_expire_centisecs.

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

Высокая корреляция I/O ожиданий:

• IO-wa = 0.9393 (очень высокая корреляция)
• IO-b = 0.9757 (очень высокая корреляция)
• wa > 10% в 100% наблюдений (ALARM)

Процессы в состоянии D (b) растут:

• Линия регрессии для процессов в uninterruptible sleep имеет угол наклона +43.65, R²=0.91
• Количество процессов в состоянии D превышает число CPU в 42.99% наблюдений (WARNING)

Соотношение чтение/запись:

• Отношение bi/bo = 2.91 (читается почти в 3 раза больше, чем пишется)
• OLAP-сценарий с интенсивным чтением

Рекомендации по vm.dirty_expire_centisecs

Текущая проблема:

Значение vm.dirty_expire_centisecs по умолчанию (3000 = 30 секунд) слишком велико для вашей нагрузки.

Данные слишком долго лежат в кэше перед записью, что приводит к:

• Резким всплескам I/O при массовой записи
• Длительным ожиданиям процессов в состоянии D
• Конкуренции между операциями чтения и отложенной записью

Предлагаемые значения:

# Рекомендуемые настройки для OLAP-нагрузки с интенсивным чтением

vm.dirty_expire_centisecs = 1000 # 10 секунд (вместо 30 по умолчанию)

vm.dirty_writeback_centisecs = 500 # 5 секунд (вместо 5 по умолчанию, но более агрессивно)

# Дополнительные рекомендуемые настройки

vm.dirty_background_ratio = 5 # 5% от RAM

vm.dirty_ratio = 10 # 10% от RAM

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

vm.dirty_expire_centisecs = 1000 (10 секунд):

• Уменьшает максимальное время хранения "грязных" данных в 3 раза
• Позволяет более равномерно распределить запись на диск
• Снижает риск накопления большого объема данных для сброса

vm.dirty_expire_centisecs — настраиваемый параметр в Linux, который определяет, насколько старым может быть «грязный» буфер, прежде чем его необходимо пометить для асинхронной записи.

vm.dirty_writeback_centisecs = 500 (5 секунд):

• Более частая активация процессов записи
• Предотвращает накопление критического объема данных

vm.dirty_writeback_centisecs — параметр ядра Linux, который определяет время ожидания между операциями сброса при асинхронном сбросе «грязных» буферов

Для вашей конфигурации RAM (7.5 GB):

• dirty_background_bytes ≈ 384 MB (5% от RAM)
• dirty_bytes ≈ 768 MB (10% от RAM)
• Эти лимиты предотвратят чрезмерное накопление данных

vm.dirty_background_bytes — параметр ядра операционной системы Linux, который указывает объём «грязной» памяти, при достижении которого фоновые потоки для записи данных в ядре начинают записывать изменённые данные из памяти на диск.

vm.dirty_bytes — параметр в Linux, который определяет объём данных, сбрасываемых из оперативной памяти на диск выполняемым запросом.

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

1. Мониторинг после изменений:

# Проверка текущих значений

cat /proc/vmstat | grep -E "dirty|writeback"

# Мониторинг в реальном времени

watch -n 1 "grep -E 'Dirty:|Writeback:' /proc/meminfo"

2. Настройки PostgreSQL для снижения I/O:

Учитывая OLAP-характер нагрузки:

-- Увеличить статистику по автоочистке для лучшего планирования запросов

ALTER SYSTEM SET default_statistics_target = 500;

-- Более агрессивная настройка autovacuum для больших таблиц

ALTER SYSTEM SET autovacuum_vacuum_scale_factor = 0.05;

ALTER SYSTEM SET autovacuum_analyze_scale_factor = 0.02;

-- Увеличить work_mem для сложных сортировок и хэш-соединений

ALTER SYSTEM SET work_mem = '64MB';

3. Оптимизация файловой системы:

# Для XFS (если используется)

mount -o remount,noatime,nodiratime,allocsize=256m,inode64 /data

# Проверка текущих параметров

xfs_info /dev/mapper/vg_data-LG_data

4. Проверка планировщика дисков:

# Убедитесь, что используется правильный планировщик

cat /sys/block/vdd/queue/scheduler

# Рекомендуется для SSD или быстрых дисков

echo "mq-deadline" > /sys/block/vdd/queue/scheduler

Ожидаемый эффект:

1. Снижение wa (I/O wait) с текущих 50-71% до 20-40%
2. Уменьшение процессов в состоянии D с 16 до 5-8
3. Более стабильная производительность без резких провалов
4. Улучшение времени отклика операций чтения

Важные предупреждения:

Тестируйте изменения поэтапно:

# Временное изменение

sysctl -w vm.dirty_expire_centisecs=1000

# Постоянное изменение (в /etc/sysctl.conf)

echo "vm.dirty_expire_centisecs = 1000" >> /etc/sysctl.conf

Мониторьте нагрузку на диск после изменений:

iostat -x 1

При слишком агрессивных настройках может возрасти нагрузка на диск из-за более частых мелких записей. Если это произойдет, увеличьте значение до 1500-2000.

Данные настройки оптимизируют баланс между отзывчивостью системы и эффективностью использования дискового ввода-вывода для вашего конкретного OLAP-сценария.

Инструкция по изменению vm.dirty_ *

1. Проверка текущих значений

sysctl vm.dirty_expire_centisecs

sysctl vm.dirty_writeback_centisecs

sysctl vm.dirty_background_ratio

sysctl vm.dirty_ratio

2. Временное изменение (без перезагрузки)

sudo sysctl -w vm.dirty_expire_centisecs=1000

sudo sysctl -w vm.dirty_writeback_centisecs=500

sudo sysctl -w vm.dirty_background_ratio=5

sudo sysctl -w vm.dirty_ratio=10

3. Постоянное изменение (через sysctl.conf)

# Создаем резервную копию

sudo cp /etc/sysctl.conf /etc/sysctl.conf.backup.$(date +%Y%m%d)

# Редактируем файл

sudo nano /etc/sysctl.conf

# Добавляем в конец файла:

vm.dirty_expire_centisecs = 1000

vm.dirty_writeback_centisecs = 500

vm.dirty_background_ratio = 5

vm.dirty_ratio = 10

4. Применяем изменения

sudo sysctl -p

5. Проверяем результат

sysctl vm.dirty_expire_centisecs vm.dirty_writeback_centisecs vm.dirty_background_ratio vm.dirty_ratio

6. Мониторинг эффекта

# Смотрим изменение состояния

watch -n 2 "grep -E 'Dirty:|Writeback:' /proc/meminfo"

# Проверяем метрики I/O

vmstat 1 10

7. Откат при необходимости

# Временный откат

sudo sysctl -w vm.dirty_expire_centisecs=3000

sudo sysctl -w vm.dirty_writeback_centisecs=5000

sudo sysctl -w vm.dirty_background_ratio=10

sudo sysctl -w vm.dirty_ratio=20

# Постоянный откат

sudo cp /etc/sysctl.conf.backup.* /etc/sysctl.conf

sudo sysctl -p

Экспериментальная проверка влияния vm.dirty_expire_centisecs=1000 на производительность СУБД