Все привыкли бороться за каждую миллисекунду производительности, стремясь сделать базы данных быстрее, стабильнее, эффективнее. Но иногда стоит взглянуть на мир иначе: а как насчёт того, чтобы намеренно сделать Postgres максимально медленным? Именно таким нестандартным вопросом задался Джейкоб Джексон, безработный разработчик, решивший провести экстремальный эксперимент с любимой СУБД.
📉 Зачем замедлять Postgres?
Причины две, и обе любопытны:
🎯 Техническое любопытство — понять, как именно настройки влияют на работу СУБД.
🎲 Эксперимент ради эксперимента — иногда лучший способ научиться — довести систему до предела и посмотреть, как она поведёт себя в экстремальных условиях.
🚧 Технические детали реализации
Джейкоб взял типичную тестовую систему:
💻 Процессор Ryzen 7950x
💽 32 ГБ RAM, SSD 2 ТБ
🐧 Linux 6.15.6
🛢 PostgreSQL 19devel
Используя TPC-C бенчмарк (128 складов, 100 подключений), он получил начальный результат 7082 транзакций в секунду (TPS). А затем начался процесс замедления…
🐌 Шаги к замедлению PostgreSQL
🔹 Уменьшение кеша (shared_buffers)
- Начальный объём в 10 ГБ был сокращён до 2 МБ.
- Эффект: снижение производительности с 7082 до 485 TPS. Система начала постоянно обращаться к диску вместо оперативной памяти.
🔹 Бесконечный автоваакум
- Автоваакум, который обычно запускается для очистки свободного пространства, был настроен на запуск после каждого изменения.
- Эффект: снижение до 293 TPS из-за непрерывных фоновых операций очистки.
🔹 Максимально медленная запись в WAL (журнал предварительной записи)
- Изменил настройки WAL так, чтобы система постоянно совершала синхронизацию с диском после каждой небольшой операции.
- Эффект: производительность упала до 98 TPS.
🔹 Игнорирование индексов
- Параметры random_page_cost и cpu_index_tuple_cost были выставлены максимально большими, чтобы Postgres всегда выбирал медленные последовательные сканирования таблиц.
- Эффект: падение производительности до 0.87 TPS.
🔹 Ограничение ввода-вывода одним потоком
- С помощью новой функции Postgres 18 (io_method) все операции ввода-вывода были отправлены через один-единственный поток.
- Эффект: финальная скорость — всего 0.016 TPS, т.е. 42 000 раз медленнее исходного показателя.
💡 Что показал этот эксперимент?
Эксперимент прекрасно иллюстрирует, как сильно производительность СУБД зависит от конфигурации. Это особенно полезно понимать в контексте реальных систем, где случайная или неопытная настройка параметров может приводить к катастрофическим результатам.
Также этот опыт подчёркивает важность глубокого понимания работы СУБД и последствия, которые могут иметь неверно выбранные параметры конфигурации.
🤔 Личное мнение автора статьи
Этот эксперимент ценен именно своей абсурдностью и наглядностью. Он показывает, насколько мощные инструменты управления предоставляет PostgreSQL, и одновременно насколько легко ими злоупотребить. Такой подход даёт не только пищу для размышлений, но и возможность посмотреть на привычные вещи под необычным углом.
Кроме того, этот эксперимент — отличная демонстрация для начинающих разработчиков и администраторов баз данных: конфигурация важна, и неправильные настройки могут испортить даже самую быструю и мощную систему.
🗃️ Какие параметры привели к финальному результату:
- 🔸 shared_buffers = 8MB
- 🔸 autovacuum_vacuum_threshold = 0
- 🔸 autovacuum_naptime = 1
- 🔸 wal_writer_flush_after = 0
- 🔸 wal_sync_method = open_datasync
- 🔸 random_page_cost = 1e300
- 🔸 io_method = worker
- 🔸 io_workers = 1
Всего Джейкоб изменил 32 настройки.
🏁 Итог: Постгрес замедлился в 42 000 раз, совершая 0.016 транзакций в секунду вместо изначальных 7082 TPS. Это, конечно, своеобразное искусство вредительства, но весьма полезное для глубокого понимания устройства системы.
🔗 Оригинальная статья: Making Postgres 42,000x slower because I am unemployed
🔗 BenchBase для тестирования: Benchbase Postgres