Данный чек-лист представляет собой структурированное руководство по оптимизации операционной системы Linux для развертывания высоконагруженных систем управления базами данных (СУБД). Он основан на анализе критических проблем производительности, таких как высокий I/O wait, блокировка процессов и неэффективное использование памяти. Материал систематизирован по приоритетам — от критических изменений, без которых невозможна стабильная работа, до тонкой настройки для достижения максимальной эффективности. Следуя этим рекомендациям, администраторы смогут значительно повысить отказоустойчивость и скорость отклика инфраструктуры, особенно в средах с интенсивной транзакционной (OLTP) или аналитической (OLAP) нагрузкой.

ЧЕК-ЛИСТ ПАРАМЕТРОВ 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).

ПРИОРИТЕТЫ И ПОРЯДОК ПРОВЕРКИ:

1. Сначала диагностика (пункты 15-18) — понять текущее состояние системы.

2. Критические параметры (1-5) — начинать оптимизацию с них, особенно с vm.dirty_* и I/O Scheduler.

3. Высокие параметры (6-10) — проверить и настроить после стабилизации I/O.

4. Средние параметры (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_*, выбору планировщика дисков и настройке свопа. Регулировка этих параметров позволяет избежать лавинообразных блокировок и сгладить пиковую нагрузку на дисковую подсистему.

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

Все изменения требуют поэтапного внедрения, тестирования и учета особенностей среды (виртуализация, оборудование).

На основе экспериментальных данных и анализа представлено руководство по оптимизации ядра Linux для серверов PostgreSQL, испытывающих высокую нагрузку с преобладанием операций чтения — типичную для аналитических запросов, отчётов и систем обработки данных. Цель настройки — полностью раскрыть потенциал современного оборудования путём точной коррекции ключевых параметров, отвечающих за работу с памятью, дисковыми операциями и распределением задач процессора. Особое внимание уделяется использованию высокоскоростных накопителей SSD/NVMe и значительных объёмов оперативной памяти для снижения задержек и повышения эффективности кэширования данных.

По итогам проведенных экспериментов и на основании анализа результатов

10 ключевых параметров операционной системы Linux для read-heavy (нагрузки с преобладанием чтения) работы PostgreSQL . Их оптимизация позволит максимально использовать кэширование, снизить задержки ввода-вывода и эффективно распределить ресурсы процессора.

Для удобства параметры разделены по категориям: память, ввод-вывод и планировщик процессов. Рекомендуемые значения ориентированы на современное оборудование (SSD/NVMe) и значительный объем оперативной памяти.

🗂️ Память

Huge Pages (Огромные страницы)

Описание: Уменьшает нагрузку на TLB процессора и фрагментацию памяти, повышая производительность операций с большими объемами данных (например, shared_buffers).

Рекомендуемое значение: Включить явно (vm.nr_hugepages в sysctl и huge_pages = on в PostgreSQL). Отключить Transparent Huge Pages (THP).

Shared Memory Limits (shmmax, shmall)

Описание: Определяют максимальный размер одного сегмента и общий объем разделяемой памяти. Необходимы для выделения shared_buffers PostgreSQL.

Рекомендуемое значение: kernel.shmmax ≥ размер shared_buffers. kernel.shmall ≥ общий объем разделяемой памяти / размер страницы.

vm.swappiness

Описание: Склонность ядра к выгрузке страниц памяти на диск (своп). Низкое значение помогает удерживать кэш БД в RAM.

Рекомендуемое значение: 1 (минимальное) — 10.

vm.overcommit_memory

Описание: Стратегия выделения памяти. Вариант 2 предотвращает "OOM Killer" из-за чрезмерной памяти, выделенной процессам.

Рекомендуемое значение: 2 (рекомендовано для серверов БД).

Политика управления "грязными" страницами (dirty_*)

Описание: Контролирует, как часто модифицированные данные в памяти записываются на диск. Оптимизация снижает пики ввода-вывода.

Рекомендуемое значение: Использовать абсолютные значения в байтах для точного контроля (например, vm.dirty_background_bytes=67108864, vm.dirty_bytes=536870912). Для read-heavy нагрузки можно немного увеличить лимиты.

💾 Ввод-вывод (I/O) и Файловая система

noatime/nodiratime для точки монтирования данных

Описание: Отключает запись времени последнего доступа к файлу, экономя дисковые операции.

Рекомендуемое значение: Добавить опции noatime,nodiratime в /etc/fstab для раздела с данными PostgreSQL.

kernel.sched_migration_cost_ns

Описание: Время, в течение которого планировщик будет держать задачу на том же CPU перед миграцией. Снижение может улучшить балансировку нагрузки для параллельных процессов PostgreSQL.

Рекомендуемое значение: Экспериментально, например 50000 (50 мкс) для систем с несколькими ядрами.

Read Ahead для Logical Volume

Описание: Объем данных, которые система предзагружает с диска при последовательном чтении. Для read-heavy и OLAP полезно.

Рекомендуемое значение: Включить и увеличить значение (например, до 16384 КБ) для томов с данными БД.

⚙️ Планировщик и Лимиты ОС

Регулятор CPU и энергосбережение

Описание: Гарантирует, что процессоры работают на максимальной частоте, исключая задержки из-за энергосбережения.

Рекомендуемое значение: Установить регулятор в performance и отключить балансировку NUMA (kernel.numa_balancing=0), если нет разнородного доступа к памяти.

Лимиты на количество файлов и процессов (nofile, nproc)

Описание: Максимальное число одновременно открытых файлов и процессов для пользователя postgres. Критично при высоком max_connections.

Рекомендуемое значение: Значительно увеличить (например, soft/hard nofile = 500000, nproc = 500000).

💎 Рекомендации для read-heavy нагрузки

Для нагрузок, где чтение сильно преобладает над записью (например, отчетные системы, аналитика), сделайте акцент на следующем:

1. Память и кэширование: Максимально увеличить shared_buffers (до 25-40% RAM), обязательно включите Huge Pages. Установите низкий vm.swappiness (1-10).

2. Планировщик процессов: Настроить kernel.sched_migration_cost_ns для лучшего распределения параллельных запросов. Установить регулятор CPU в performance.

3. Автоочистка (Autovacuum): Агрессивность может быть частично отключена, так как данные редко меняются. Это экономит CPU-циклы. Однако плановый VACUUM (например, по cron) в период низкой нагрузки необходим.

🛠️ Практические шаги по настройке

1. Проверка текущих значений: sysctl -a | grep <параметр> и tuned-adm active для просмотра текущей конфигурации.

2. Применение настроек:

3. Через tuned (рекомендуется для RHEL/CentOS): Создать пользовательский профиль, как в , и активировать его командой tuned-adm profile <имя_профиля>.

4. Через sysctl: Добавить параметры в файл /etc/sysctl.d/99-postgresql.conf и выполните sysctl -p.

5. Настройка Huge Pages: Рассчитать необходимое количество: (shared_buffers + другие затраты) / 2MB. Установитб через vm.nr_hugepages в sysctl и huge_pages = on в postgresql.conf.

6. Монтирование с noatime: Отредактировать /etc/fstab, добавив опции к разделу с данными, и перемонтировать (mount -o remount /path).

7. Увеличение лимитов ОС: Отредактировать файл /etc/security/limits.d/postgresql.conf и настроить службы в systemd (если используется).

8. Перезагрузка: Перезагрузить сервер для применения всех изменений, особенно связанных с Huge Pages и tuned.

Итог

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

Ключевые шаги: обязательное включение Huge Pages, увеличение shared_buffers, снижение swappiness, отключение ненужных обновлений атрибутов файлов (noatime), настройка планировщика процессов и регулятора CPU на режим производительности, а также увеличение системных лимитов. Агрессивность autovacuum может быть снижена для экономии ресурсов.

Часто при замедлении работы базы данных первым решением кажется увеличение вычислительных ресурсов: больше ядер, памяти, быстрые диски. Однако существует и другой, более экономичный путь — заглянуть глубже, на уровень операционной системы, управляющей этими ресурсами.

Данная статья — это практический разбор реального кейса, где скрупулёзная настройка параметров подсистемы ввода-вывода, кэширования и планировщика задач Linux позволила поднять производительность PostgreSQL на впечатляющие 65%. Без замены железа, без увеличения лицензий, только за счёт грамотной оптимизации «фундамента», на котором работает СУБД. Мы пройдём по всем ключевым экспериментам, от базовых значений до финального результата, и покажем, какие именно настройки стали решающими в этой «бесплатной» победе над latency.

Тестовая среда, инструменты и конфигурация СУБД:

• СУБД: PostgreSQL 17

• Инструмент нагрузочного тестирования: pg_expecto

• Тестовая база данных: pgbench (10GB, простая структура)

• Условия тестирования: параллельная нагрузка от 5 до 22 сессий по каждому тестовому сценарию.

Базовые значения параметров IO

Общие параметры производительности:

• vm.dirty_ratio = 30

• vm.dirty_background_ratio = 10

Параметры IO-планировщика:

• [none] mq-deadline kyber bfq

Настройки кэширования и буферизации:

• vm.vfs_cache_pressure = 100

Параметры файловой системы:

• /dev/mapper/vg_data-LG_data on /data type ext4 (rw,relatime)

Размер буферов для операций с блочными устройствами

• read_ahead_kb=4096

Эксперимент-2: Общие параметры производительности

vm.dirty_ratio=10

vm.dirty_background_ratio=5

Эксперимент-3: Параметры IO-планировщика

[mq-deadline] kyber bfq none

Эксперимент-5: Настройки кэширования и буферизации

vm.vfs_cache_pressure=50

Эксперимент-7: Оптимизация параметров файловой системы

/dev/mapper/vg_data-LG_data on /data type ext4 (rw,noatime,nodiratime)

Эксперимент-8: Изменение размера буферов для операций с блочными устройствами

echo 256 > /sys/block/vdd/queue/read_ahead_kb

Итоговый результат влияния изменения параметров подсистемы IO на производительность СУБД

Среднее увеличение операционной скорости в результате применения изменений подсистемы IO по сравнению с базовыми значениями составило 65.09%.

Показатели производительности , ожиданий СУБД и метрик производительности IO в ходе экспериментов

Операционная скорость

Ожидания СУБД

IOPS

Пропускная способность (MB/s)

Длина очереди (aqu_sz)

Ожидание по чтению

Ожидание по записи

Итоговый вывод:

Систематическая оптимизация параметров подсистемы IO — таких как настройки кэширования, планировщика операций ввода-вывода и параметров файловой системы — позволила достичь значительного повышения производительности PostgreSQL.

Суммарный эффект от внесённых изменений выразился в среднем увеличении операционной скорости на 65,09% по сравнению с базовой конфигурацией. Наиболее существенный вклад внесли корректировки размера буферов предварительного чтения (read_ahead_kb) и отключение избыточного обновления временных меток файлов (noatime, nodiratime).

Результаты подтверждают - целенаправленная настройка окружения ОС является критически важным этапом развёртывания высоконагруженных СУБД.

В современных вычислительных системах операции ввода-вывода (I/O) часто становятся узким местом, ограничивающим общую производительность. Одним из ключевых параметров, влияющих на эффективность работы с дисковыми накопителями, является размер буфера предварительного чтения (read-ahead). Этот параметр определяет, сколько данных система заранее считывает с диска в память в ожидании последующих запросов. Хотя увеличение этого буфера может ускорить последовательные операции чтения, его неоптимальное значение способно привести к обратному эффекту — избыточной нагрузке на подсистему хранения, бесполезному расходованию пропускной способности и кэш-памяти.

В данной статье на реальном примере разбирается кейс анализа производительности блочного устройства vdd в Linux-системе, где наблюдалась 100% утилизация диска и высокие задержки. Мы детально исследуем метрики ввода-вывода, корреляции между ними и оценим целесообразность изменения параметра read_ahead_kb с текущего значения 4096 КБ. Материал будет полезен системным администраторам, DevOps-инженерам и всем, кто стремится глубже понять тонкости настройки ОС для максимизации отдачи от дисковой подсистемы.

Текущее значение

# cat /sys/block/vdd/queue/read_ahead_kb

4096

На основе анализа производительности IO для устройства vdd можно сделать следующие выводы и рекомендации:

Текущая ситуация с устройством vdd:

1. Утилизация диска (%util): постоянно 100% в течение всего периода наблюдения.

2. Задержки записи (w_await): в 94,55% наблюдений превышают 5 мс (ALARM).

3. Глубина очереди (aqu_sz): постоянно >1 (ALARM).

4. Соотношение чтения/записи: 3,36:1 (OLAP-сценарий, много операций чтения).

5. Средний размер запроса:
   Чтение (rareq_sz): ~9–10 КБ
   Запись (wareq_sz): ~10–11 КБ

6. Корреляция speed – IOPS: отрицательная (–0,7013), что указывает на не-IO-ограниченную систему (проблемы могут быть в CPU, блокировках, памяти).

7. Корреляция cache – r/s: отрицательная (–0,6421), что говорит об эффективности кэширования.

8. Параметр read_ahead_kb: текущее значение = 4096 (4 МБ).

Анализ целесообразности изменения read_ahead_kb:

✅ Аргументы за уменьшение значения:

1. Средний размер запроса на чтение всего ~10 КБ, а предзагрузка установлена на 4 МБ — это избыточно и может приводить к:
   Чтению лишних данных, которые не используются.
   Нагрузке на IO-подсистему без реальной пользы.
   Заполнению кэша ненужными данными, вытесняя полезные.

2. Высокая утилизация диска (100%) и большая глубина очереди указывают на то, что диск перегружен. Уменьшение read_ahead_kb может снизить избыточную нагрузку.

3. OLAP-сценарий (много чтения) — в таких случаях слишком большой read-ahead может мешать, если запросы случайные или не последовательные.

⚠️ Аргументы против уменьшения:

1. Если нагрузка в основном последовательное чтение больших файлов (например, обработка логов, дампов), то большой read-ahead может быть полезен.

2. Резкое уменьшение может увеличить количество IOPS, что при уже высокой утилизации может ухудшить ситуацию.

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

Изменить read_ahead_kb с 4096 на 128–256 КБ (например, 256 КБ), так как:

• Средний размер запроса ~10 КБ.

• Это уменьшит избыточное чтение, но сохранит преимущества предзагрузки для последовательных операций.

• Наблюдать за изменениями в r/s, r_await, %util, aqu_sz.

Команда для изменения:

echo 256 > /sys/block/vdd/queue/read_ahead_kb

Мониторинг после изменения:

1. Сравнить r/s, rMB/s, r_await, %util до и после.

2. Проверить, не увеличилась ли глубина очереди (aqu_sz).

3. Оценить влияние на общую производительность (например, через vmstat, iostat).

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

1. Исследовать другие узкие места: так как система не ограничена IO, стоит проверить:
   CPU (wa > 10% — ALARM).
   Память (использование кэша и буферов).
   Процессы в D состоянии (ожидание IO).

2. Оптимизировать запросы к СУБД:
   Увеличить shared_buffers (если PostgreSQL).
   Проверить наличие полных сканирований больших таблиц.

3. Рассмотреть возможность увеличения IOPS/пропускной способности диска (если это облачный диск — изменить тип на более производительный).

Заключение:

Изменение read_ahead_kb с 4096 на 256 КБ целесообразно, но должно проводиться осторожно, с мониторингом. Это может снизить избыточную нагрузку на диск, но не решит основную проблему — 100% утилизацию диска, которая требует более комплексного подхода (апгрейд диска, оптимизация запросов, увеличение кэша).