Закрытие соединения в приложении не влияет на дисконнект баунсера с постгресом. Да и установка соединения дорогая операция

установка tcp-соединения - да дорогая и медленная. но гораздо больше времени пройдет на поднятие бакэнда pg и считывания кучи критических индексов и кэшей

Так какие причины не использовать такую методику работы?

В смысле? Это не поможет, соединение между боунсером и pg все равно оборвется по таймауту

В смысле? Это не поможет, соединение между боунсером и pg все равно оборвется по таймауту

кстати не понял, у вас по бездействию отрубает или даже активный бакэнд?

кстати не понял, у вас по бездействию отрубает или даже активный бакэнд?

даже активный

похоже на багу тогда

соединение между боунсером и pg

не наблюдал.

а не клиентом и боунсером

не наблюдал.

если не меняете сессионные параметры, то и не заметите

В смысле? Это не поможет, соединение между боунсером и pg все равно оборвется по таймауту

Я что-то запутался. :( Я спрашивал только вот об этом: > Его можно использовать когда есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение. Но это по любому ошибка дизайна.

Я что-то запутался. :( Я спрашивал только вот об этом: > Его можно использовать когда есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение. Но это по любому ошибка дизайна.

я не понимаю к чему это :)

Почему "есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение" —- это ошибка дизайна?

Почему "есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение" —- это ошибка дизайна?

Это не я говорил :)

Это я говорил. Ещё раз: 1. Установка соединения - дорогая операция 2. Если активных клиентов может быть много (> 1000), то pgbouncer в режиме session pooling не поможет

Это я говорил. Ещё раз: 1. Установка соединения - дорогая операция 2. Если активных клиентов может быть много (> 1000), то pgbouncer в режиме session pooling не поможет

Прав на все 100%

Почему "есть мало глупых клиентов, которые не держут коннектов, а на каждый чих устанавливают новое соединение" —- это ошибка дизайна?

Ошибка

Это я говорил. Ещё раз: 1. Установка соединения - дорогая операция 2. Если активных клиентов может быть много (> 1000), то pgbouncer в режиме session pooling не поможет

1. И что? Почему бы не рассчитывать на то, что pooler будет, если он нужен в этой ситуации? 2. Почему?

Ошибка

Почему?

1. Что что будут расходоваться ресурсы и клиента и пулера на ненужную работу (на переустановку соединений) 2. Потому что если все кдлиенты одновременно захотят работаь с базой то либо придётся запустить слишком много бэкендов и Посгресу станет плохо, либо придётсчя кого-то не пускать. И плохо станет клиентам. В режиме statement пулинга можно по очереди выполнять стайтменты различных клиентов на ограниченном чсиле клиентов. При повышенной активности клиентов они заметят лишь некторое замедление при работе с базой. Но это не ошибка приложения из зща невоможности получить доступ к базе.

объясняю, если work_mem достаточен на этапе планирования, то операция производиться делается в памяти - тогда может произойти OOM, если планировщик неодооценил кол-во строк. это проблема. а то что бакэнд кушает память и вышел на "крейсерное значение" - это не проблема

спасибо, да, имеет смысл посмотреть на work_mem

1. Что что будут расходоваться ресурсы и клиента и пулера на ненужную работу (на переустановку соединений) 2. Потому что если все кдлиенты одновременно захотят работаь с базой то либо придётся запустить слишком много бэкендов и Посгресу станет плохо, либо придётсчя кого-то не пускать. И плохо станет клиентам. В режиме statement пулинга можно по очереди выполнять стайтменты различных клиентов на ограниченном чсиле клиентов. При повышенной активности клиентов они заметят лишь некторое замедление при работе с базой. Но это не ошибка приложения из зща невоможности получить доступ к базе.

Спасибо. А чем "В режиме statement пулинга можно по очереди выполнять стайтменты различных клиентов на ограниченном чсиле клиентов." при указанном дизайне приложения отличается от " придётсчя кого-то не пускать", если "не пускать" —- это "замораживать" установление connection (в bouncer-е)?

Почему?

К 90% СУБД соединение устанавливается долго. Да вообще сетевое соединение TCP устанавливается долго. Но к этому сама инициализация соединения в СУБД тоже достаточно дорогая операция. Отсоединение чуть менее дорогое, но тоже недёшево.

Одно дело - когда клиент пытается приконнектится к базе и у него это не получается за заданный таймаут. Тогда работать с базой нельзя. Другое дело, когда он посылает запрос и получает ответ не через 0.1msec, а через 10msec. Ну или даже секунду. Проблема в том, что пока есть активные клиенты и их число больше чем ограничение на число сессий, то нового просто не пустят. Даже если клиенты тупо рвут коннекшины после каждого стайтмента, всё равно нет никакой гарантии, что клиенту удасться установтить соединение с сервером за N попыток с некторым таймаутом.

а оно обрывается

Такого не может быть

Такого не может быть

Я воспроизводил многократно

Покажите ? Баг отправляли ?

Я воспроизводил многократно

Покажите

За 10летнюю практику такого не видел

Только если что то вокруг настроенно не так как надо

Покажите ? Баг отправляли ?

Так это не баг, а фича типо. Регулируется параметром server_connect_timeout

За 10летнюю практику такого не видел

и не увидете, если не будете параметры сессии менять

Можно сделать просто тест, написать клиента, который выставляет схему и делает в ней вставку в таблицу, без явного указания схемы. И зациклить его

Так вот в какой то момент вставка перестанет работать

Потому что боунсер разорвет соединение и схему нужно будет выставлять по новой

Так это не баг, а фича типо. Регулируется параметром server_connect_timeout

Это вообще про коннект

а без нее будет ошибка, что схема не найдена

Вы что то путаете

Это вообще про коннект

именно, о нем и речь

О чем?!

server_connect_timeout If connection and login won’t finish in this amount of time, the connection will be closed. [seconds] Default: 15.0

баунсер рвет коннект с pg по таймауту независимо от нагруженности соединения

Вы вообще не про то говорите

Или путаете

Что то

А про что я говорю? :)

Не знаю

Тогда почему вы считаете что я путаю? :)

Я говорил всегда именно про кеннект и про режим коммитов в баунсере

для сессионного режима такой проблемы нет

!!!!

Стоп

ага

Так это не баг, а фича типо. Регулируется параметром server_connect_timeout

Вот это не про разрыв вообще

server_connect_timeout If connection and login won’t finish in this amount of time, the connection will be closed. [seconds] Default: 15.0

Вот это про что

Вот это не про разрыв вообще

ну называйте как хотите, факт в том, что соединение прерывается по таймауту

Вот это про что

таймаут закрытия соединения

таймаут закрытия соединения

Какой?!

Там нет проверки активно оно ли нет

Что вы там воспроизвели ?!

Я не понимаю сути ваших вопросов :)

Вы говорите , что есть баг

Нет, не баг

А я говорю, покажите

А фича, которая мне не нравится

Нет, не баг

Тогда покажите фичу?! Какой параметр ?!

А фича, которая мне не нравится

Нет такой фичи

Я утверждаю, что в случае транзакционного пулинга, bouncer рвет соединение между собой и postgres не зависимо от нагрузки соединение по таймауту, который я показывал - server_connect_timeout

Я утверждаю, что в случае транзакционного пулинга, bouncer рвет соединение между собой и postgres не зависимо от нагрузки соединение по таймауту, который я показывал - server_connect_timeout

Это баг. Вопроизвести и отправить разработчикам.

Я утверждаю, что в случае транзакционного пулинга, bouncer рвет соединение между собой и postgres не зависимо от нагрузки соединение по таймауту, который я показывал - server_connect_timeout

Вы читать умеете по английски ?!

transaction Server is released back to pool after transaction finishes.

Вы читать умеете по английски ?!

Возможно :)

Коллеги, почитайте внимательно доку

Я утверждаю, что в случае транзакционного пулинга, bouncer рвет соединение между собой и postgres не зависимо от нагрузки соединение по таймауту, который я показывал - server_connect_timeout

Это баг тогда, если вы умеете чтитать. Вот я вам и говорю, что нет таких багов

Вы читать умеете по английски ?!

+

Если вы имеете ввиду, что won't finish подразумевается, что ты отрубаешь, а он все равно живет

То в нашем случае он был выставлен в районе 60 часа

и ровно каждый час соединение обрывалось

Между pg и bouncer

Я вам говорю , что если бы баунсер рвал как попало соединения , он бы не был мастхев сервер к пг

Вы троль?!

Коллеги, почитайте внимательно доку

какую? на гитхабе в описании: server_connect_timeout If connection and login won’t finish in this amount of time, the connection will be closed. [seconds] Default: 15.0 Т.е. обрывать соединение, если в течение этого времени попытка подключения/логина не закончилась. В конфиге: ;; Cancel connection attempt if server does not answer takes longer. ;server_connect_timeout = 15 Т.е. обрывает, если сервер не отвечает в течение этого времени.

Я вам говорю , что если бы баунсер рвал как попало соединения , он бы не был мастхев сервер к пг

Он не как попало рвет

server_connect_timeout используется для прибивания соединений, котрые смогли приконнектится к Посгресу, но не смогли залогиниться за этот таймаут. Работающие сессии по этому таймауту никто не прибивает. Я вообще не нашёл в pgbouncer код, который пытается "просто-так" (без наличия каких-то ошибок) прибивать активные соединения.

Он не как попало рвет

Вы троль?! Какой параметр вы крутили?

server_connect_timeout

server_connect_timeout

Это тайм-аут на установку соединения !!!! Его ещё нет!!!

/* find connections that got connect, but could not log in */ if (cf_server_connect_timeout > 0) { statlist_for_each_safe(item, &pool->new_server_list, tmp) { server = container_of(item, PgSocket, head); Assert(server->state == SV_LOGIN); age = now - server->connect_time; if (age > cf_server_connect_timeout) disconnect_server(server, true, "connect timeout"); } }

какую? на гитхабе в описании: server_connect_timeout If connection and login won’t finish in this amount of time, the connection will be closed. [seconds] Default: 15.0 Т.е. обрывать соединение, если в течение этого времени попытка подключения/логина не закончилась. В конфиге: ;; Cancel connection attempt if server does not answer takes longer. ;server_connect_timeout = 15 Т.е. обрывает, если сервер не отвечает в течение этого времени.

а при чем здесь этот параметр? > Я утверждаю, что в случае транзакционного пулинга, bouncer рвет соединение между собой и postgres не зависимо от нагрузки соединение по таймауту, который я показывал - server_connect_timeout ключевое слово - транзакционного. А теперь читаем: pool_mode: session Server is released back to pool after client disconnects. Default. transaction Server is released back to pool after transaction finishes. statement Server is released back to pool after query finishes. Long transactions spanning multiple statements are disallowed in this mode. В режиме транзакционного пулинга соединение будет закрыто после ее завершения.

а при чем здесь этот параметр? > Я утверждаю, что в случае транзакционного пулинга, bouncer рвет соединение между собой и postgres не зависимо от нагрузки соединение по таймауту, который я показывал - server_connect_timeout ключевое слово - транзакционного. А теперь читаем: pool_mode: session Server is released back to pool after client disconnects. Default. transaction Server is released back to pool after transaction finishes. statement Server is released back to pool after query finishes. Long transactions spanning multiple statements are disallowed in this mode. В режиме транзакционного пулинга соединение будет закрыто после ее завершения.

Что вы тут все несете?!

@pg_vadim человек утверждает, что пгбаунсер рвёт рабочее соединение посередине транзакции. Ну я его именно так понял.

Нет, не по середине

а сруза после, если прошел таймаут

Возможно сыграл роль вот этот параметр

server_lifetime The pooler will try to close server connections that have been connected longer than this. Setting it to 0 means the connection is to be used only once, then closed. [seconds] Default: 3600.0

А не server_connection_timeout

Но факт в том, что после перехода на сесионный пулинг, проблема разрыва соединений ушла, при тех же настройках

теперь более понятно о чем вы

Во. Ещё один параметр появился. Ещё один подкину: server_idle_timeout Ну чтобы скучно не было.

If a server connection has been idle more than this many seconds it will be dropped. If 0 then timeout is disabled.