Логично, что большинство гайдов по Postgres посвящены тому, как сделать его быстрее, выше, сильнее. А вы когда-нибудь задумывались, как наоборот сделать его медленнее?
Зачем? Ну, во-первых, это прекрасный способ разобраться, как СУБД работает и что обеспечивает ее производительность, а во-вторых, почему бы и нет.
Если вы об этом не задумывались, не страшно. Нашелся экспериментатор, который сделал это за вас и замедлил Postgres в 42 000 раз.
По условиям задачи, было тормозить его можно было только изменениями параметров
postgresql.conf. Иначе неспортивно.Итак, что же он сделал?
🔵Ужал кэш. Прочитав блок данных, Postgres записывает его в кэш, и это позволяет обрабатывать следующие запросы быстрее, чем если бы СУБД каждый раз обращалась к диску. Ряд экспериментов показал, что 2 МБ — это минимальное возможное значение, при котором Postgres может работать, просто очень медленно, обрабатывая 500 меньше транзакций в секунду. На старте, с кэшем в 10 ГБ у него было 7082 TPS.
🔵Завалил СУБД фоновыми задачами. В частности — заставил ежесекундно запускать autovacuum, процесс, с помощью которого Postgres находит и заполняет пустое место на диске новыми. Из-за ужатого кэша СУБД была вынуждена часто обращаться к диску, и скорость упала до 293 TPS.
🔵Заставил записывать все изменения в WAL перед внесением в базу. TPS упал ниже 100.
🔵Фактически отключил возможность пользоваться индексами, увеличив параметры
random_page_cost и cpu_index_tuple_cost и заставив сканировать все страницы последовательно. Кэш пришлось увеличить до 8МБ, но TPS все равно стал ниже единицы.🔵И наконец-то перевел Postgres в однопоточный режим, выставив параметры
io_method = worker и затем io_workers = 1. Это уронило TPS ниже 0,1. Дело сделано, база еле ползает. В конце статьи перечислены все параметры, в которые вносились изменения, если вдруг кто-то захочет повторить.
А что вы изменили бы, если бы хотели замедлить СУБД?