🔥 Энтузиаст замедлил PostgreSQL в 42 000 раз с помощью 32 параметров

То есть все сугубо за счет настроек, что впечатляет

Один энтузиаст решил выяснить не как ускорить, а как максимально замедлить PostgreSQL.

И ему это удалось: производительность упала с 7082 транзакций в секунду до 0,016 TPS, то есть более чем в 42 000 раз.

Причем он не трогал железо, не удалял индексы и не вмешивался в код — все только через postgresql.conf.

Содержание

Минимальный кэш и перегруженный autovacuum
WAL, как у Брэндона Сандерсона
Отключение индексов и однопоточный I/O
Финал

Минимальный кэш и перегруженный autovacuum

Первый шаг — почти отключить кэш: shared_buffers = 2MB. Это резко снижает буферизацию страниц и увеличивает обращения к диску.

Затем — заставить Postgres непрерывно запускать autovacuum и analyze после каждой вставки. В итоге в логи будут падать десятки операций в секунду. Почти без пользы, но с большим I/O.

WAL, как у Брэндона Сандерсона

Потом автор усложнил систему логов WAL: настроил частые чекпоинты (checkpoint_timeout = 30, max_wal_size = 32MB) и принудил Postgres писать каждый байт максимально медленно (wal_sync_method = open_datasync, wal_level = logical).

🔥 Разработчик развеял мифы о чистом коде, трендах и идеальном программированииtproger.ru

Производительность упала до менее 1 TPS.

Отключение индексов и однопоточный I/O

Без удаления самих индексов автор просто сделал их бессмысленными для планировщика запросов: random_page_cost и cpu_index_tuple_cost были задраны до 1e300.

Вдобавок, Postgres был переведен на io_method = worker с io_workers = 1, чтобы все дисковое I/O выполнялось одним потоком.

Финал

В итоге Postgres смог обработать всего 11 транзакций за 2 минуты со 100 подключениями.

Эксперимент не только впечатляющий, но и полезный: он показывает, насколько надежно Postgres защищен от «случайного самоуничтожения». Но если очень захотеть — можно все.