Нашли, перевели и опубликовали статью про эксперимент: авторы поиграли с параметрами в postgresql.conf и уронили производительность с 7000 до 0,1 транзакций в секунду.
Это наглядный урок о том, какие настройки действительно управляют скоростью, стабильностью и эффективностью СУБД.
🖥 Как построен эксперимент
Тест TPC-C через BenchBase, 128 складов, 100 соединений, изначально — стандартная конфигурация. С этого стартового уровня Postgres выдает около 7082 TPS. Затем автор шаг за шагом крутит ручки и смотрит, как все рушится:
1️⃣ Уменьшение shared_buffers с 10 ГБ до 8 МБ снижает TPS примерно в семь раз, а до 2 МБ — почти в пятнадцать. Меньше кэша — больше обращений к диску.
2️⃣Настройки вроде autovacuum_vacuum_threshold = 0, autovacuum_naptime = 1 и крошечный maintenance_work_mem заставляют систему постоянно запускать vacuum и analyze. Сервер тратит ресурсы не на запросы, а на собственное обслуживание.
3️⃣ Частые чекпоинты, wal_sync_method = open_datasync, wal_writer_flush_after = 0 — и Postgres тонет в синхронизации и сбросах на диск. Производительность падает до сотен TPS.
4️⃣Изменение random_page_cost и cpu_index_tuple_cost на гигантские значения фактически отключает индексы, а ограничение I/O до одного воркера (io_method = worker, io_workers = 1) добивает систему. На выходе — все работает в 42 000 раз медленнее.
Вывод: производительность PostgreSQL держится не только на железе или архитектуре, но и на понимании конфигурации. Пара неверных параметров способна уничтожить эффективность кластера, даже если все остальное настроено идеально.
Полную версию читайте на Хабре.