kznalp

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

Данная статья — это практический разбор реального кейса, где скрупулёзная настройка параметров подсистемы ввода-вывода, кэширования и планировщика задач 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).

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

В мире оптимизации СУБД иногда меньше означает больше. Вопреки стандартным рекомендациям об увеличении буферов, эксперимент показал, что осознанное уменьшение размера read_ahead_kb с 4 МБ до 256 КБ привело к росту общей производительности PostgreSQL на 7%. Это напоминание о том, что каждая система уникальна, а оптимизация требует тонкой настройки под реальную нагрузку.

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

Read_ahead_kb — параметр, который определяет максимальное количество килобайт, которые операционная система может прочитать заранее во время последовательной операции чтения.

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

По умолчанию значение параметра — 128 КБ для каждого сопоставляемого устройства. Однако увеличение значения read_ahead_kb до 4–8 МБ может улучшить производительность в средах приложений, где происходит последовательное чтение больших файлов

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

cat /sys/block/vdd/queue/read_ahead_kb

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

4096

Изменение:

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

Основание:

• Увеличение предварительного чтения может улучшить производительность последовательных операций чтения.

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

• Улучшение rMB/s для последовательных рабочих нагрузок.

Итоговый отчет по анализу производительности подсистемы IO

1. Общая характеристика системы

• Период анализа: 2026-01-07 10:50 - 2026-01-07 12:39 (109 минут)

• Основные устройства хранения:

• vdd (vg_data-LG_data): 100ГБ, смонтирован в /data - основной диск данных

• vdc (vg_wal-LG_wal): 50ГБ, смонтирован в /wal - диск для WAL

• vdb (vg_log-LG_log): 30ГБ, смонтирован в /log

• vda: системный диск с разделами ОС

• Тип нагрузки: Смешанная нагрузка с признаками как OLTP, так и OLAP

• Для vdd: OLAP-сценарий (соотношение чтение/запись = 3.33:1)

• Для vdc: OLTP-паттерн (высокая корреляция speed-IOPS)

2. Критические проблемы производительности

Для устройства vdd (/data):

• ALARM: Загрузка устройства 100% во всех 110 наблюдениях

• ALARM: Высокое время отклика на запись - 94.55% наблюдений превышают 5мс

• ALARM: Постоянно высокая длина очереди - 100% наблюдений с aqu_sz > 1 (до 35)

• ALARM: Высокий процент ожидания CPU IO (wa) - 100% наблюдений с wa > 10%

• ALARM: Процессы в uninterruptible sleep возрастают при высоком wa

Для устройства vdc (/wal):

• ALARM: Загрузка устройства >50% - 100% наблюдений (50-66%)

• WARNING: Высокая корреляция wa-util (0.5115) - процессы ждут диск

• ALARM: Очень высокая корреляция cache-w/s (0.7635) - неэффективное использование памяти

3. Анализ корреляций и паттернов нагрузки

Устройство vdd:

• Отрицательная корреляция memory cache - r/s (-0.8040) и cache - rMB/s (-0.8465)

• Память неэффективно используется для снижения нагрузки на диск

• Отрицательная корреляция speed-IOPS (-0.2205) и speed-MB/s (-0.8862)

• Производительность не ограничена IOPS или пропускной способностью

• Узкое место в CPU, блокировках или параметрах параллелизма

Устройство vdc:

• Высокая положительная корреляция speed-IOPS (0.7764)

• Классический OLTP-паттерн, производительность зависит от способности диска обрабатывать мелкие операции

• Отрицательная корреляция speed-MB/s (-0.6110)

• Проблема не в пропускной способности диска

4. Диагностика узких мест IO

Показатели для vdd:

• r_await(ms): 2-5 мс (в пределах нормы)

• w_await(ms): 4-16 мс (критически высоко, 94.55% > 5мс)

• aqu_sz: 10-35 (критически высоко, всегда > 1)

• proc_b: 5-13 процессов в uninterruptible sleep

• cpu_wa(%): 39-45% (критически высоко)

• Корреляция speed-IOPS: -0.2205 (отрицательная)

• Корреляция speed-MB/s: -0.8862 (сильно отрицательная)

Показатели для vdc:

• r_await(ms): 0 мс (нет операций чтения)

• w_await(ms): 0.56-0.62 мс (в норме)

• aqu_sz: 0.6-0.71 (в норме)

• proc_b: 5-13 процессов в uninterruptible sleep

• cpu_wa(%): 39-45% (критически высоко)

• Корреляция speed-IOPS: 0.7764 (сильно положительная)

• Корреляция speed-MB/s: -0.6110 (отрицательная)

Вывод по диагностике узких мест IO:

1. vdd является основным узким местом - 100% загрузка, длинные очереди, высокое время отклика записи

2. Высокий cpu_wa на обоих устройствах указывает на системную проблему с IO

3. Разные паттерны нагрузки на vdd (OLAP) и vdc (OLTP) требуют разных подходов к оптимизации

4. Память используется неэффективно для кэширования, особенно на vdd

Итоговый вывод по производительности IO

Текущее состояние: Критическое. Система испытывает серьезные проблемы с производительностью IO, особенно на основном диске данных (vdd).

Основные проблемы:

1. Диск vdd постоянно загружен на 100% с длинными очередями запросов

2. Высокое время отклика на операции записи (до 16мс)

3. Неэффективное использование оперативной памяти для кэширования

4. Значительные простои CPU из-за ожидания IO (wa 39-45%)

Прогноз: Без вмешательства производительность будет деградировать при росте нагрузки, возможны отказы служб из-за таймаутов IO.

Приоритет действий: Высокий. Рекомендуется начать с немедленных оптимизаций настроек СУБД и мониторинга, затем перейти к апгрейду инфраструктуры.

Эксперимент-7(Оптимизация параметров файловой системы) vs Эксперимент-8( Изменение размера буферов для операций с блочными устройствами).

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

Среднее увеличение операционной скорости в ходе Эсперимента-8 по сравнению с Экпериментом-7 составило 7.79%.⬆️

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

IOPS

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

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

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

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

1. Сравнение критических проблем производительности

Вывод: Оба эксперимента показывают, что узкое место не в подсистеме IO, а в других компонентах системы (CPU, блокировки, СУБД).

2. Сравнительный анализ корреляций и паттернов нагрузки

3. Диагностика метрик IO

3.1 r_await (ms)

• Эксп. 7: 2–5 мс, стабильно низкий.

• Эксп. 8: 2–5 мс, стабильно низкий.

• Вывод: Задержки чтения в норме, проблем нет.

3.2 w_await (ms)

• Эксп. 7: 4–16 мс, есть рост в конце.

• Эксп. 8: 4–16 мс, стабилен.

• Вывод: Задержки записи также в допустимых пределах.

3.3 aqu_sz (средняя длина очереди)

• Эксп. 7: 10–31, растёт к концу.

• Эксп. 8: 10–35, также рост к концу.

• Вывод: Очереди увеличиваются, что может указывать на рост нагрузки или блокировок.

3.4 proc_b (количество процессов в ожидании IO)

• Эксп. 7: 4–13, умеренный рост.

• Эксп. 8: 5–13, стабильно.

• Вывод: Количество процессов в ожидании IO не критично.

3.5 cpu_wa (%) (время ожидания CPU)

• Эксп. 7: 39–47%, высокий уровень.

• Эксп. 8: 39–45%, также высокий.

• Вывод: Высокий cpu_wa указывает на то, что CPU часто простаивает в ожидании IO или других ресурсов.

3.6 Корреляция speed с IOPS

• Отрицательная в обоих случаях, но в эксп. 7 — сильнее.

• Это подтверждает, что производительность не зависит от IOPS.

3.7 Корреляция speed с пропускной способностью

• Отрицательная, особенно сильная в эксп. 8.

• Пропускная способность диска не является ограничением.

3.8 Другие показатели производительности IO

• Utilization: 100% в обоих экспериментах, но это не означает перегрузку IO, так как задержки низкие.

• Shared блоки: активный рост в обоих случаях, что характерно для OLTP-нагрузки.

• Время чтения/записи shared блоков: растёт, особенно в эксп. 8.

3.9 Вывод по диагностике узких мест IO

• IO не является узким местом ни в одном из экспериментов.

• Проблемы связаны с CPU, блокировками, ожиданиями СУБД.

• Рост очередей (aqu_sz) и времени ожидания CPU указывают на проблемы с параллелизмом или блокировками в СУБД.

4. Итоговый вывод по сравнению производительности IO в ходе экспериментов

1. Оба эксперимента подтверждают отсутствие IO-ограничений.

2. Задержки чтения/записи низкие, пропускная способность не влияет на производительность.

3. Эксперимент 8 показывает лучшую оптимизацию параметров IO, что выражается в более стабильных метриках r_await и w_await, а также в снижении влияния IOPS на скорость.

4. Основные проблемы остаются неизменными:

5. Высокий cpu_wa указывает на неэффективное использование CPU.

6. Рост aqu_sz и proc_b говорит о возможных блокировках или недостатке параллелизма.

7. Рекомендуется фокус на оптимизацию СУБД, настройку параллелизма и устранение блокировок.

8. Рекомендации:

9. Провести анализ ожиданий в СУБД (locks, latches, waits).

10. Настроить параметры параллелизма (если используется PostgreSQL — max_connections, work_mem, shared_buffers и т.д.).

11. Рассмотреть возможность увеличения CPU или оптимизации запросов.

Заключение: Эксперимент 8 демонстрирует улучшение в части управления IO, но системные проблемы (CPU, блокировки) остаются. Для дальнейшего повышения производительности необходимо сосредоточиться на оптимизации работы СУБД и устранении узких мест, не связанных с IO.

В современных вычислительных системах операции ввода-вывода (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% утилизацию диска, которая требует более комплексного подхода (апгрейд диска, оптимизация запросов, увеличение кэша).

Производительность PostgreSQL в высокой степени зависит от корректной работы с памятью. Ядро Linux, управляя дисковым кэшем и буферами, может как значительно ускорить работу СУБД, так и стать причиной серьёзных проблем — от излишнего свопинга до деградации производительности из-за двойного кэширования. В статье предоставлены практические инструкции по настройке ключевых параметров ядра (vm.swappiness, vm.dirty_*, vm.vfs_cache_pressure) для оптимальной работы PostgreSQL.

Исходные данные

Характер нагрузки на СУБД: преобладание чтения над записью

RAM = 8GB

shared_buffers = 2GB

🔍 Часть 1: Диагностика текущего состояния

1.1. Проверка параметров кэширования ОС Linux

1. Текущие значения параметров виртуальной памяти:

# Основные параметры dirty-страниц и буферизации

echo "=== Текущие настройки кэширования ОС ==="

sudo sysctl -a | grep -E "(dirty|swappiness|vfs_cache_pressure)" | grep -v net.ipv4

# Альтернативно - чтение напрямую из /proc/sys/vm

cat /proc/sys/vm/swappiness

cat /proc/sys/vm/dirty_background_ratio

cat /proc/sys/vm/dirty_ratio

cat /proc/sys/vm/dirty_expire_centisecs

cat /proc/sys/vm/dirty_writeback_centisecs

cat /proc/sys/vm/vfs_cache_pressure

2. Проверка состояния Transparent Huge Pages:

cat /sys/kernel/mm/transparent_hugepage/enabled

# Результат: [never] значит отключено, [always] - включено

3. Мониторинг текущего использования кэша и буферов:

# Общая статистика памяти

free -h

# Подробная информация о dirty-страницах

grep -E "(Dirty|Writeback|NFS_Unstable)" /proc/meminfo

# Динамический мониторинг (обновление каждые 2 секунды)

watch -n 2 'grep -E "(Dirty|Writeback)" /proc/meminfo && echo "---" && free -h | grep -v total'

4. Проверка активности диска (критично для анализа влияния записи):

# Установите sysstat если нет: sudo yum install sysstat / sudo apt-get install sysstat

iostat -x 2 5

# Обратите внимание на:

# - %util (загрузка диска)

# - await (среднее время ожидания)

# - avgqu-sz (средняя длина очереди)

1.2. Диагностика кэширования PostgreSQL

1. Подключение к базе данных и проверка hit ratio:

psql -U postgres -d БД

-- Общий hit ratio для всех таблиц

SELECT

sum(heap_blks_read) as heap_read,

sum(heap_blks_hit) as heap_hit,

CASE

WHEN sum(heap_blks_hit) > 0 THEN

ROUND((sum(heap_blks_hit)::numeric / (sum(heap_blks_hit) + sum(heap_blks_read))) * 100, 2)

ELSE 0

END as heap_hit_ratio,

sum(idx_blks_read) as idx_read,

sum(idx_blks_hit) as idx_hit,

CASE

WHEN sum(idx_blks_hit) > 0 THEN

ROUND((sum(idx_blks_hit)::numeric / (sum(idx_blks_hit) + sum(idx_blks_read))) * 100, 2)

ELSE 0

END as idx_hit_ratio

FROM pg_statio_user_tables;

-- Hit ratio по базам

SELECT

datname,

blks_read,

blks_hit,

ROUND((blks_hit::numeric / (blks_hit + blks_read)) * 100, 2) as hit_ratio

FROM pg_stat_database

WHERE datname NOT LIKE 'template%';

2. Анализ использования shared_buffers:

-- Установиnm расширение если еще не установлено

CREATE EXTENSION IF NOT EXISTS pg_buffercache;

-- Топ-10 таблиц в кэше

SELECT

c.relname as table_name,

COUNT(*) * 8 / 1024 as cached_mb,

pg_size_pretty(pg_relation_size(c.oid)) as table_size,

ROUND(COUNT(*) * 100.0 / (SELECT setting::numeric FROM pg_settings WHERE name='shared_buffers'), 2) as percent_of_cache

FROM pg_buffercache b

JOIN pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)

WHERE c.relkind = 'r' -- только обычные таблицы

GROUP BY c.relname, c.oid

ORDER BY cached_mb DESC

LIMIT 10;

-- Распределение shared_buffers по типам данных

SELECT

CASE

WHEN usagecount IS NULL THEN 'Free'

ELSE usagecount::text

END as usage_count,

COUNT(*) * 8 / 1024 as mb,

ROUND(COUNT(*) * 100.0 / (SELECT setting::numeric FROM pg_settings WHERE name='shared_buffers'), 2) as percent

FROM pg_buffercache

GROUP BY usagecount

ORDER BY usagecount DESC NULLS FIRST;

3. Проверка временных файлов (переполнение work_mem):

SELECT

datname,

temp_files,

pg_size_pretty(temp_bytes) as temp_size,

ROUND(temp_bytes / 1024.0 / 1024.0 / NULLIF(temp_files, 0), 2) as avg_file_size_mb

FROM pg_stat_database

WHERE temp_files > 0;

-- Активные запросы, использующие временные файлы

SELECT

pid,

query,

temp_files,

temp_bytes

FROM pg_stat_activity

WHERE temp_files > 0 AND state = 'active';

4. Проверка текущих настроек PostgreSQL:

-- Критические настройки памяти

SELECT

name,

setting,

unit,

context

FROM pg_settings

WHERE name IN (

'shared_buffers',

'work_mem',

'maintenance_work_mem',

'effective_cache_size',

'wal_buffers',

'random_page_cost',

'effective_io_concurrency'

)

ORDER BY name;

⚙️ Часть 2: Оптимизация настроек

2.1. Оптимизация ОС Linux (требует прав root)

1. Создание оптимизированного профиля tuned:

# Создание директории для профиля

sudo mkdir -p /etc/tuned/postgresql-optimized

# Создание конфигурационного файла

sudo cat > /etc/tuned/postgresql-optimized/tuned.conf << 'EOF'

[main]

summary=Optimized for PostgreSQL with 8GB RAM, read-heavy workload

include=throughput-performance

[sysctl]

# Минимизация записи на диск (оптимизация для чтения)

vm.dirty_background_ratio = 2

vm.dirty_ratio = 5

vm.dirty_expire_centisecs = 6000

vm.dirty_writeback_centisecs = 1000

# Минимизация свопинга

vm.swappiness = 5

# Сохранение кэша dentry и inode (улучшение для частого чтения файлов)

vm.vfs_cache_pressure = 50

# Увеличение лимитов для большего количества соединений

fs.file-max = 2097152

EOF

# Активация профиля

sudo tuned-adm profile postgresql-optimized

sudo tuned-adm active # Проверка активации

2. Отключение Transparent Huge Pages:

# Немедленное отключение

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

# Постоянное отключение (для систем с systemd)

sudo cat > /etc/systemd/system/disable-thp.service << 'EOF'

[Unit]

Description=Disable Transparent Huge Pages

[Service]

Type=oneshot

ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag"

[Install]

WantedBy=multi-user.target

EOF

sudo systemctl daemon-reload

sudo systemctl enable disable-thp.service

sudo systemctl start disable-thp.service

3. Настройка лимитов памяти для пользователя postgres:

# Добавьте в /etc/security/limits.conf или создайте файл в /etc/security/limits.d/

sudo cat >> /etc/security/limits.conf << 'EOF'

postgres soft memlock 8388608 # 8GB в kB

postgres hard memlock 8388608

postgres soft nofile 65536

postgres hard nofile 65536

EOF

# Для применения в текущей сессии

sudo prlimit --pid $(pgrep -u postgres) --memlock=8388608:8388608

Рекомендации по изменению параметров ОС

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

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

Монтирование с опциями noatime,nodiratime

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

Noatime полностью отключает запись времени доступа к файлу. Эта опция подходит, если приложения не зависят от atime. Noatime может быть полезен в разделах с интенсивным чтением, где не важна совместимость с ПО, полагающимся на atime. Например, в каталогах статического контента, кэшах, медиабиблиотеках, снапшотах сборок.

Nodiratime отключает обновление времени доступа только для каталогов. Для остальных файлов время atime будет обновляться всегда. Отдельный nodiratime актуален только при желании тонко выключить обновление atime для каталогов, оставив его для файлов (редкий случай).

Настройка файловой системы /data - изменение параметров mount

1. Проверка текущих опций монтирования

# Текущее состояние

mount | grep/data

2. Определение UUID устройства (рекомендуется использовать UUID вместо пути устройства)

# Получить UUID устройства

blkid /dev/mapper/vg_data-LG_data

3. Резервное копирование текущего fstab

cp /etc/fstab /etc/fstab.backup_$(date +%Y%m%d)

4. Редактирование /etc/fstab

vi /etc/fstab

добавить

# /data

/dev/mapper/vg_data-LG_data /data ext4 defaults,noatime,nodiratime 0 0

5. Перемонтирование файловой системы

mount -o remount /data

6. Проверка применённых опций

# Проверить текущие опции монтирования

mount | grep/data

Важные замечания:

1. noatime vs relatime:

o noatime — полностью отключает обновление atime

o relatime (по умолчанию) — обновляет atime, только если mtime/ctime новее

o nodiratime — отключает atime только для директорий

2. Эффект от изменений:

o Уменьшение нагрузки на диск (меньше операций записи)

o Повышение производительности для workloads с частым чтением

o Некоторые приложения (например, backup-утилиты, использующие atime) могут работать некорректно

Итоговый отчет по анализу производительности подсистемы IO

1. Общая характеристика системы

• Период анализа: 06.01.2026 14:42 – 16:31 (около 2 часов)

• Основные устройства хранения:
  vdd (100 ГБ, монтирован в /data):
  Используется под нагрузку чтения и записи
  Наблюдается 100% утилизация (%util = 100)
  Высокие показатели w_await (до 13 мс)
  vdc (50 ГБ, монтирован в /wal):
  Преимущественно запись
  Утилизация 53–63%
  Низкое время отклика на запись (~1 мс)
  Другие диски: vda (система), vdb (лог)

• Тип нагрузки: OLAP-сценарий с преобладанием операций чтения над записью (соотношение ~3.36:1). Нагрузка не ограничена пропускной способностью дисков.

2. Критические проблемы производительности

1. 100% утилизация диска vdd в течение всего периода наблюдения.

2. Высокое время отклика на запись (w_await) на vdd:
   94.55% наблюдений превышают 5 мс
   Максимум до 13 мс

3. Большая длина очереди (aqu_sz) на vdd:
   Всегда > 1, достигает 31
   Указывает на перегруженность диска

4. Высокий cpu_wa (I/O wait):
   100% наблюдений > 10%
   Процессы в состоянии uninterruptible sleep превышают количество ядер CPU в 25–50% случаев

5. Неэффективное использование кэша:
   Высокая корреляция между cache и w/s на vdc (0.587)
   Слабая корреляция буферной памяти с операциями чтения/записи

3. Анализ корреляций и паттернов нагрузки

• Отрицательная корреляция wa и util на vdd (-0.3019) — свидетельствует о том, что высокий wa не всегда связан с загрузкой диска.

• Высокая корреляция операционной скорости с чтением блоков (0.7134) — производительность напрямую зависит от операций чтения с диска.

• Низкая/отрицательная корреляция скорости с IOPS и пропускной способностью — указывает, что узкое место не в подсистеме IO.

• Преобладание операций чтения (соотношение read/write = 3.36) — характерно для аналитических нагрузок.

4. Диагностика узких мест IO

Вывод по диагностике:
Основная проблема — высокое время отклика на запись на диске vdd и перегруженность очереди запросов. При этом общая производительность системы не ограничена пропускной способностью или IOPS, что указывает на иные узкие места: вероятно, недостаток RAM, неэффективные запросы или блокировки на уровне СУБД.

5. Рекомендации по оптимизации

1. Оптимизация диска vdd:
   Рассмотреть переход на более быстрые диски (SSD/NVMe)
   Разделить нагрузку: выделить отдельный диск для журналов транзакций

2. Оптимизация памяти:
   Увеличить размер буферного кэша СУБД
   Настроить shared_buffers и effective_cache_size в PostgreSQL

3. Оптимизация запросов:
   Провести анализ медленных запросов
   Добавить/оптимизировать индексы для уменьшения seq scan
   Использовать partitioning для больших таблиц

4. Настройка мониторинга:
   Включить детальный мониторинг процессов в состоянии D (uninterruptible sleep)
   Настроить оповещения при %util > 90% и w_await > 5 мс

5. Балансировка нагрузки:
   Рассмотреть использование реплик для чтения
   Возможно, увеличить количество ядер CPU для параллельной обработки запросов

6. Итоговый вывод по производительности IO

Подсистема IO находится в критическом состоянии по следующим причинам:

• Диск vdd постоянно перегружен (100% утилизация)

• Высокое время отклика на запись (до 13 мс)

• Длинная очередь запросов (до 31)

• Высокий I/O wait процессора (до 47%)

Однако основное узкое место — не в пропускной способности дисков, а в:

1. Неэффективном использовании памяти (слабая кэшируемость данных)

2. Большом количестве операций чтения с диска из-за неоптимальных запросов

3. Высокой загрузке CPU в состоянии ожидания IO

Рекомендуется:
Сначала провести оптимизацию на уровне СУБД и приложения (индексы, запросы, кэширование), а затем рассмотреть апгрейд дисковой подсистемы для диска vdd.

Сравнительные результаты: Эксперимент-5: Настройки кэширования и буферизации и Эксперимент-7: Оптимизация параметров файловой системы.

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

Среднее увеличение операционной скорости в ходе Эсперимента-7 по сравнению с Экпериментом-5 составило 7.47%.

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

IOPS

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

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

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

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

Сравнительный анализ производительности подсистемы IO: Эксперимент-5(Настройки кэширования и буферизации) и Эксперимент-7(Оптимизация параметров файловой системы).

1. Сравнение критических проблем производительности

• Общая проблема в обоих экспериментах: Производительность не ограничена подсистемой IO.

• Основные узкие места: CPU, блокировки, параметры параллелизма, ожидания СУБД.

• Статус аварийного оповещения: В обоих случаях зафиксирована отрицательная корреляция между операционной скоростью и IOPS/MB/s, что указывает на влияние не-IO факторов на производительность.

2. Сравнительный анализ корреляций и паттернов нагрузки

Вывод:

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

3. Диагностика метрик IO

3.1. r_await (среднее время чтения, мс)

• Эксперимент-5: стабильно ~2–4 мс.

• Эксперимент-7: стабильно ~2–5 мс.

• Изменение: Незначительный рост в эксперименте-7, но в пределах нормы.

3.2. w_await (среднее время записи, мс)

• Эксперимент-5: 3–12 мс, плавный рост.

• Эксперимент-7: 5–13 мс, более выраженный рост к концу теста.

• Изменение: Увеличение задержек записи в эксперименте-7, что может указывать на влияние оптимизаций ФС на операции записи.

3.3. aqu_sz (средняя длина очереди)

• Эксперимент-5: 8–29.

• Эксперимент-7: 13–31.

• Изменение: Увеличение длины очереди в эксперименте-7, что согласуется с ростом w_await.

3.4. proc_b (количество процессов в состоянии блокировки)

• Эксперимент-5: 5–13.

• Эксперимент-7: 4–13.

• Изменение: Незначительные колебания, без явной тенденции.

3.5. cpu_wa (%) (время ожидания CPU)

• Эксперимент-5: 42–47%.

• Эксперимент-7: 39–47%.

• Изменение: Снижение cpu_wa в эксперименте-7, что может указывать на улучшение использования CPU после оптимизации ФС.

3.6. Корреляция speed – IOPS

Отрицательная в обоих случаях, сильнее в эксперименте-7. Это подтверждает, что рост IOPS не ведёт к росту производительности, проблема в других подсистемах.

3.7. Корреляция speed – пропускная способность

Отрицательная, слабее, чем с IOPS. Пропускная способность диска не является ограничивающим фактором.

3.8. Другие показатели производительности IO

• IOPS: в эксперименте-7 немного выше (до 4346 vs 4293 в эксперименте-5).

• MB/s: стабильно ~39–43 MB/s в обоих экспериментах.

• Utilization: 100% в обоих случаях, что говорит о полной загрузке устройства.

3.9. Вывод по диагностике узких мест IO

• Эксперимент-5: Стабильные показатели IO, узкое место — CPU/блокировки.

• Эксперимент-7: Ухудшение w_await и aqu_sz, но улучшение cpu_wa. Оптимизация ФС привела к увеличению задержек записи, но снизила нагрузку на CPU.

4. Итоговый вывод по сравнению производительности IO в ходе экспериментов

1. Оба эксперимента подтверждают, что узкое место — не в подсистеме IO, а в CPU, блокировках или настройках СУБД.

2. Эксперимент-7 (оптимизация ФС) показал:

3. Увеличение задержек записи (w_await) и длины очереди (aqu_sz).

4. Снижение времени ожидания CPU (cpu_wa).

5. Более сильную отрицательную корреляцию speed-IOPS, что указывает на ещё меньшую зависимость производительности от IO.

6. Эксперимент-5 (настройки кэширования) демонстрирует более стабильные задержки IO, но более высокую нагрузку на CPU.

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

8. Продолжить оптимизацию CPU, параллелизма и настройки СУБД.

9. Для экспериментов с ФС рекомендуется дополнительная настройка параметров записи для снижения w_await.

10. Мониторинг блокировок и contention в СУБД.

Заключение:

Оба эксперимента успешно идентифицировали, что производительность упирается не в IO, а в другие компоненты системы. Оптимизация файловой системы (Эксперимент-7) частично улучшила использование CPU, но ухудшила задержки записи. Это указывает на необходимость комплексной настройки системы, учитывающей как параметры ФС, так и настройки СУБД и CPU.

В рамках проекта PG_EXPECTO по всесторонней оптимизации СУБД PostgreSQL был проведён цикл экспериментов по настройке подсистемы ввода-вывода. В ходе «Эксперимента-5» фокус сместился на тонкую настройку механизмов кэширования и буферизации операционной системы. Целью было оценить, как управление памятью для метаданных файловой системы может повлиять на общую производительность дисковой подсистемы в условиях аналитической (OLAP) нагрузки, где чтение данных преобладает над записью. Результаты оказались показательными: даже одна корректировка параметра vm.vfs_cache_pressure принесла ощутимое улучшение.

Рекомендации по изменению параметров ОС

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

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

vm.vfs_cache_pressure

Параметр в Linux, который контролирует склонность ядра к освобождению памяти, используемой для кэширования объектов VFS (Virtual File System). Влияет на баланс между кэшем страниц и кэшем метаданных файловой системы.

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

sysctl vm.vfs_cache_pressure

# sysctl vm.vfs_cache_pressure

vm.vfs_cache_pressure = 100

Изменение:

sysctl -w vm.vfs_cache_pressure=50

# sysctl -w vm.vfs_cache_pressure=50

vm.vfs_cache_pressure = 50

# sysctl vm.vfs_cache_pressure

vm.vfs_cache_pressure = 50

Основание:

Уменьшает давление на кэш dentry и inode, что может улучшить кэширование файловых операций.

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

Улучшение эффективности кэша, снижение нагрузки на дисковые операции чтения.

Итоговый отчет по анализу производительности подсистемы IO

Общая характеристика системы

• Период анализа: 2026-01-06 11:36 – 2026-01-06 13:25 (около 1 часа 50 минут)

• Основные устройства хранения:
  vdd (100 ГБ, LVM /data) – основное устройство данных
  vdc (50 ГБ, LVM /wal) – устройство для журналов
  vdb (30 ГБ, LVM /log) – логи
  vda (70 ГБ) – системный диск

• Тип нагрузки: OLAP-сценарий с преобладанием операций чтения над записью (соотношение ~3.24:1). Нагрузка на оба диска (vdd и vdc) высокая, с признаками очередей и ожиданий.

Критические проблемы производительности

1. Диск vdd перегружен:
   %util = 100% на протяжении всего периода
   w_await > 5 мс в 90.9% наблюдений
   aqu_sz (средняя длина очереди) > 1 в 100% наблюдений
   cpu_wa > 10% в 100% наблюдений

2. Диск vdc также показывает высокую загрузку:
   %util = 51–62% (всё время выше 50%)
   Запись стабильна, но загрузка высокая

3. Высокое соотношение чтения к записи (3.24:1) указывает на аналитическую нагрузку, требующую оптимизации кэширования и стратегий чтения.

Анализ корреляций и паттернов нагрузки

• Для vdd:
  Высокая положительная корреляция buff – r/s (0.899) и buff – wMB/s (0.806) – память неэффективно снижает нагрузку на диск.
  Отрицательная корреляция speed – IOPS (-0.593) – проблема не в IOPS, а в других подсистемах (CPU, блокировки).

• Для vdc:
  Слабая корреляция speed – IOPS (0.252) – IOPS не является узким местом.
  Отрицательная корреляция speed – MB/s (-0.115) – пропускная способность не ограничивает.

Вывод: Проблема производительности связана не с пропускной способностью или IOPS, а с задержками, очередями и, возможно, с настройками СУБД или CPU.

Диагностика узких мест IO

Вывод по диагностике узких мест IO:
Основное узкое место – высокие задержки записи и большая очередь на диске vdd, что приводит к ожиданию со стороны CPU (wa высокий). Проблема усугубляется неэффективным использованием памяти для буферизации.

Рекомендации по оптимизации

1. Оптимизация диска vdd:
   Рассмотреть переход на более быстрые диски (SSD/NVMe).
   Настроить параметры IO-планировщика (например, deadline или noop для SSD).
   Увеличить размер очереди (nr_requests).

2. Оптимизация памяти и кэширования:
   Увеличить shared_buffers (если это СУБД, например PostgreSQL).
   Настроить vm.dirty_ratio и vm.dirty_background_ratio для более эффективной записи.

3. Оптимизация запросов и схемы данных:
   Использовать индексы, секционирование, материализованные представления.
   Пересмотреть запросы с большим количеством чтений.

4. Мониторинг и дальнейший анализ:
   Следить за iowait, await, aqu_sz в реальном времени.
   Анализировать логи СУБД на предмет медленных запросов.

5. Для vdc:
   Мониторить утилизацию, при росте нагрузки – рассмотреть выделение более производительного диска.

Итоговый вывод по производительности IO

Текущее состояние: Критическое.
Диск vdd является основным узким местом – постоянная 100% загрузка, высокие задержки записи, большая очередь запросов. Это приводит к простою CPU в ожидании IO и снижению общей производительности системы.

Перспективы:
При оптимизации диска vdd, настроек памяти и запросов можно ожидать значительного улучшения производительности. Диск vdc работает в допустимом режиме, но требует наблюдения.

Рекомендуемые первоочередные действия:

1. Апгрейд vdd на SSD.

2. Настройка параметров кэширования и записи в ОС и СУБД.

3. Анализ и оптимизация наиболее ресурсоемких запросов.

*Отчет подготовлен на основе автоматизированного анализа метрик iostat/vmstat за период 06.01.2026 11:36–13:25.*

Сравнительные результаты: Эксперимент-3(Параметры IO-планировщика) и Эксперимент-5: Настройки кэширования и буферизации

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

Среднее увеличение операционной скорости в ходе Эсперимента-5 по сравнению с Экпериментом-3 составило 30.82%.

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

IOPS

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

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

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

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

Сравнительный анализ производительности подсистемы IO: Эксперимент-3(Параметры IO-планировщика) и Эксперимент-5: Настройки кэширования и буферизации

1. Сравнение критических проблем производительности

Вывод: В обоих экспериментах IO-подсистема не является узким местом. Проблема производительности связана с другими компонентами системы (CPU, блокировки, память).

2. Сравнительный анализ корреляций и паттернов нагрузки

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

3. Диагностика метрик IO

3.1 Задержки операций (латентности)

Наблюдение: Латентности операций чтения и записи находятся в приемлемых пределах в обоих экспериментах.

3.2 Очереди и блокировки

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

3.3 Загрузка CPU

Наблюдение: Высокий процент времени ожидания IO процессором в обоих экспериментах, что может указывать на неоптимальное взаимодействие CPU и IO.

3.4 Дополнительные показатели производительности IO

Наблюдение: Показатели IOPS и пропускной способности сопоставимы в обоих экспериментах. Время операций с блоками демонстрирует схожую динамику роста.

3.5 Вывод по диагностике узких мест IO

IO-подсистема не является ограничивающим фактором в обоих экспериментах по следующим причинам:

1. Низкие латентности операций чтения/записи

2. Отсутствие значимых корреляций между производительностью и метриками IO

3. Умеренные значения длины очереди и заблокированных процессов

4. Схожие показатели IOPS и пропускной способности в обоих экспериментах

4. Итоговый вывод по сравнению производительности IO в ходе экспериментов

1. Консистентность результатов: Оба эксперимента демонстрируют одинаковый основной вывод — IO-подсистема не является узким местом в системе.

2. Эффективность оптимизаций: Эксперимент 5 (с настройками кэширования и буферизации) показал:
   Незначительное улучшение latencies (особенно r_await)
   Слегка сниженные значения cpu_wa
   Сопоставимые основные показатели IOPS и пропускной способности

3. Рекомендации:
   Сфокусироваться на оптимизации CPU, устранении блокировок и настройке параллелизма
   Рассмотреть оптимизацию работы с памятью
   Провести детальный анализ времени выполнения запросов СУБД
   Настройки кэширования из эксперимента 5 можно считать успешными, но недостаточными для решения основной проблемы производительности

4. Общий вывод: Проблема производительности в обоих случаях связана с факторами вне IO-подсистемы. Оптимизации кэширования (эксперимент 5) дали незначительные улучшения, но не решили основную проблему, что подтверждает необходимость дальнейшего исследования CPU, блокировок и параметров параллелизма.

В мире высоконагруженных баз данных каждая миллисекунда ожидания ввода-вывода может стать узким местом всей системы. В поисках решения администраторы часто обращаются к настройке глубины очереди запросов к диску (nr_requests), надеясь одним параметром решить проблему высокой утилизации хранилища. Данный разбор на реальных метриках показывает, что вслепую увеличивать очередь не только бесполезно, но иногда и вредно. Когда диск постоянно работает на 100%, ключ к оптимизации лежит не в очереди, а в грамотном перераспределении нагрузки, стратегическом кэшировании и настройке планировщика операций ввода-вывода.

Запрос нейросети

Проанализируй показатели производительности IO и текущие значения для параметра nr_requests :"# cat /sys/block/vdd/queue/nr_requests

256". Подготовь рекомендации о целесообразности изменения параметра nr_requests для оптимизации подсистемы IO.

На основе анализа производительности IO для диска vdd, текущего значения nr_requests = 256 и контекста нагрузки, можно дать следующие рекомендации:

Текущее состояние (диск vdd):

1. Высокая загрузка диска:
   %util = 100% постоянно
   Средняя длина очереди (aqu_sz) от 11 до 29
   Большое количество процессов в состоянии uninterruptible sleep (6-14 при 8 CPU)

2. Характер нагрузки:
   Преобладание операций чтения над записью (соотношение ~3:1)
   OLAP-подобный сценарий с интенсивным чтением
   Высокая корреляция между объемом кэша и объемом чтения с диска

3. Проблемы:
   Чрезмерное ожидание IO процессором (wa = 45-51%)
   Глубина очереди постоянно > 1 (100% наблюдений)
   Признаки недостаточной эффективности кэширования

Рекомендации по nr_requests:

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

• Достаточно высокое для большинства рабочих нагрузок

• НЕ является основным ограничивающим фактором при текущей нагрузке

• Увеличение не решит проблему 100% утилизации

Рекомендуемые действия:

НЕ увеличивать nr_requests (256 → более высокие значения):

Текущая очередь и так переполнена (aqu_sz до 29)

Увеличение nr_requests не снизит %util = 100%

Может привести к:

• Увеличению латентности отдельных запросов

• Росту потребления памяти ядром

• Эффекту "застревания" старых запросов

Оптимизировать параметры планировщика (scheduler):

# Для OLAP-нагрузки с преобладанием чтения

echo deadline > /sys/block/vdd/queue/scheduler
# Настройки для deadline (опционально)
echo 256 > /sys/block/vdd/queue/iosched/read_expire
echo 5000 > /sys/block/vdd/queue/iosched/write_expire
echo 8 > /sys/block/vdd/queue/iosched/fifo_batch

Увеличить readahead для последовательных чтений:

# Текущее значение обычно 128 или 256
cat /sys/block/vdd/queue/read_ahead_kb
# Увеличить для OLAP
echo 4096 > /sys/block/vdd/queue/read_ahead_kb

Приоритетные оптимизации:
Увеличить кэширование (если возможно добавить RAM)
Оптимизировать запросы БД (индексы, уменьшение seq scan)
Рассмотреть разделение нагрузки на несколько дисков
Проверить настройки ФС (noatime, nodiratime)

Экспериментальная проверка (если решили изменить nr_requests):

#Временно уменьшить для теста
echo 128 > /sys/block/vdd/queue/nr_requests

# Мониторинг эффекта
iostat -x 1
cat /proc/interrupts | grep vdd

Вывод:

Параметр nr_requests = 256 не является узким местом.

Проблема :

1. Слишком высокой нагрузке на диск (OLAP + вероятно недостаток кэша)

2. Возможно, недостаточной производительности самого диска для текущей нагрузки

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

Сфокусироваться на:

1. Увеличении оперативной памяти для кэширования

2. Оптимизации запросов к базе данных

3. Рассмотрении более производительного хранилища (SSD/NVMe вместо HDD)

4. Настройке параметров планировщика и readahead

Изменение nr_requests даст минимальный эффект и может ухудшить ситуацию при текущей 100% утилизации диска.