Hello, I have to say that, as the author of the “persistent connections” feature, I am confused by repeated references to a “connection pool” in this discussion. I chose *not* to implement a connection pool because these aren’t easy to get right. Users who need a connection pool are better off with a third-party option such as pgpool.
When persistent connections are enabled, each thread uses a persistent connection to the database — as opposed to one connection per HTTP request. That said connections aren’t shared or pooled between threads. This guarantees that each connection dies when the thread that opened it dies. In practice, Django opens a database connection per thread and keeps it open after each request. When the next request comes in, if the connection still works (this is tested with something like “SELECT 1”) and its maximum age isn’t reached, Django re-uses it; otherwise it closes it and opens a new one. This is what the “close_if_unusable_or_obsolete” function does — as the name says :-) I hope this helps, -- Aymeric. > On 03 Jun 2016, at 13:48, Cristiano Coelho <[email protected]> wrote: > > > El viernes, 3 de junio de 2016, 4:41:16 (UTC-3), Florian Apolloner escribió: > > Yes, SIGTERM is a signal Python should handle nicely, SIGKILL will just nuke > the process from earth and prevent any cleanup I think. Note that the OS will > clean up though (sooner or later). As for the open connections: Check on > postgres where from they are and then check on that machine to which process > they belong and maybe use gdb to find out more. > > > When I saw the issue the first thing I checked was the source IP and was the > amazon machine as expected, then I'm almost sure those connections were used > by the thread pools because the last statement was a 'commit' where normally > most of the statements listed through the list connections query are selects > and those pools always end up with an insert so the commit makes sense. > > The only issue I see here on the postgres side would be that you have very > long timeouts configured. > > Looks like postgres doesn't have any kind of connection timeout and you need > to use pg bouncer for that. > > > Well, I guess that with the connection.close_if_unusable_or_obsolete() change > it should improve the connection handling of the thread pools. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/5fbbb59e-4ed6-4795-b8e8-c97da791d3d1%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/5fbbb59e-4ed6-4795-b8e8-c97da791d3d1%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/E5C1BFEB-CB5A-4E5D-A450-22F1361761A1%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
