Нейросети стремительно входят в повседневную практику разработчиков и администраторов баз данных, обещая революцию в оптимизации и автоматизации. Но насколько можно доверять их рекомендациям в сложных, высоконагруженных системах? На основе актуальных экспериментов 2025-2026 годов мы разбираем, как ИИ меняет работу с PostgreSQL, где он действительно полезен, а где его «категоричные» советы приводят к падению производительности на сотни процентов. Это не статья о страхах, а руководство по эффективному и безопасному использованию нового инструментария.
https://dzen.ru/a/aWh4NtBUtEXvCn5n

Статья посвящена результатам комплексного анализа производительности системы после внесения изменений в тестовые сценарии и настройки окружения в версии 5.1. Основное внимание уделено выявлению узких мест под нагрузкой, в особенности — критическим проблемам ввода-вывода (I/O), которые стали определяющим фактором ограничения производительности СУБД.
https://dzen.ru/a/aWjJq9NfDEv1sYPy

Статья посвящена анализу производительности системы на основе PostgreSQL в условиях нагрузочного тестирования, для увеличенного значения shared_buffers = 4GB. Основное внимание уделено выявлению узких мест в подсистемах ввода-вывода (I/O) и памяти, а также их влиянию на общую производительность СУБД. Результаты анализа служат основой для формирования конкретных рекомендаций по оптимизации инфраструктуры и конфигурации базы данных.
https://dzen.ru/a/aWji0yeSdXr5h1o-

От дисковых ожиданий к кэшированию: как shared_buffers меняет игру.
Данный отчёт суммирует результаты сравнительного нагрузочного тестирования СУБД PostgreSQL с использованием комплекса pg_expecto 5.1. Целью экспериментов была объективная оценка влияния ключевого параметра памяти — shared_buffers — на производительность базы данных и метрики инфраструктуры, в первую очередь подсистемы ввода-вывода. Тестирование имитировало смешанную OLAP-нагрузку с преобладанием операций чтения на идентичных конфигурациях, где единственной переменной был размер буферного кэша (1 ГБ в первом эксперименте и 4 ГБ во втором).
https://dzen.ru/a/aWjqAGX1SViFFtPp

Настоящее исследование посвящено экспериментальной проверке общепринятой рекомендации по снижению параметра vm.swappiness для серверов PostgreSQL с "OLAP-нагрузкой". В ходе нагрузочного тестирования на синтетической рабочей нагрузке, имитирующей аналитические запросы, было оценено влияние значений vm.swappiness = 10 и vm.swappiness = 1 на производительность СУБД и инфраструктуры. Результаты выявили неожиданные закономерности, ставящие под сомнение универсальность данной рекомендации
https://dzen.ru/a/aWnOoP-X7waGvapc

Многие администраторы баз данных слепо доверяют рекомендациям нейросетей и популярным гайдам по настройке PostgreSQL. Однако реальные условия могут кардинально отличаться от теоретических. В этой статье мы разберем, почему vm.swappiness=1 может стать ошибкой, если не учесть узкие места системы
https://dzen.ru/a/aWsieexi4izqPgpg

vm.dirty_expire_centisecs = 1000 (10 секунд):
Уменьшает максимальное время хранения "грязных" данных в 3 раза
Позволяет более равномерно распределить запись на диск
Снижает риск накопления большого объема данных для сброса
#postgresql
https://dzen.ru/a/aWtKIpJDW0oZ3FfZ

Эксперимент проводился с целью проверки гипотезы о том, что уменьшение времени хранения «грязных» данных в памяти с 30 до 10 секунд позволит снизить нагрузку на подсистему ввода-вывода и улучшить отклик системы.
#postgresql
https://dzen.ru/a/aWt7Fsz1OHIAePWX

Тема для исследований.
Если PostgreSQL планирует контрольную точку, а ОС уже активно сбрасывает "грязные" страницы на диск — возникает избыточная нагрузка. Исследуем гипотезу о том, что согласование интервалов очистки кеша ОС и СУБД ведёт к более предсказуемой и эффективной работе.
#postgresql
https://dzen.ru/a/aWx78rz9xAmTkImr

Тема для исследований.
Настройка СУБД PostgreSQL не ограничивается её внутренними параметрами. Ключевым фактором является взаимодействие с операционной системой. В данном отчёте исследуется теоретическое влияние тонкого параметра ядра Linux — vm.vfs_cache_pressure — на эффективность работы PostgreSQL при OLTP, OLAP и смешанных нагрузках.
#postgresql
https://dzen.ru/a/aWx-05OfHlFsNBZM

PG_EXPECTO 5.1: Влияние vm.dirty_expire_centisecs=3000/1000/2000 на производительность PostgreSQL.
В отчете представлены результаты серии экспериментов по оценке воздействия настройки кэша записи ядра Linux (vm.dirty_expire_centisecs) на производительность СУБД PostgreSQL и дискового массива /data в условиях аналитической (OLAP) нагрузки с преобладанием операций чтения.
#postgresql
https://dzen.ru/a/aWyxxn4qWAPqkmqr

⚠️Теперь любое сравнение или бенчмарк должны в обязательном порядке содержать не только детальную конфигурацию СУБД (версия, размеры буферов, настройки памяти), но и полную информацию о ключевых параметрах операционной системы.⚠️ Без этого контекста результаты тестов теряют объективность и воспроизводимость, так как потенциально скрывают узкие места, обусловленные не СУБД, а её окружением.
#postgresql
https://dzen.ru/a/aW0aXo_lNXVRfObn

В документе представлен план развития инструмента PG_EXPECTO для анализа производительности PostgreSQL, а также перечень исследовательских тем в области статистического анализа СУБД. Особое внимание уделено оценке трудоёмкости реализации каждого направления
#postgresql
https://dzen.ru/a/aW3F-Lz9xAmT0ytZ
Риторические вопросы:
-Почему такая интересная и перспективная тема - мало кому интересна? Вендорам вообще не интересна.
-Как справится с таким огромным объёмом работ одному?

Анонс исследования: Моделирование OLAP-нагрузки и анализ влияния параметров ОС на производительность СУБД

В рамках цикла материалов по оптимизации инфраструктуры данных представляем методологию создания воспроизводимого тестового сценария pg_expecto.
Цель — генерация контролируемой нагрузки, имитирующей работу аналитических запросов (OLAP) в PostgreSQL.

Созданный сценарий планируется использовать как инструмент для фундаментального исследования. Ключевая научно-практическая задача — количественная оценка влияния конфигурационных параметров операционной системы (ядро Linux, планировщик ввода-вывода, управление памятью) на производительность СУБД.

Особый интерес представляет сравнительный анализ реакции двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP) — на единые изменения в окружении. Это позволит выявить потенциальные конфликты настроек и найти баланс для гибридных рабочих нагрузок.

Данный отчет представляет результаты комплексного анализа производительности СУБД PostgreSQL под нагрузкой, имитирующей OLAP.
#postgresql
https://dzen.ru/a/aW-JVhKDJmav3Gcm

Статья представляет собой глубокий сравнительный анализ паттернов производительности PostgreSQL 17 для двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP). Исследование проведено с помощью специализированного комплекса pg_expecto, предназначенного для статистического анализа и нагрузочного тестирования. Этот инструмент позволил не только имитировать сценарии, но и выявить тонкие корреляции между внутренними ожиданиями СУБД (DataFileRead, LWLock) и системными метриками (vmstat, iostat). В статье показано, как под нагрузкой ведут себя ключевые показатели: от hit ratio буферного кэша до времени отклика диска, и определены характерные «узкие места» для каждого типа задач.
Это готовый кейс для использования в нагрузочных тестах.
#postgresql
https://dzen.ru/a/aW-cHqWfDwHm_8O5

➡️Анонс: Как настройки ядра Linux влияют на PostgreSQL? Экспериментальное исследование OLTP и OLAP нагрузки

❓Ключевой вопрос: Насколько сильно тонкая настройка операционной системы может ускорить или замедлить работу вашей СУБД PostgreSQL? Я решил проверить это на практике, выбрав четыре критически важных параметра виртуальной памяти Linux.

В предстоящей статье будут представлены результаты серии контролируемых экспериментов, проведенных с помощью комплекса pg_expecto версии 5.2.

Фокус исследования: Сравнение производительности СУБД под OLTP (много коротких транзакций, частое обновление) и OLAP (сложные аналитические запросы, чтение больших объемов данных) типами нагрузки.
Цель — выяснить, как настройки ОС влияют на каждый сценарий.

Что настраивать? Эксперименты затронут ключевые параметры, управляющие работой с «грязной» памятью и кэшем файловой системы:

1️⃣☑️vm.dirty_ratio = 10 — процент памяти, при заполнении которого процессы блокируются для синхронной записи на диск.
2️⃣☑️vm.dirty_background_ratio = 5 — процент памяти, при котором фоновые процессы начинают асинхронную запись «грязных» страниц.
3️⃣vm.swappiness = 10 — склонность ядра к вытеснению страниц из RAM в swap (меньше значение — меньше свапим).
4️⃣vm.vfs_cache_pressure = 50 — тенденция к reclaim (освобождению) кэша inode и dentry (выше значение — агрессивнее очистка).

📋План экспериментов: Всего запланировано 8 тестов, что позволит оценить как индивидуальное, так и совокупное влияние тюнинга:

🔺Базовый замер (дефолтные настройки ОС) для OLTP и OLAP.☑️
🔺Последовательное включение каждого из четырех параметров по отдельности.
🔺Финальный тест со всеми четырьмя настроенными параметрами одновременно.

Что можно будет узнать из статьи:
1️⃣Конкретное влияние каждого параметра (dirty_ratio, swappiness и т.д.) на скорость отклика транзакций (tps) и время выполнения аналитических запросов (latency).
2️⃣Рекомендации по оптимальной конфигурации ОС для чисто OLTP, чисто OLAP и гибридных нагрузок.
3️⃣Практические выводы: стоит ли углубляться в тонкую настройку ядра или «дефолты» уже достаточно хороши?
4️⃣Оценку эффективности инструмента pg_expecto для проведения подобных исследований.

Следите за публикацией, где будет представлена детальная методология, графики сравнения производительности и готовые конфигурации для ваших серверов.
💥Результаты могут удивить!

#PostgreSQL #Производительность #Тюнинг #Linux #OLTP #OLAP #Эксперимент #БазыДанных

Эксперимент над ОС: зажигаем реактивную тягу OLTP и OLAP.

PostgreSQL. Выжми максимум

Уменьшение параметров грязной памяти — интуитивно понятный шаг для снижения IO-нагрузки. Но что, если он лишь меняет "симптомы", не затрагивая корень проблемы? Итоги нагрузочного тестирования бросают вызов упрощенным подходам к тюнингу.
В статье представлены результаты сравнительного анализа производительности СУБД PostgreSQL под OLAP-нагрузкой. Исследование фокусируется на оценке влияния ключевых параметров виртуальной памяти ядра Linux — vm.dirty_ratio и vm.dirty_background_ratio — на поведение системы, паттерны ожиданий и итоговую эффективность.
#postgresql
https://dzen.ru/a/aXCgSD09TjYLotxM

PG_EXPECTO 5.2 : OLTP - влияние vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД PostgreSQL.
В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы.
#postgresql
https://dzen.ru/a/aXDGJpuEUwzbZ1EU