Comments 3
Я извиняюсь, а зачем вообще нужен swap на сервере субд в наши дни?
Swap не создаем. Корректно настраиваем shared_buffers и прочие связанные параметры бд с учетом максимального количества конектов чтобы не было OOM + немного оставить под файловый кеш os.
Своп был нужен во времена когда памяти было мало, а процессов много и нужно было хоть как-то запустить их на одной машине.
В случае сервера субд вся память должна быть отдана бд и процесс по сути будет только один - зачем тут своп? Если вся бд не влезает в shared_buffers, то бд сама будет подгружать ее страницы с диска, но в отличие от os она это делает осмысленно
а зачем вообще нужен swap на сервере субд в наши дни
Потому что как показал эксперимент - настройка swap оказывает влияние на то, что производительность СУБД в данной конкретной конфигурации и данным конкретным сценарием нагрузки с использованием vm.swappiness = 10 выше чем при vm.swappiness = 1. Причина в общем то уже понятна. Статья с подробным анализом будет готова завтра . Но опубликована на другом ресурсе (добавлю ссылку в конце статьи ).
Я не предлагаю тюнить vm.swapiness. Я предлагаю не создавать swap раздел. Вообще. Postgres предсказуемо использует память, соответственно можно заранее рассчитать макс. потребление и потюнить параметры бд, чтобы оверкомит по памяти никогда не случался.
Таким образом и настройка эта (vm.swapiness) не будет иметь никакого влияния. И никаких микрофризов вызванных пейджингом не будет гарантировано. Ну и в качестве бонуса вы продлите жизнь системных ssd дисков.
PG_EXPECTO 5.1: Влияние vm.swappiness=1 на производительность PostgreSQL