Причины которые мешают играть и записывать видео на канал вы можете узнать посмотрев это видео.
00:01 — Введение
01:04 — Меры защиты которые применял
01:40 — Возможные предпосылки атаки вирусами Windows 11
03:22 — Как сохранил видео
04:17 — Описываю последствия атаки на операционную систему Windows 11
Подпишись и смотри ролики:
Правила Pikabu 1.4.5 запрещают публиковать ссылки однако это нарушает закон статья 10 Федерального закона от 26.07.2006 № 135-ФЗ "Запрет на злоупотребление хозяйствующим субъектом доминирующим положением"
Однажды решив запустить компьютер и включив свою любимую игру вдруг столкнетесь... Подпишись и смотри ролики:
Правила Pikabu 1.4.5 запрещают публиковать ссылки однако это нарушает закон статья 10 Федерального закона от 26.07.2006 № 135-ФЗ "Запрет на злоупотребление хозяйствующим субъектом доминирующим положением"
Стандартные рекомендации по влиянию параметра vm.swappiness на производительность СУБД PostgreSQL
Для OLAP-нагрузок в PostgreSQL рекомендуется установить vm.swappiness=1, чтобы минимизировать обращения к медленному диску и обеспечить стабильную производительность при обработке больших данных. Это заставит ядро использовать своп только в крайнем случае, сохраняя рабочие данные в оперативной памяти.
1. Текущая конфигурация памяти:
RAM: 8 GB
shared_buffers: 4 GB (50% от RAM - правильно настроено)
work_mem: 32 MB (адекватно для 22 сессий)
Остаётся для ОС: ~3.5-4 GB (учитывая кэш файловой системы)
2. Рекомендация: swappiness = 1 (лучший выбор)
Почему именно 1:
PostgreSQL интенсивно использует файловый кэш - для SELECT-нагрузки это критично
shared_buffers уже содержит "горячие" данные в управляемой памяти
Низкое значение предотвращает вытеснение кэша страниц ОС в своп
При нехватке памяти PostgreSQL сам управляет своими буферами через shared_buffers
Экспериментальная проверка влияния vm.swappiness=1 на производительность СУБД
Операционная скорость
Изменение операционной скорости СУБД в ходе нагрузочного тестирования
Среднее уменьшение операционной скорости в Эксперименте-2 (vm.swappiness = 1) составило 14.37%⚠️
Анализ причин снижения производительности СУБД PostgreSQL после применения vm.swappiness = 1
Рекомендация vm.swappiness=1 для PostgreSQL, которую часто дают нейросети и многие руководства, основана на общей логике: «меньше свопа — меньше обращений к диску — выше производительность». Однако эксперимент, описанный в статье «PG_EXPECTO 5.1: Влияние vm.swappiness=1 на производительность PostgreSQL», показывает, что в конкретных условиях эта настройка не дала ожидаемого эффекта. Вот ключевые причины, почему это произошло.
🔍 Суть эксперимента
Конфигурация: PostgreSQL 17, 8 ядер CPU, 8 ГБ RAM, shared_buffers=4 ГБ, нагрузка OLAP (аналитические запросы с большим объёмом чтения).
Сравнение: Производительность при vm.swappiness=10 и vm.swappiness=1.
Ожидание: Снижение своппинга должно уменьшить дисковый ввод-вывод и ускорить работу.
📊 Результаты
Диск - «узкое место»
Нагрузка на диск (/data) достигала 100% в обоих экспериментах. Высокая очередь запросов (aqu_sz) и время ожидания CPU для IO (cpu_wa >50%) указывали на то, что производительность упиралась в диск, а не в память.
Система избегала своппинга
Даже при swappiness=10 ядро Linux предпочитало вытеснять файловый кэш, а не отправлять данные в своп. Поэтому изменение параметра почти не повлияло на поведение подсистемы памяти.
Минимальное влияние на метрики vmstat
Разница между swappiness=10 и swappiness=1 оказалась статистически незначимой: не было существенных изменений в IOPS или пропускной способности. Небольшие улучшения (например, снижение w_await и глубины очереди) не решили основную проблему — перегруженность диска.
Общий результат
Проведенные эксперименты не подтвердили ожидаемого положительного влияния снижения параметра vm.swappiness на производительность PostgreSQL при интенсивной нагрузке с дефицитом оперативной памяти. Ключевым узким местом в обоих экспериментах стала производительность дисковой подсистемы.
🤔 Почему рекомендация нейросетей не подтвердилась?
Обобщённый характер рекомендаций
Нейросети (и многие руководства) опираются на общие принципы: «для OLAP-нагрузок снизьте swappiness, чтобы удержать данные в RAM». Однако они не учитывают конкретную конфигурацию и узкие места системы.
Условия эксперимента
Дисковая подсистема была перегружена (100% utilization), поэтому даже полное отключение свопа не могло улучшить общую производительность. Нехватка RAM (8 ГБ при shared_buffers=4 ГБ) приводила к вытеснению файлового кэша, а не к активному своппингу. Из-за этого изменение swappiness практически не меняло картину.
Контекстная зависимость
Эффект от vm.swappiness проявляется только когда система активно использует своп. Если же система избегает своппинга (как в эксперименте) или узким местом является диск, то настройка не даёт заметного выигрыша.
💡 Практические выводы
Не доверяйте слепо общим рекомендациям (в том числе от нейросетей)
Проверяйте их в своей среде.
Диагностируйте узкие места перед тонкой настройкой
Мониторьте iostat, vmstat, pg_stat_activity. Смотрите на %util, await, cpu_wa, aqu_sz.
Рассмотрите увеличение RAM для уменьшения нагрузки на диск.
vm.swappiness стоит снижать только когда
Наблюдается активный своппинг (si, so в vmstat).
Дисковая подсистема не является узким местом.
PostgreSQL работает с большим объёмом данных, которые должны оставаться в RAM.
Краткий сравнительный анализ производительности и ожиданий СУБД
Операционная скорость (SPEED)
Наклон линии регрессии скорости отрицательный в обоих случаях, но в Эксперименте-2 он круче (-26.99 против -23.65), что указывает на более быстрое снижение производительности.
Ожидания СУБД (WAITINGS)
Общий объем ожиданий и их рост во времени практически идентичны в обоих экспериментах (угол наклона ~43.6). В обоих случаях ожидания почти полностью (коэффициент корреляции ~1.0) состоят из ожиданий ввода-вывода (IO). Ключевое отличие: в Эксперименте-2 появилась умеренная корреляция ожиданий с IPC (0.86) и LWLock (0.86), которые в первом эксперименте были незначимы.
Типы ожиданий (Wait Events):
Основное событие ожидания в обоих случаях — DataFileRead (более 90% всех ожиданий типа IO). В Эксперименте-2 дополнительно зафиксированы ожидания типов IPC (BufferIo) и LWLock (XidGen, BufferContent), что отсутствовало в первом эксперименте.
Подробный сравнительный анализ метрик vmstat и выводы по метрикам
procs_r (процессы в run queue)
Одинаково низкие значения (1-3) в обоих экспериментах. Очередь на выполнение не является проблемой.
procs_b (процессы в uninterruptible sleep)
Явная проблема в обоих случаях. Количество процессов, заблокированных в ожидании IO, стабильно растет на протяжении всего теста. В Эксперименте-1 значение выросло с 5 до 16. В Эксперименте-2 значение выросло с 5 до 14. Более 40% наблюдений в обоих тестах — количество заблокированных процессов превышает число ядер CPU (8), что подтверждает серьезные проблемы с подсистемой IO.
memory_swpd (используемый объем свопа)
Эксперимент-1: Незначительный рост с ~220 до ~224 МБ. Эксперимент-2: Заметный рост с ~205 до ~217 МБ. Хотя объем мал, тенденция к увеличению при swappiness=1 присутствует.
swap_si / swap_so (свопин/аут)
В обоих экспериментах равен 0. Активный свопинг не наблюдался.
memory_free (свободная RAM)
Критически низкий показатель в обоих экспериментах (~130 МБ из 7.5 ГБ, что составляет менее 2%). 100% наблюдений — свободной памяти менее 5%. Система работает на пределе доступной оперативной памяти.
memory_buff / memory_cache (буферы и кеш)
Стабильно высокие значения (кеш ~7 ГБ) в обоих тестах. ОС активно использует свободную память для кеширования дисковых операций, что является нормальным поведением.
io_bi / io_bo (блоки ввода/вывода)
Чрезвычайно высокие значения в обоих экспериментах (bi: с ~26k до ~32k; bo: с ~17k до ~20k). Наблюдается очень сильная корреляция (>0.87) этих показателей с ожиданиями IO в СУБД. Это подтверждает, что СУБД является основным источником нагрузки на дисковую подсистему.
Значения стабильны и сопоставимы в обоих тестах. Существенных аномалий не выявлено.
cpu_us / cpu_sy / cpu_id / cpu_wa (распределение времени CPU)
cpu_wa (время ожидания IO):Основная проблема. В обоих экспериментах занимает 50-70% времени CPU, что указывает на то, что процессор простаивает в ожидании операций дискового ввода-вывода.
cpu_id (время простоя):Снижается с ~33% в начале до ~10-13% в конце тестов, так как процессор все больше времени ждет IO.
cpu_us / cpu_sy (пользовательское/системное время):Остаются стабильно низкими (11-12% / 4-5%), что означает отсутствие нагрузки на вычислительные ресурсы со стороны приложения или ядра ОС. CPU не является узким местом.
Ключевые отличия метрик vmstat, влияющих на итоговую производительность СУБД
Динамика memory_swpd
При vm.swappiness=1 наблюдается более выраженный рост использования области свопа (с 205 до 217 МБ), в то время как при значении 10 рост был минимальным (с 220 до 224 МБ). Это указывает на то, что даже при низком значении параметра система под давлением нехватки памяти была вынуждена начать использовать своп.
Уровень procs_b
В конце теста при swappiness=10 было зафиксировано 16 заблокированных процессов, а при swappiness=1 — 14. Хотя разница невелика, в сочетании с другими метриками это указывает на схожую, но несколько менее выраженную пиковую нагрузку на IO во втором эксперименте.
Анализ причин снижения производительности при vm.swappiness=1
Основная (общая) причина
В обоих экспериментах основная причина снижения производительности — критическая нехватка оперативной памяти для рабочего набора данных СУБД. Это приводит к: Чрезмерной нагрузке на дисковую подсистему (очень высокие io_bi/io_bo, cpu_wa >50%). Росту числа процессов, заблокированных на операциях ввода-вывода (procs_b). Прямой зависимости скорости работы СУБД от скорости чтения с диска (корреляция speed и shared_blks_read >0.97).
Специфическое влияние vm.swappiness=1
Установка параметра в 1 должна минимизировать использование свопа. Однако при тотальной нехватке памяти система все равно была вынуждена начать использовать swpd, хотя и менее активно, чем при значении 10.
Более важное следствие: Жесткая политика удержания данных в RAM при ее катастрофической нехватке привела к усилению конкуренции за ресурсы памяти между процессами СУБД. Это выразилось в появлении в Эксперименте-2 дополнительных ожиданий, связанных с легковесными блокировками (LWLock) и межпроцессным взаимодействием (IPC), которые отсутствовали в первом тесте. Данные блокировки являются внутренними для PostgreSQL и возникают при конкуренции за доступ к разделам общей памяти. Их появление свидетельствует о том, что нехватка памяти начала негативно влиять не только на IO, но и на внутреннюю координацию процессов СУБД.
Итог
При vm.swappiness=1 на фоне той же фундаментальной проблемы (нехватка RAM → лавина IO) дополнительно возникла внутренняя contention (конкуренция) в СУБД из-за борьбы за scarce (дефицитную) оперативную память. Это привело к более быстрому и глубокому падению операционной скорости (SPEED) по сравнению с Экспериментом-1, где система могла немного "разгрузить" RAM в своп, потенциально смягчая пиковое давление на shared buffers и внутренние структуры PostgreSQL.
⚖️ Почему swappiness=10 работал лучше
Более сбалансированный подход
При swappiness=10 система могла немного своппингуть неактивные фоновые процессы Это сохраняло больше файлового кэша для активных операций PostgreSQL
Оптимизация под конкретную нагрузку
OLAP-запросы (70% SELECT) требуют много последовательных чтений Файловый кэш ОС критически важен для повторных чтений одних и тех же данных Сохранение этого кэша дало больше преимуществ, чем экономия на своппинге
📈 Основной итог экспериментов:
Нет универсальных настроек
То, что работает для OLTP, может вредить OLAP
Важен контекст bottlenecks:
Если узкое место - диск (как в эксперименте), сохраняйте кэш любой ценой Если узкое место - память, можно снижать swappiness
Мониторинг обязателен
Без метрик vmstat и iostat нельзя понять реальный эффект
Послесловие
Главный вывод этого исследования прост: не существует универсальных настроек. Производительность PostgreSQL зависит от конкретной конфигурации, нагрузки и узких мест системы. Прежде чем применять рекомендации, проведите тесты в своей среде и опирайтесь на метрики, а не на советы из чатов.
Миф о swappiness: когда рекомендация не работает на практике.
Настоящее исследование посвящено экспериментальной проверке общепринятой рекомендации по снижению параметра vm.swappiness для серверов PostgreSQL . В ходе нагрузочного тестирования на синтетической рабочей нагрузке, имитирующей аналитические запросы, было оценено влияние значений vm.swappiness = 10 и vm.swappiness = 1 на производительность СУБД и инфраструктуры. Результаты выявили неожиданные закономерности, ставящие под сомнение универсальность данной рекомендации.
В статье представлены результаты нагрузочного тестирования PostgreSQL на синтетической рабочей нагрузке, имитирующей аналитические запросы (OLAP). Цель исследования: определить - как снижение параметра vm.swappiness влияет на взаимодействие СУБД с подсистемой ввода-вывода Linux.
Теоретическая часть
🎯 Влияние vm.swappiness на OLAP в PostgreSQL
Высокое значение (например, 60 по умолчанию):
Эффект: Ядро активно выгружает данные в своп, даже если физическая память не исчерпана.
Влияние на OLAP: Это может привести к "трешингу" (thrashing) — постоянному обмену данными между RAM и диском. Для OLAP-запросов, которые сканируют огромные наборы данных, это означает катастрофическое падение производительности, так как система тратит время на ввод-вывод, а не на обработку.
Низкое значение (например, 1-10):
Эффект: Ядро свопирует данные, только когда свободной оперативной памяти практически не осталось. Кэш PostgreSQL (например, shared_buffers) и данные для больших запросов с большей вероятностью останутся в быстрой RAM.
Влияние на OLAP: Это обеспечивает стабильность для длительных аналитических операций, минимизируя риск внезапных задержек из-за подкачки с диска. Однако слишком низкое значение (0) может привести к неожиданному завершению процесса (OOM Kill) при резком росте нагрузки.
⚙️ Рекомендации по настройке для OLAP
Для серверов PostgreSQL, ориентированных на OLAP-нагрузку, общепринятая рекомендация — снизить значение vm.swappiness.
Базовое значение: Установите vm.swappiness=1 для минимального использования свопа, но не полного его отключения.
Альтернатива: В некоторых продакшен-сценариях, особенно на системах с большим объемом RAM, используют значение vm.swappiness=10 как баланс между стабильностью и гибкостью.
Важное предупреждение: Значение 0 использовать не рекомендуется, так как это может дестабилизировать систему и спровоцировать агрессивное действие OOM Killer (механизма, который завершает процессы при нехватке памяти).
📝 Как применить настройку
Настройка производится через файл /etc/sysctl.conf (для постоянного изменения) или через интерфейс sysctl.
Измените значение (временно, до перезагрузки): sudo sysctl -w vm.swappiness=1
Сделайте изменение постоянным. Добавьте или измените строку в файле /etc/sysctl.conf vm.swappiness=1
После сохранения файла примените изменения: sudo sysctl -p /etc/sysctl.conf
🔍 Дополнительные соображения для OLAP
Настройка vm.swappiness — лишь одна часть оптимизации памяти для OLAP. Не менее важны:
Достаточный объем RAM: Ключевой фактор для OLAP. Данные должны помещаться в оперативную память для максимальной скорости.
Параметры PostgreSQL: Увеличьте shared_buffers (до 25-40% от RAM) для кэширования данных и work_mem для сложных сортировок и агрегаций.
Мониторинг: Следите за метриками swap in/out (например, через vmstat 1) и кэш-попаданий в PostgreSQL, чтобы убедиться в эффективности настроек.
💎 Итог
Для OLAP-нагрузок в PostgreSQL рекомендуется установить vm.swappiness=1, чтобы минимизировать обращения к медленному диску и обеспечить стабильную производительность при обработке больших данных. Это заставит ядро использовать своп только в крайнем случае, сохраняя рабочие данные в оперативной памяти.
Практическая часть: Экспериментальная проверка влияния vm.swappiness=1
Важное изменение в версии 5.1⚠️
Изменены тестовые сценарии scenario-2 и scenario-3.
Веса тестовых сценариев и параметры нагрузочного тестирования
# Веса сценариев по умолчанию
scenario1 = 0.7
scenario2 = 0.2
scenario3 = 0.1
Измененные параметры операционной системы ⚠️
1️⃣Общие параметры производительности
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
2️⃣Параметры IO-планировщика
[mq-deadline] kyber bfq none
3️⃣Настройки кэширования и буферизации
vm.vfs_cache_pressure = 50
4️⃣Оптимизация параметров файловой системы
/dev/mapper/vg_data-LG_data on /data type ext4 (rw,noatime,nodiratime)
5️⃣Изменение размера буферов для операций с блочными устройствами
read_ahead_kb = 256
Нагрузка на СУБД в ходе экспериментов
Изменение vm.swappiness
Текущее значение
# cat /proc/sys/vm/swappiness
10
Изменение значения
# sysctl -w vm.swappiness=1
vm.swappiness = 1
# vi /etc/sysctl.conf
vm.swappiness = 1
# sysctl -p /etc/sysctl.conf
vm.swappiness = 1
Контроль изменения
# cat /proc/sys/vm/swappiness
1
Эксперимент-1 ( vm.swappiness = 10 )
Эксперимент-2 (vm.swappiness = 1)
Корреляционный анализ производительности и ожиданий СУБД
Операционная скорость
Изменение операционной скорости СУБД в ходе нагрузочного тестирования
Среднее уменьшение операционной скорости в Эксперименте-2 (vm.swappiness = 1) составило 14.37%
Ожидания СУБД
Изменение ожиданий СУБД в ходе нагрузочного тестирования
Среднее увеличение ожиданий в Эксперименте-2 (vm.swappiness = 1) составило 1.03%
Производительность подсистемы IO
Важно - главный предварительный итог
Изменение параметра vm.swappiness = 1 практически не оказывает влияния на метрики производительности подсистемы IO.
IOPS (Производительность IO)
Изменение производительности IO(IOPS) в ходе нагрузочного тестирования
Эксперимент 1: Начальная скорость выше (~611 850). Наблюдается выраженный отрицательный тренд (угол наклона -23.65). Скорость снижается на ~26% к концу теста.
Эксперимент 2: Начальная скорость ниже (~500 504). Отрицательный тренд также присутствует (угол наклона -26.99), но абсолютное падение скорости меньше (~7%).
Вывод: В условиях эксперимента снижение swappiness не привело к улучшению максимальной пропускной способности, однако общее относительное падение производительности под нагрузкой было менее выраженным.
Ожидания СУБД (WAITINGS):
Оба эксперимента демонстрируют: Сильный и стабильный рост ожиданий во времени (R² ~0.91, угол наклона ~43.6). Практически полную корреляцию общих ожиданий с ожиданиями типа IO (WAITINGS - IO = 1.000). 80% и более всех ожиданий приходятся на операцию DataFileRead.
Ключевое различие: Эксперимент 1: Ожидания коррелируют с IPC (межпроцессное взаимодействие) и LOCK отрицательно или слабо. Эксперимент 2: Появилась заметная положительная корреляция ожиданий с IPC (0.86) и LWLOCK (0.86), что указывает на возросшую конкуренцию за легковесные блокировки и буферы в памяти.
Сравнение метрик инфраструктуры (vmstat) и их корреляция с СУБД
Загрузка CPU и очередь процессов:
Оба эксперимента: Нагрузка на CPU (us + sy) не является проблемой (низкие значения, нет превышения 80%). Очередь исполняемых процессов (procs_r) не превышает количество ядер CPU. Высокий процент времени ожидания ввода-вывода (cpu_wa): 50-71% в Эксперименте 1, 51-69% в Эксперименте 2.
Различия: Существенных различий в метриках CPU между экспериментами не выявлено.
Дисковый ввод-вывод (IO):
Оба эксперимента показывают идентичные проблемы: ALARM: Очень высокая корреляция ожиданий СУБД типа IO с cpu_wa (~0.94) и procs_b (~0.98). Это указывает, что процессы СУБД массово переходят в состояние непрерываемого сна (D) из-за ожидания ответа от диска. ALARM: Количество процессов в состоянии D (procs_b) стабильно растет и в пике превышает количество ядер CPU в 2 раза. ALARM: Соотношение читаемых блоков к записываемым высокое (>2.7), что подтверждает read-intensive (OLAP) характер нагрузки. ALARM: Прямая сильная корреляция операционной скорости СУБД с количеством прочитанных с диска блоков (~0.97). Производительность напрямую упирается в скорость чтения с диска.
Вывод: Параметр swappiness не оказал влияния на профиль и тяжесть проблем с дисковым IO. Система упирается в пределы производительности дисковой подсистемы.
Память (RAM):
Общая картина в обоих экспериментах: ALARM: Свободная оперативная память (memory_free) практически отсутствует (<5% на протяжении >50% наблюдений). OK: Своппинг (swap_si, swap_so) не использовался, несмотря на нехватку свободной RAM. Значительный объем памяти используется для кэша файловой системы (memory_cache >7 GB).
Ключевой вывод: Даже при swappiness=10 система не прибегала к своппингу. Нехватка свободной RAM, по всей видимости, компенсировалась активным вытеснением файлового кэша, что усугубляло проблему с дисковым IO, заставляя чаще читать данные с диска.
Итоговый вывод о влиянии vm.swappiness
Для данной конкретной конфигурации (8 CPU, 7.5 GB RAM) и предоставленного характера нагрузки (интенсивное чтение, вызывающее дефицит свободной оперативной памяти):
Отсутствие влияния на своппинг: Изменение параметра vm.swappiness с 10 на 1 не привело к качественному изменению поведения системы. В обоих случаях система предпочла не использовать раздел подкачки, даже в условиях хронической нехватки свободной оперативной памяти.
Несущественное влияние на производительность СУБД: Не было зафиксировано значимого улучшения или ухудшения итоговой операционной скорости (SPEED) СУБД. Основная проблема производительности в обоих экспериментах была одинакова и заключалась в дисковом вводе-выводе, который стал узким местом.
Изменение профиля конкуренции: Снижение swappiness до 1 привело к появлению статистически значимой корреляции ожиданий СУБД с IPC и LWLOCK. Это косвенно свидетельствует о том, что при более жестком ограничении на использование свопа процессы СУБД активнее конкурировали за структуры данных в оперативной памяти (буферы, легковесные блокировки), однако это не стало новым узким местом по сравнению с дисковым IO.
Общий вывод:
В рамках проведенных экспериментов с интенсивной нагрузкой, вызывающей дефицит оперативной памяти, параметр vm.swappiness не оказал решающего влияния на общую производительность системы и СУБД PostgreSQL. Основным лимитирующим фактором в обоих случаях была производительность дисковой подсистемы. Система в обоих конфигурациях избегала своппинга, выбирая стратегию вытеснения файлового кэша, что лишь усиливало нагрузку на диски. Изменения в поведении СУБД были минимальны и не повлияли на ключевую проблему производительности.
Анализ производительности IO для файловой системы /data
Сравнительный отчет по производительности подсистемы IO для файловой системы /data
Общая характеристика системы
Аппаратная конфигурация: CPU: 8 ядер (x86_64) RAM: 7.5 GB Диск для /data: vdd → vg_data-LG_data (99 GB LVM)
Критические проблемы производительности по файловой системе /data
Загрузка диска (utilization): 100% в 100% наблюдений в обоих экспериментах
Очередь запросов (aqu_sz): постоянно превышает 1 (100% наблюдений)
Ожидание CPU для IO (cpu_wa): стабильно >50% (в 100% наблюдений)
Процессы в состоянии ожидания IO (proc_b): регулярно превышают количество ядер CPU (25-50% наблюдений)
Соотношение чтения/записи: ~2.9:1 (OLAP-сценарий)
Анализ корреляций и паттернов нагрузки по файловой системе /data
Высокая корреляция cpu_wa и util: 0.94 (Эксп.1) и 0.87 (Эксп.2) — процессы ждут диск
Отрицательная корреляция cache с операциями чтения/записи: эффективное использование кэша
Высокая корреляция скорости операций с shared_blks_read: 0.97 — производительность напрямую зависит от чтения с диска
Слабые/отрицательные корреляции с IOPS и MB/s: производительность не ограничена пропускной способностью или IOPS
Диагностика узких мест IO по файловой системе /data
Сравнение метрик между экспериментами:
r_await(ms): Эксп.1: 1-5 мс (MIN: 1.47, MAX: 5.12) Эксп.2: 1-6 мс (MIN: 1.47, MAX: 5.68) Изменение: незначительное увеличение максимума во втором эксперименте
w_await(ms): Эксп.1: 1-15 мс (MIN: 1.63, MAX: 14.91) Эксп.2: 1-5 мс (MIN: 1.63, MAX: 4.49) Изменение: значительное улучшение во втором эксперименте
proc_b (процессы в uninterruptible sleep): Оба эксперимента: регулярно превышают количество ядер CPU Эксп.1: 42.99% наблюдений с превышением Эксп.2: 42.73% наблюдений с превышением Изменение: минимальное улучшение
cpu_wa(%) (время ожидания CPU для IO): Эксп.1: 50-71% Эксп.2: 51-69% Изменение: незначительное снижение диапазона
Диск /data является узким местом в обоих экспериментах
Высокая загрузка диска (100%) приводит к образованию очереди запросов
Процессы проводят значительное время в ожидании IO (cpu_wa >50%)
Характер нагрузки: OLAP с преобладанием операций чтения
Проблема не в пропускной способности диска или IOPS
Итоговый вывод о влиянии параметра vm.swappiness
Минимальное влияние на ключевые метрики: изменение vm.swappiness с 10 на 1 не привело к существенному изменению производительности подсистемы IO
Незначительные улучшения во втором эксперименте: Снижение максимального времени ожидания записи (w_await) Уменьшение максимальной глубины очереди запросов (aqu_sz) Небольшое снижение времени ожидания CPU для IO (cpu_wa)
Проблема перегруженности диска сохраняется: в обоих экспериментах наблюдается 100% загрузка диска и высокая очередь запросов
Характер нагрузки определяет производительность: сценарий с высоким соотношением чтения/записи создает устойчивую нагрузку на диск, которая не может быть компенсирована настройками swappiness в данных условиях
Результат согласуется с анализом корреляций: в обоих экспериментах выявлено, что узкое место не в IOPS или пропускной способности, а в самой загрузке диска, что делает изменение vm.swappiness неэффективным для решения основной проблемы
Итог
Проведенные эксперименты не подтвердили ожидаемого положительного влияния снижения параметра vm.swappiness на производительность PostgreSQL при интенсивной нагрузке с дефицитом оперативной памяти.
Основные выводы:
Изменение параметра не привело к качественному изменению поведения подсистемы памяти: система в обоих случаях избегала своппинга, предпочитая вытеснять файловый кэш.
Не было зафиксировано значимого улучшения или ухудшения итоговой операционной скорости СУБД. Ключевым узким местом в обоих экспериментах стала производительность дисковой подсистемы.
Снижение vm.swappiness до 1 привело лишь к косвенному изменению профиля конкуренции за ресурсы в памяти, но это не повлияло на общую картину производительности, ограниченную вводом-выводом.
Для подсистемы IO изменение параметра также не оказало существенного влияния: проблема 100% загрузки диска и высокой очереди запросов сохранилась при обоих значениях.
Общий вывод:
В условиях конкретной тестовой конфигурации (интенсивное чтение, нехватка RAM, ограниченная дисковая производительность) рекомендация по снижению vm.swappiness для оптимизации нагрузки в PostgreSQL не нашла экспериментального подтверждения. Производительность системы определялась другими факторами.
От дисковых ожиданий к кэшированию: как shared_buffers меняет игру.
Данный отчёт суммирует результаты сравнительного нагрузочного тестирования СУБД PostgreSQL с использованием комплекса pg_expecto 5.1. Целью экспериментов была объективная оценка влияния ключевого параметра памяти — shared_buffers — на производительность базы данных и метрики инфраструктуры, в первую очередь подсистемы ввода-вывода. Тестирование имитировало смешанную OLAP-нагрузку с преобладанием операций чтения на идентичных конфигурациях, где единственной переменной был размер буферного кэша (1 ГБ в первом эксперименте и 4 ГБ во втором).
Задача
Провести сравнительный анализ влияния размера shared_buffers на производительность СУБД PostgreSQL и подсистемы IO для версии pg_expecto 5.1.
Важное изменение в версии 5.1⚠️
Изменены тестовые сценарии scenario-2(INSERT) и scenario-3(UPDATE).
Веса тестовых сценариев и параметры нагрузочного тестирования
# Веса сценариев по умолчанию
scenario1 = 0.7
scenario2 = 0.2
scenario3 = 0.1
Измененные параметры операционной системы для оптимизации⚠️
1️⃣Общие параметры производительности
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
2️⃣Параметры IO-планировщика
[mq-deadline] kyber bfq none
3️⃣Настройки кэширования и буферизации
vm.vfs_cache_pressure = 50
4️⃣Оптимизация параметров файловой системы
/dev/mapper/vg_data-LG_data on /data type ext4 (rw,noatime,nodiratime)
5️⃣Изменение размера буферов для операций с блочными устройствами
read_ahead_kb = 256
Нагрузка на СУБД в ходе экспериментов
Корреляционный анализ производительности и ожиданий СУБД
Операционная скорость
Изменение операционной скорости СУБД в ходе нагрузочного тестирования
Среднее увеличение операционной скорости в Эксперименте-2 (shared_buffers=4GB) составило 70.76%
Ожидания СУБД
Изменение ожиданий СУБД в ходе нагрузочного тестирования
Среднее уменьшение ожиданий в Эксперименте-2 (shared_buffers=4GB) составило 12.97%
Производительность подсистемы IO
IOPS (Производительность IO)
Изменение производительности IO(IOPS) в ходе нагрузочного тестирования
Среднее увеличение производительности IO в Эксперименте-2 (shared_buffers=4GB) составило 4.28%
MB/s (Пропуская способность IO)
Изменение пропуской способности IO(MB/s) в ходе нагрузочного тестирования
Среднее уменьшение пропускной способности IO в Эксперименте-2 (shared_buffers=4GB) составило 5.23%
Итоговый вывод о влиянии shared_buffers
Для производительности СУБД:
Увеличение shared_buffers с 1GB до 4GB привело к значительному росту операционной скорости (до +63.4% в пике)
Минимальная производительность улучшилась на 39.5%
Изменилась динамика производительности: с положительного тренда на отрицательный при увеличении нагрузки
Преобразовало зависимость между скоростью и ожиданиями с прямой на обратную
Для инфраструктуры:
Снизило процент времени, когда процессы в состоянии D превышали количество ядер CPU (с 56.48% до 42.99%)
Не устранило проблему высокой корреляции между ожиданиями IO и метриками wa/b
Не повлияло на использование оперативной памяти (в обоих случаях активно используется)
Для характера нагрузки (OLAP-сценарий):
Уменьшило общее количество операций чтения с диска на 11.6%
Изменило распределение ожиданий между основными запросами
Преобразовало зависимость производительности от операций записи с прямой на обратную
Общий эффект
Параметр shared_buffers = 4GB показал существенно лучшие результаты для данной конфигурации и характера нагрузки, позволив эффективнее кэшировать данные в памяти и снизив зависимость производительности от операций ввода-вывода, что особенно критично для OLAP-сценариев с преобладанием операций чтения.
Увеличение параметра shared_buffers с 1 ГБ до 4 ГБ привело к значительному качественному изменению в поведении системы под нагрузкой.
Для СУБД: Производительность (операционная скорость) выросла на 39.5–63.4%, а зависимость между скоростью и ожиданиями ввода-вывода трансформировалась с прямой на обратную. Количество обращений к диску для чтения сократилось на 11.6%.
Для инфраструктуры: Нагрузка на подсистему ввода-вывода осталась критически высокой, однако уменьшилось количество процессов, блокированных в ожидании диска, и улучшилось среднее время отклика на операции чтения (r_await).
Общий эффект: Более крупный буферный кэш эффективнее обслуживал OLAP-составляющую нагрузки, кэшируя данные и снижая давление на диск. Это сместило узкие места системы: если при shared_buffers=1GB производительность жёстко зависела от характеристик диска (IOPS и пропускной способности), то при shared_buffers=4GB эта зависимость ослабла, хотя диск по-прежнему оставался полностью загруженным.
