Opened 7 years ago

Closed 3 years ago

Last modified 3 years ago

#10402 closed Bug (needsinfo)

mysql backend connections left idle open

Reported by: DirkDatzert Owned by: nobody
Component: Database layer (models, ORM) Version: 1.4
Severity: Normal Keywords:
Cc: pembo13@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no



I have a related issue which behaves like ticket #9878 .

I query a model.objects during an AJAX jQuery Autocomplete call which receives an simple http-request, does an orm-related query of the db and reponses with a single http-response. Example view and urls are attached.

I run Django-1.0.X SVN 9684 with python-mysql 1.2.2 oder 1.2.3b1, Python 2.4.2 on SLES10 and apache2-mod_python-3.1.3 under apache2-2.2.3.

After one request the mysql db connection is left over in established mode on the client side and visible under SHOW PROCESSLIST via mysql cli as sleeping.

Some threads in the internet told that this maybe a bug in python-mysql in relation to mod_python but an update of python-mysql to latest beta didn't resolve this. I have a second application running under the same apache2 construct on the same host which didn't shows this idle connections. I connection is opened and closed correctly after a single HTTP-request.


Attachments (1)

jquery-autocomplete.txt (2.3 KB) - added by DirkDatzert 7 years ago.
jquery autocomplete

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by DirkDatzert

jquery autocomplete

comment:1 Changed 7 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 5 years ago by SmileyChris

  • Resolution set to needsinfo
  • Severity set to Normal
  • Status changed from new to closed
  • Type set to Bug

This is a rather old ticket, and seems to hinge around a very specific setup.

If someone can verify this is still an issue for them then feel free to reopen.

comment:3 Changed 3 years ago by pembo13

  • Easy pickings unset
  • UI/UX unset

I have the following environment:

  • Python 2.6.6
  • Django-1.4.1
  • Apache httpd-2.2.15-26
  • mod_wsgi
  • MySQL-python-1.2.3-0.3

While investigating a large number of aborted connection on a mysql server (large relatively to the amount of activity I was expecting, ~18 abortions per hour) I stumbled upon my Django app showing sleeping two sleeping connections in the SHOW PROCESSLIST; With multiple refreshes, I saw an increment of the aborted connections counter after each connection disappeared from the list.

comment:4 Changed 3 years ago by pembo13

  • Cc pembo13@… added
  • Resolution needsinfo deleted
  • Status changed from closed to new

comment:5 Changed 3 years ago by pembo13

  • Version changed from 1.0 to 1.4

comment:6 Changed 3 years ago by aaugustin

  • Resolution set to worksforme
  • Status changed from new to closed
  • Triage Stage changed from Design decision needed to Accepted

Unfortunately I have absolutely no idea where to start to diagnose this... If you're using Django 1.5 or earlier the code that closes connections at the end of each request is extremly straightforward -- it just calls connection.close()!

Connection handling code was overhauled in master to support persistent connections. If you can reproduce the bug on master (with CONN_MAX_AGE set to 0) have a look at this code:
and try to figure out why it doesn't work as expected on your setup?

comment:7 Changed 3 years ago by anonymous

I upgraded to django 1.5 yesterday and definitely see an increase in the idle connections. Here is a graph from RDS . Running "sudo netstat --all --program | grep 'mysql'" shows me that almost all of these were spawned from uwsgi which I used to serve django (they aren't from command line processes.

comment:8 Changed 3 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to new

comment:9 Changed 3 years ago by jacob

  • Resolution set to needsinfo
  • Status changed from new to closed

I'm fairly sure that this is related to your particular setup and not anything specific in Django. For example, if you've got code that connects to the database in your uwsgi config before uwsgi forks, that'll leak database connections. There isn't a ton that we can do about that; those connections get created "outside" Django essentially. In our experimentation, we couldn't make this happen unless we did something along those lines. So I think this is a problem with your configuration, not with Django itself.

It's possible I'm wrong, and if you do think this is a Django bug and can provide more information to help us reproduce it please feel free to reopen. But we're going to need a fair bit of information -- ideally a very small app that easily recreates the issue. And please do try to reproduce against Django master; connection handling's completely changed, and we won't be making any further improvements to the version shipping in 1.5.

comment:10 Changed 3 years ago by pembo13

Jacob, since I'm on 1.4, would my input on this possible issue be useless until I can reproduce in master?

Note: See TracTickets for help on using tickets.
Back to Top