Этот Linux не новогодний, но зато мой самый первый. 1999 год. На местном радиорынке натыкаюсь на красивую коробчонку с дистрибутивом BeOS. Как и все лини для домашнего пользования он был сырой, как могила. Но для работы с текстами, серфингу по сети и прочими нетривиальными задачами вполне подходил. Правда были нюансы. Например с бубном приходилось поплясать даже чтобы прикрутить русский язык (не к интерфейсу, а чтобы просто писать). Ну и приложений было раз-два и обчелся. Но по сравнению с вин-95 все равно это было свежо и приятно.
От хаоса к порядку: настройка Linux для рекордов СУБД
Данный чек-лист представляет собой структурированное руководство по оптимизации операционной системы 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).
ПРИОРИТЕТЫ И ПОРЯДОК ПРОВЕРКИ:
Сначала диагностика (пункты 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_*, выбору планировщика дисков и настройке свопа. Регулировка этих параметров позволяет избежать лавинообразных блокировок и сгладить пиковую нагрузку на дисковую подсистему.
Дополнительно рассматриваются настройки сетевого стека, ограничений процессов и файловой системы, что в комплексе обеспечивает стабильную и предсказуемую работу базы данных под высокой нагрузкой.
Все изменения требуют поэтапного внедрения, тестирования и учета особенностей среды (виртуализация, оборудование).
Привет! Меня зовут Нияз, и последние пять лет я веду, пожалуй, самый длинный и упорный личный проект в своей жизни создаю собственную макрос-клавиатуру с нуля: от логотипа до электроники и ПО.
Если коротко: я делаю устройство, которое экономит десятки минут в день тем, кто постоянно работает с графикой, фото, 3D или видео. Но путь к этой клавиатуре начался гораздо раньше.
Яндекс Еда — иконки фильтров основного экрана приложения сервиса доставки еды из ресторанов и продуктов из магазинов.
Я уже больше 11 лет занимаюсь рекламным дизайном и всем, что связано с производством визуального контента. За это время я стал настоящим «универсальным солдатом»:
могу снять продукт;
сделать 3D-визуализацию;
собрать макет;
отретушировать итог;
и настроить весь pipeline под задачу клиента.
Я работаю в Photoshop, Blender, Cinema 4D, After Effects, Premiere Pro, Capture One и ещё десятках программ.
И у всех у них одно общее — бесконечные горячие клавиши.
Работая по 6–10 часов ежедневно, я замечал две вещи:
я механически нажимаю одни и те же комбинации (Ctrl+Z, Ctrl+C, Ctrl+V, переключения инструментов и т. д.);
мизинец и запястье к концу дня просто болят.
Каждый дизайнер/ретушёр прекрасно понимает этот «пианизм»: бесконечный рояль из одинаковых нажатий, когда твои пальцы живут отдельной жизнью.
В какой-то момент я понял: я хочу удобный инструмент под свои задачи. И раз его нет — я сделаю его сам.
Так появилась идея собственной макрос-клавиатуры
первые экспериментальные бумажки, как примерно будет выглядеть и какого размера она будет
Я начал собирать прототипы, разрабатывать корпуса, тестировать кнопки, писать софт. И постепенно появилась та самая маленькая клавиатура, которая стоит рядом с основной и закрывает 80% рутинных действий.
Задачи, которые я решил:
вынести горячие клавиши на физические кастомные кнопки;
избавить пальцы от «рояля»;
ускорить повторяющиеся процессы;
уменьшить количество ненужных движений по клавиатуре.
Что под капотом устройства
Я начал собирать прототипы, разрабатывать корпуса, тестировать кнопки, писать софт. И постепенно появилась та самая маленькая клавиатура, которая стоит рядом с основной и закрывает 80% рутинных действий.
Задачи, которые я решил:
вынести горячие клавиши на физические кастомные кнопки;
избавить пальцы от «рояля»;
ускорить повторяющиеся процессы;
уменьшить количество ненужных движений по клавиатуре.
Что под капотом устройства
Сейчас клавиатура умеет:
одиночное нажатие
двойное нажатие
удержание
Мой инженер (человек-легенда, о котором расскажу отдельно) сделал плату с продуманной логикой работы. А я со своей стороны написал приложение для управления макросами, их переназначения и настройки задержек.
Стабильность работы — на уровне, которого иногда не дают даже топовые устройства вроде Logitech MX.
О чём я буду писать
этапы проектирования корпуса
ошибки и фейлы при создании устройства
UX/UI приложения
оптимизацию workflow
мягкий backstage: как я строю свой мини-стартап
Если вам интересен такой путь — присоединяйтесь
Подписывайтесь, ставьте реакции — это реально мотивирует продолжать вести этот проект и делать его лучше.
От кэша в памяти до планировщика CPU: полный путь к производительности
На основе экспериментальных данных и анализа представлено руководство по оптимизации ядра 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 нагрузки
Для нагрузок, где чтение сильно преобладает над записью (например, отчетные системы, аналитика), сделайте акцент на следующем:
Память и кэширование: Максимально увеличить shared_buffers (до 25-40% RAM), обязательно включите Huge Pages. Установите низкий vm.swappiness (1-10).
Планировщик процессов: Настроить kernel.sched_migration_cost_ns для лучшего распределения параллельных запросов. Установить регулятор CPU в performance.
Автоочистка (Autovacuum): Агрессивность может быть частично отключена, так как данные редко меняются. Это экономит CPU-циклы. Однако плановый VACUUM (например, по cron) в период низкой нагрузки необходим.
🛠️ Практические шаги по настройке
Проверка текущих значений: sysctl -a | grep <параметр> и tuned-adm active для просмотра текущей конфигурации.
Применение настроек:
Через tuned (рекомендуется для RHEL/CentOS): Создать пользовательский профиль, как в , и активировать его командой tuned-adm profile <имя_профиля>.
Через sysctl: Добавить параметры в файл /etc/sysctl.d/99-postgresql.conf и выполните sysctl -p.
Настройка Huge Pages: Рассчитать необходимое количество: (shared_buffers + другие затраты) / 2MB. Установитб через vm.nr_hugepages в sysctl и huge_pages = on в postgresql.conf.
Монтирование с noatime: Отредактировать /etc/fstab, добавив опции к разделу с данными, и перемонтировать (mount -o remount /path).
Увеличение лимитов ОС: Отредактировать файл /etc/security/limits.d/postgresql.conf и настроить службы в systemd (если используется).
Перезагрузка: Перезагрузить сервер для применения всех изменений, особенно связанных с Huge Pages и tuned.
Итог
Для PostgreSQL с нагрузкой, где преобладает чтение, критически важны настройки, уменьшающие латентность ввода-вывода и максимизирующие использование оперативной памяти под кэш.
Ключевые шаги: обязательное включение Huge Pages, увеличение shared_buffers, снижение swappiness, отключение ненужных обновлений атрибутов файлов (noatime), настройка планировщика процессов и регулятора CPU на режим производительности, а также увеличение системных лимитов. Агрессивность autovacuum может быть снижена для экономии ресурсов.
От latency — к velocity: как тонкая настройка IO разогнала PostgreSQL на 65%.
Часто при замедлении работы базы данных первым решением кажется увеличение вычислительных ресурсов: больше ядер, памяти, быстрые диски. Однако существует и другой, более экономичный путь — заглянуть глубже, на уровень операционной системы, управляющей этими ресурсами.
Данная статья — это практический разбор реального кейса, где скрупулёзная настройка параметров подсистемы ввода-вывода, кэширования и планировщика задач 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 на производительность СУБД
Сравнительный график изменения операционной скорости в ходе нагрузочного тестирования для Эксперимента-8(SPEED-8) и базовыми значениями параметров IO для Эксперимента-1(SPEED-1)
Среднее увеличение операционной скорости в результате применения изменений подсистемы IO по сравнению с базовыми значениями составило 65.09%.
Показатели производительности , ожиданий СУБД и метрик производительности IO в ходе экспериментов
Операционная скорость
График изменения операционной скорости в ходе экспериментов
Ожидания СУБД
График изменения ожидания СУБД в ходе экспериментов
IOPS
График изменения IOPS в ходе экспериментов
Пропускная способность (MB/s)
График изменения MB/s в ходе экспериментов
Длина очереди (aqu_sz)
График изменения aqu_sz в ходе экспериментов
Ожидание по чтению
График изменения r-await(ms) в ходе экспериментов
Ожидание по записи
График изменения w-await(ms) в ходе экспериментов
Итоговый вывод:
Систематическая оптимизация параметров подсистемы IO — таких как настройки кэширования, планировщика операций ввода-вывода и параметров файловой системы — позволила достичь значительного повышения производительности PostgreSQL.
Суммарный эффект от внесённых изменений выразился в среднем увеличении операционной скорости на 65,09% по сравнению с базовой конфигурацией. Наиболее существенный вклад внесли корректировки размера буферов предварительного чтения (read_ahead_kb) и отключение избыточного обновления временных меток файлов (noatime, nodiratime).
Результаты подтверждают - целенаправленная настройка окружения ОС является критически важным этапом развёртывания высоконагруженных СУБД.
Первый первый Pentium завелся дома, и решил я посмотреть, а что такое Линукс. И стал играться, пробовать разные программы (для сравнения с Вин95) и прочие развлекухи. И каким то чудом вышел на xsnow, и тут такое на экране - и елочки зеленые, и Санта на санях разъезжает, и снег сыпет на окошки (его еще и стряхивать можно было, если верно помню). И все это в реальном режиме.
Картинка не моя, взята с интернетов.
И тут я понял, Линукс мне нравиться!!! Всех с прошедшим Новым Годом, и с сегодняшним Рождеством!
Примерно так выглядит дефолтная консоль в Manjaro. Но вот в Linux Mint, например, она выглядит иначе, даже если установить и запустить zsh. Возникает вопрос: где именно хранятся настройки zsh? Какие файлы следует скопировать для переноса настроек?
Меньше — иногда значит быстрее: как оптимизация буфера чтения разгружает диск и ускоряет систему
В современных вычислительных системах операции ввода-вывода (I/O) часто становятся узким местом, ограничивающим общую производительность. Одним из ключевых параметров, влияющих на эффективность работы с дисковыми накопителями, является размер буфера предварительного чтения (read-ahead). Этот параметр определяет, сколько данных система заранее считывает с диска в память в ожидании последующих запросов. Хотя увеличение этого буфера может ускорить последовательные операции чтения, его неоптимальное значение способно привести к обратному эффекту — избыточной нагрузке на подсистему хранения, бесполезному расходованию пропускной способности и кэш-памяти.
В данной статье на реальном примере разбирается кейс анализа производительности блочного устройства vdd в Linux-системе, где наблюдалась 100% утилизация диска и высокие задержки. Мы детально исследуем метрики ввода-вывода, корреляции между ними и оценим целесообразность изменения параметра read_ahead_kb с текущего значения 4096 КБ. Материал будет полезен системным администраторам, DevOps-инженерам и всем, кто стремится глубже понять тонкости настройки ОС для максимизации отдачи от дисковой подсистемы.
Текущее значение
# cat /sys/block/vdd/queue/read_ahead_kb
4096
На основе анализа производительности IO для устройства vdd можно сделать следующие выводы и рекомендации:
Текущая ситуация с устройством vdd:
Утилизация диска (%util): постоянно 100% в течение всего периода наблюдения.
Задержки записи (w_await): в 94,55% наблюдений превышают 5 мс (ALARM).
Глубина очереди (aqu_sz): постоянно >1 (ALARM).
Соотношение чтения/записи: 3,36:1 (OLAP-сценарий, много операций чтения).
Средний размер запроса: Чтение (rareq_sz): ~9–10 КБ Запись (wareq_sz): ~10–11 КБ
Корреляция speed – IOPS: отрицательная (–0,7013), что указывает на не-IO-ограниченную систему (проблемы могут быть в CPU, блокировках, памяти).
Корреляция cache – r/s: отрицательная (–0,6421), что говорит об эффективности кэширования.
Параметр read_ahead_kb: текущее значение = 4096 (4 МБ).
Анализ целесообразности изменения read_ahead_kb:
✅ Аргументы за уменьшение значения:
Средний размер запроса на чтение всего ~10 КБ, а предзагрузка установлена на 4 МБ — это избыточно и может приводить к: Чтению лишних данных, которые не используются. Нагрузке на IO-подсистему без реальной пользы. Заполнению кэша ненужными данными, вытесняя полезные.
Высокая утилизация диска (100%) и большая глубина очереди указывают на то, что диск перегружен. Уменьшение read_ahead_kb может снизить избыточную нагрузку.
OLAP-сценарий (много чтения) — в таких случаях слишком большой read-ahead может мешать, если запросы случайные или не последовательные.
⚠️ Аргументы против уменьшения:
Если нагрузка в основном последовательное чтение больших файлов (например, обработка логов, дампов), то большой read-ahead может быть полезен.
Резкое уменьшение может увеличить количество 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
Мониторинг после изменения:
Сравнить r/s, rMB/s, r_await, %util до и после.
Проверить, не увеличилась ли глубина очереди (aqu_sz).
Оценить влияние на общую производительность (например, через vmstat, iostat).
Дополнительные рекомендации:
Исследовать другие узкие места: так как система не ограничена IO, стоит проверить: CPU (wa > 10% — ALARM). Память (использование кэша и буферов). Процессы в D состоянии (ожидание IO).
Оптимизировать запросы к СУБД: Увеличить shared_buffers (если PostgreSQL). Проверить наличие полных сканирований больших таблиц.
Рассмотреть возможность увеличения IOPS/пропускной способности диска (если это облачный диск — изменить тип на более производительный).
Заключение:
Изменение read_ahead_kb с 4096 на 256 КБ целесообразно, но должно проводиться осторожно, с мониторингом. Это может снизить избыточную нагрузку на диск, но не решит основную проблему — 100% утилизацию диска, которая требует более комплексного подхода (апгрейд диска, оптимизация запросов, увеличение кэша).
