под нагрузочными тестами начало класть СУБД - плодятся idle, постепенно выедается память и в итоге oom-killer убивает постгресовый процесс. Если посмотреть, что там исполнялось, то видно, что все "лишние" idle в состоянии rollback. Причем разработчики поясняют, что rollback у них - норма и им они завершают все read-only тразнзакции 🤨 Типа изменений же не было, зачем коммит? Моя думать, что сие не true, но непонятно, как гуглу сформулировать запрос, чтобы понять. Спрашиваю у людей )
Да нет разницы как завершать. Просто подключение надо закрывать
ок. спасибо. С завершением тоже неочевидно. На стороне приложения выделенный пул соединений не растет. Выделено 50 коннектов, в него упирается и все. Дальше не плодится. Растет только на стороне субд. Может быть так, что в рамках этих 50-ти открываются постоянно новые на стороне субд и не закрываются?
Дело не в idle и не в rollback
Да же не знаю что на стороне СУБД может открывать, только если dblink какой на себя для автономных транзакций
> плодятся idle, постепенно выедается память В норме этого не должно быть. Какая версия PostgreSQL (SELECT version();)? И как и чем "выедается память"? > и в итоге oom-killer убивает постгресовый процесс может быть, эти "тесты" делают что-то нестандартное? Или, возможно, это обычное "убивай непричастных" поведение OOM killer? ;) > Моя думать, что сие не true Отчасти это так — но эта часть, в основном, теоретическая (состоит в том, что никаким данным, полученным из откаченной транзакции, "снаружи" нельзя доверять — но на практике этим PostgreSQL почти не пользуется). И к таким эффектам отношения не имеет.
Там пулер держит соединения.
И пусть держит. В норме это как минимум не имеет значения, а обычно только улучшает ситуацию.
Скорее всего у вас лимит коннекшинов, а автоматизаторы так хороши в коде что не знают как переиспользовать коннекшин и под каждый тестик создают новый Простое решение, постучать по головке автоматизаторам
Лимит не приводит к oom, но в целом как то так да
>Моя думать, что сие не true, Зря.
после танцев с бубном очевидность пропала окончательно ) Проблема только в debian(11,12). Аналогичные машины по дискам, цпу, памяти и настройкам постгреса дают разные результаты. В Centos7 держит нагрузку, в дебиан падает
Так что Вы сделали-то, конкретно (и с какими результатами)? И какая сейчас ситуация?
Centos 7 не сильно старше указаных Debian'ов?
CentOS Linux release 7.9.2009 (Core)
взяли 2 одинаковые ВМ, из стандартных настроек поправили только shared_buffers. На нагрузочном тесте центос держит нагрузку стабильно, на дебиан через пару минут начинает есть память и падает
Это неконкретное описание, извините. Что (какой процесс(ы)) начинает "есть память", как Вы это видите (каким инструментов), что в логах OS и PostgreSQL, когда "падает"? И да, Вы PostgreSQL-то обновили? ;)
угу. До 14.9. В логах:
Показывайте тексты текстом. И этого недостаточно, правда — всё остальное нужно.
Обсуждают сегодня