Ideale Einstellungen für pgbouncer mit Djangos CONN_MAX_AGE

Question

Ich betreibe eine Multi-Tenant-Website, wo ich den Aufwand für die Erstellung einer PostgreSQL-Verbindung pro Anfrage reduzieren möchte. Djangos CONN_MAX_AGE erlaubt dies, auf Kosten von vielen offenen Verbindungen zu PostgreSQL (8 Worker * 20 Threads = 160 Verbindungen). Mit 10 MB pro Verbindung verbraucht dies viel Speicher.

Der Hauptzweck ist die Reduzierung des Verbindungszeitaufwands. Daher meine Fragen:

• Welchen Setup sollte ich für eine solche Lösung verwenden? (PgBouncer?)
• Kann ich 'Transaktion' Pool-Modus mit Django verwenden?
• Wäre ich besser dran mit etwas wie: https://github.com/kennethreitz/django-postgrespool anstelle von Djangos Pooling?

Django 1.6 Einstellungen:

DATABASES['default'] = { 
    'ENGINE': 'django.db.backends.postgresql_psycopg2', 

    .... 

    'PORT': '6432' 
    'OPTIONS': {'autocommit': True,}, 
    'CONN_MAX_AGE': 300, 
} 

ATOMIC_REQUESTS = False # default 

Postgres:

max_connections = 100 

PgBouncer:

pool_mode = session  # Can this be transaction? 
max_client_conn = 400 # Should this match postgres max_connections? 
default_pool_size = 20 
reserve_pool_size = 5 

Answer 1

Hier ist ein Setup, das ich benutzt habe.

pgbouncer auf derselben Maschine wie gunicorn ausgeführt wird, Sellerie usw.

pgbouncer.ini:

[databases] 
<dbname> = host=<dbhost> port=<dbport> dbname=<dbname> 

[pgbouncer] 
: your app will need filesystem permissions to this unix socket 
unix_socket_dir = /var/run/postgresql 
; you'll need to configure this file with username/password pairs you plan on 
; connecting with. 
auth_file = /etc/pgbouncer/userlist.txt 

; "session" resulted in atrocious performance for us. I think 
; "statement" prevents transactions from working. 
pool_mode = transaction 

; you'll probably want to change default_pool_size. take the max number of 
; connections for your postgresql server, and divide that by the number of 
; pgbouncer instances that will be conecting to it, then subtract a few 
; connections so you can still connect to PG as an admin if something goes wrong. 
; you may then need to adjust min_pool_size and reserve_pool_size accordingly. 
default_pool_size = 50 
min_pool_size = 10 
reserve_pool_size = 10 
reserve_pool_timeout = 2 
; I was using gunicorn + eventlet, which is why this is so high. It 
; needs to be high enough to accommodate all the persistent connections we're 
; going to allow from Django & other apps. 
max_client_conn = 1000 
... 

/etc/pgbouncer/userlist.txt:

"<dbuser>" "<dbpassword>" 

Django-Einstellungen. py:

... 
DATABASES = { 
    'default': { 
     'ENGINE': 'django.contrib.gis.db.backends.postgresql_psycopg2', 
     'NAME': '<dbname>', 
     'USER': '<dbuser>', 
     'PASSWORD': '<dbpassword>', 
     'HOST': '/var/run/postgresql', 
     'PORT': '', 
     'CONN_MAX_AGE': None, # Set to None for persistent connections 
    } 
} 
... 

Wenn ich mich richtig erinnere, kann man im Prinzip eine beliebige Anzahl von "persistenten" Verbindungen zu pgbouncer haben, da pgbouncer die Serververbindungen zurück zum Pool freigibt, wenn Django damit fertig ist (solange man für verwendet). Wenn Django versucht, seine persistente Verbindung wiederzuverwenden, wartet pgbouncer darauf, auf eine verwendbare Verbindung zu Postgres zu warten.