На основе анализа отчёта о производительности выявлены три критические проблемы:
- критическая нехватка оперативной памяти (RAM <5%),
- сильный bottleneck ввода-вывода (высокий cpu_wa, процессы в состоянии 'D')
- конкуренция за CPU из-за блокировок.
Следующие 10 параметров ОС Linux подобраны и ранжированы специально для устранения этих узких мест в текущей конфигурации. Оптимизация направлена на стабилизацию памяти, снижение задержек ввода-вывода и более эффективное использование процессорных ресурсов.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Общие рекомендации по настройке параметров Linux
Top-10 параметров ОС Linux для практической оптимизации PostgreSQL
1. vm.swappiness
Рекомендуемое значение: 1
Обоснование: Прямое лечение симптома ALARM: свободной RAM <5%. Резко снижает склонность ядра к вытеснению страниц памяти на диск, помогая удерживать кэш БД в RAM.
2. Политика vm.dirty_* (фоновая запись)
Рекомендуемое значение:
vm.dirty_background_bytes = 67108864 (64 MB)
vm.dirty_bytes = 536870912 (512 MB)
Обоснование: Снижение уровня корреляции(ALARM): высокая корреляция IO-b (0.969). Ограничивает объём неписанных данных в кеше, предотвращая массивные и блокирующие записи на диск, которые переводят процессы в состояние непрерываемого сна (procs_b).
3.vm.overcommit_memory
Рекомендуемое значение: 2
Обоснование: Защита от OOM-Killer. Стратегия 2 гарантирует, что ядро не позволит процессам выделить больше памяти, чем доступно, что критично при стабильной нехватке RAM.
4. Huge Pages (Огромные страницы)
Рекомендуемое действие: Явно включить, рассчитав vm.nr_hugepages. Обязательно отключить Transparent Huge Pages (THP).
Обоснование: Снижает накладные расходы ядра на управление памятью для больших буферов (как shared_buffers = 2GB). Повышает стабильность и предсказуемость при работе с памятью.
5.Регулятор CPU (CPU Frequency Governor)
Рекомендуемое значение: performance
Обоснование: Лечит ALARM: высокая корреляция LWLock-us (0.955). Фиксирует процессоры на максимальной частоте, исключая задержки из-за энергосбережения и стабилизируя время отклика СУБД.
6. kernel.sched_migration_cost_ns
Рекомендуемое значение: 500000 (0.5 миллисекунды)
Обоснование: Помогает снизить contention на легковесные блокировки (LWLock), увеличивая время, в течение которого задача остаётся на одном ядре, прежде чем планировщик попробует её мигрировать.
7. Read Ahead (предварительное чтение) для Logical Volume
Рекомендуемое действие: Увеличить значение read_ahead_kb до 16384 (16 MB) для тома с данными (/data).
Обоснование: Учитывая OLAP-сценарий с соотношением чтения/записи 3.3:1, улучшает производительность последовательных операций чтения большого объёма данных.
8. Лимиты ОС на дескрипторы и процессы
Рекомендуемые значения:
nofile (мягкий/жёсткий) = 500000
nproc (мягкий/жёсткий) = 500000
Обоснование: Создаёт достаточный запас для высокого значения max_connections=1000 и фоновых рабочих процессов, предотвращая ошибки из-за исчерпания лимитов.
9. Параметры разделяемой памяти (kernel.shmall, kernel.shmmax)
Рекомендуемое действие: Проверить, что текущие значения достаточны для размещения shared_buffers (2GB) и других структур.
Обоснование: Базовое требование для работы PostgreSQL. Недостаточные значения помешают серверу запуститься с текущими настройками.
10. Опция монтирования noatime
Рекомендуемое действие: Добавить опции noatime,nodiratime для точек монтирования /data и /wal в /etc/fstab.
Обоснование: Устраняет обязательную операцию записи на диск при каждом чтении файла (обновление времени доступа), снижая нагрузку на I/O.
Итог
Представленный список — это целевой план действий, сфокусированный на решении конкретных проблем вашей системы, выявленных в отчёте. Применение этих настроек (особенно первых пяти) должно привести к снижению времени ожиданий I/O (cpu_wa), сокращению количества заблокированных процессов (procs_b) и повышению общей стабильности работы PostgreSQL.
После внесения изменений необходимо провести повторное нагрузочное тестирование, чтобы объективно оценить эффект от оптимизации.
