и памяти? Когда на одном кластере лежат БД разных бэкендов и не хотелось бы попасть в ситуацию когда одна база выжирает все ресурсы делая неработающими все остальные базы и соответственно их бэкенды)
Такого нету, поэтому коммуналки зло Хоть как-то на практике получается лимитировать через размеры серверных пулов в pgbouncer-e (и только если использовать transaction pooling) 2 коннекта ~~ 1 vcpu. И так поделить все цпу между разными базами. Но это для oltp баз.
+statement_timeout конкретных role
использовать свой кастомный шедулер, который коннекты от разных баз будет раскидывать по разным cgroup-ам приведет к разным граблям: 1) про cpu: при commit/rollback транзакции происходит ProcArrayLock в эксклюзивном режиме, а ProcArray это общая для всего инстанса сущность. Поэтому когда cgroups - скажет процессу sleep, в момент ProcArrayLock, то ни один commit/rollback не будет происходить по всему инстансу 2) по memory: cgroup-a не ограничивает использование памяти, она наказывает за превышение, поэтому вместо ошибки Out of Memory прийдет OOM killer и потушит сразу весь инстанс.
Если под каждый бэкенд виртуалку с pg поднимать не хочется, то несколько инстансов pg на одной виртуалке норм решение?
Может лучше один инстанс отдел ными базами
там появятся инструменты, которые вы хотите если запускать в контейнерах: $ docker run --help | grep -i limit если запускать через systemd: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#Options
у postgres-a нет встроенных механизмов изоляции разных тентантов внутри одного инстанса, поэтому если клиенты жалуются на шумных соседей, то, к сожалению, postgres вынуждает админов либо в контейнерах запускать базы либо в отдельных виртуалках безусловно операционная поддержка от этого проще не становится, но инструментов для автоматизации всего этого тоже не мало
Обсуждают сегодня