☑️Данный чек-лист представляет собой структурированное руководство по оптимизации операционной системы Linux для развертывания высоконагруженных систем управления базами данных (СУБД). Он основан на анализе критических проблем производительности, таких как высокий I/O wait, блокировка процессов и неэффективное использование памяти. Материал систематизирован по приоритетам — от критических изменений, без которых невозможна стабильная работа, до тонкой настройки для достижения максимальной эффективности. Следуя этим рекомендациям, администраторы смогут значительно повысить отказоустойчивость и скорость отклика инфраструктуры, особенно в средах с интенсивной транзакционной (OLTP) или аналитической (OLAP) нагрузкой.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Запрос
для заданной конфигурации СУБД и инфраструктуры сформируй и отранжируй чек-лист параметров инфраструктуры Linux для проверки целесообразности оптимизации параметров операционной системы
ЧЕК-ЛИСТ ПАРАМЕТРОВ LINUX ДЛЯ ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ СУБД
⚠️КРИТИЧЕСКИЙ УРОВЕНЬ (High Priority)
Параметры, напрямую влияющие на критические проблемы: высокий I/O wait, процессы в состоянии D, нехватка RAM.
☑️vm.dirty_ratio
Команда проверки: sysctl vm.dirty_ratio
Целевое значение: 10-15
Обоснование: Ключевой параметр! Определяет порог, при котором процессы блокируются на запись. Высокое значение (20-30) приводит к накоплению "грязных" страниц и массовым блокировкам (состояние D).
☑️vm.dirty_background_ratio
Команда проверки: sysctl vm.dirty_background_ratio
Целевое значение: 3-5
Обоснование: Порог фоновой записи. Слишком высокое значение откладывает запись, затем вызывает "взрывную" нагрузку. Для OLAP-нагрузки с большими чтениями нужен более агрессивный фоновый сброс.
☑️I/O Scheduler для дисков данных
Команда проверки: cat /sys/block/vd[d,x]/queue/scheduler
Целевое значение: none (noop) для KVM/VirtIO
Обоснование: В виртуальной среде (KVM) планировщик none (noop) минимизирует накладные расходы, передавая запросы гипервизору. mq-deadline или kyber могут создавать излишнюю очередь.
☑️vm.swappiness
Команда проверки: sysctl vm.swappiness
Целевое значение: 1-10
Обоснование: При почти полной загрузке RAM (free <5%) система может начать готовиться к свопингу. Резкое снижение заставляет ядро в первую очередь сбрасывать кэш файловой системы, а не искать кандидатов на своп.
☑️vm.dirty_expire_centisecs
Команда проверки: sysctl vm.dirty_expire_centisecs
Целевое значение: 1000-1500 (10-15 секунд)
Обоснование: Время жизни "грязной" страницы. Уменьшение делает запись более частой, но менее объемной "пачками", что сглаживает нагрузку на диск и снижает пики wa.
‼️ВЫСОКИЙ УРОВЕНЬ (Medium Priority)
Параметры, влияющие на общую производительность и стабильность под нагрузкой.
☑️Ограничение открытых файлов (nofile) для пользователя postgres
Команда проверки: su - postgres -c 'ulimit -n'
Целевое значение: 65535
Обоснование: При max_connections=1000 и большом количестве таблиц/индексов PostgreSQL может быстро исчерпать лимит. Это вызовет ошибки "Too many open files".
☑️vm.vfs_cache_pressure
Команда проверки: sysctl vm.vfs_cache_pressure
Целевое значение: 50-80
Обоснование: Управляет тенденцией ядра к высвобождению памяти, занятой кэшем inode и dentry. Уменьшение значения сохраняет кэш файловой системы дольше, что полезно для OLAP с частыми чтениями.
☑️Параметры монтирования для /data, /wal, /log
Команда проверки: mount | grep -E "(data|wal|log)"
Целевое значение: noatime,nodiratime,barrier=0 (если диск с батарейным кэшем)
Обоснование: noatime исключает запись времени доступа, снижая нагрузку на запись. barrier=0 отключает барьеры для дисков с батарейным кэшем (только если уверены в надежности).
[CPU Governor]
Команда проверки: cpupower frequency-info | grep governor
Целевое значение: performance
Обоснование: Фиксирует CPU на максимальной частоте, исключая задержки на переключение частот. Критично для виртуальных машин, где гипервизор может "тормозить" CPU в powersave.
[Кеш hugepages (опционально)]
Команда проверки: grep HugePages /proc/meminfo
Целевое значение: Рассчитать исходя из shared_buffers (например, для shared_buffers=2GB выделить 1GB hugepages)
Обоснование: Уменьшает накладные расходы на управление памятью, но требует настройки PostgreSQL (параметр huge_pages).
‼️СРЕДНИЙ УРОВЕНЬ (Low Priority)
Параметры "тонкой настройки" или для устранения потенциальных проблем.
net.core.somaxconn
Команда проверки: sysctl net.core.somaxconn
Целевое значение: 1024
Обоснование: Максимальный размер очереди принятых соединений. При пиковых подключениях к БД может предотвратить отказы.
net.ipv4.tcp_tw_reuse
Команда проверки: sysctl net.ipv4.tcp_tw_reuse
Целевое значение: 1
Обоснование: Позволяет переиспользовать сокеты в состоянии TIME_WAIT для исходящих соединений. Снижает нагрузку на сетевой стек при активной работе.
[vm.min_free_kbytes]
Команда проверки: sysctl vm.min_free_kbytes
Целевое значение: 262144 (256MB)
Обоснование: Минимальный объем свободной памяти для ядра. Увеличение может предотвратить deadlock при нехватке памяти, но слишком высокое значение уменьшает доступную память для процессов.
[Ограничение процессов (nproc) для пользователя postgres]
Команда проверки: su - postgres -c 'ulimit -u'
Целевое значение: 4096-8192
Обоснование: С учетом max_connections=1000 и фоновых процессов autovacuum (max_workers=4) может потребоваться увеличение.
ℹ️ДИАГНОСТИЧЕСКИЕ ПАРАМЕТРЫ (Для сбора информации перед оптимизацией)
Текущая нагрузка I/O
Команда проверки: iostat -dx 2 5 или iotop -o
Что оценивать: Утилизация дисков (%util), очередь (avgqu-sz), время отклика (await). Сравнить /data vs /wal.
📝Статистика dirty pages
Команда проверки: cat /proc/vmstat | grep -E "(dirty|writeback)"
Что оценивать: nr_dirty, nr_writeback. Если nr_dirty постоянно близко к лимиту — нужна оптимизация vm.dirty_*.
📝Pressure Stall Information (PSI)
Команда проверки: cat /proc/pressure/io или cat /proc/pressure/memory
Что оценивать: Показывает, как процессы страдают от нехватки I/O или памяти. Значения >10% указывают на серьезные проблемы.
📝Конфигурация дисковых очередей
Команда проверки: cat /sys/block/vdd/queue/nr_requests и cat /sys/block/vdd/queue/read_ahead_kb
Что оценивать: Глубина очереди (128-256 нормально) и readahead (для OLAP можно увеличить до 4096-8192).
📋ПРИОРИТЕТЫ И ПОРЯДОК ПРОВЕРКИ:
- Сначала диагностика (пункты 15-18) — понять текущее состояние системы.
- Критические параметры (1-5) — начинать оптимизацию с них, особенно с vm.dirty_* и I/O Scheduler.
- Высокие параметры (6-10) — проверить и настроить после стабилизации I/O.
- Средние параметры (11-14) — тонкая настройка после решения основных проблем.
📋ВАЖНЫЕ ПРЕДУПРЕЖДЕНИЯ:
- Изменяйте параметры по одному и тестируйте после каждого изменения (нагрузочный тест аналогичный "Эксперименту-8").
- Сохраняйте бэкапы конфигураций (sysctl -a > /root/sysctl_backup.conf, /etc/security/limits.conf.bak).
- Для виртуальной среды (KVM) некоторые параметры могут контролироваться гипервизором (например, I/O Scheduler на хосте). Согласуйте изменения с администраторами виртуальной инфраструктуры.
- Параметры файловой системы (barrier=0) применяйте только если диск имеет батарейный кэш (BBU) или вы готовы к риску потери данных при сбое питания.
Итог
Чек-лист охватывает ключевые аспекты настройки Linux для оптимальной работы СУБД, выделяя четыре уровня вмешательства: диагностика, критическая, высокая и средняя настройка.
Основное внимание уделяется управлению вводом-выводом (I/O) и памятью — параметрам vm.dirty_*, выбору планировщика дисков и настройке свопа. Регулировка этих параметров позволяет избежать лавинообразных блокировок и сгладить пиковую нагрузку на дисковую подсистему.
Дополнительно рассматриваются настройки сетевого стека, ограничений процессов и файловой системы, что в комплексе обеспечивает стабильную и предсказуемую работу базы данных под высокой нагрузкой.
Все изменения требуют поэтапного внедрения, тестирования и учета особенностей среды (виртуализация, оборудование).