Explication des entrées du journal pgbouncer dans le projet django

Question

J'utilise pgbouncer dans une application Web Django. Le serveur d'applications et le serveur de base de données sont deux machines virtuelles distinctes. pgbouncer est installé sur le serveur d'applications. les paramètres pertinents dans pgbouncer.ini sont:

[databases] 
dbname = host=80.211.128.113 port=5432 dbname=dbname 

pool_mode = transaction 
max_client_conn = 250 
default_pool_size = 100 

Une fois pgbouncer a repris, j'ai vérifié pgbouncer.log et trouvé beaucoup d'entrées comme suit:

2016-11-15 12:26:27.514 582 LOG S-0x1192740: dbname/myuser@80.211.128.113:5432 new connection to server 
2016-11-15 12:26:27.517 582 LOG C-0x11afcb8: dbname/myuser@127.0.0.1:42262 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.523 582 LOG S-0x1192a10: dbname/myuser@80.211.128.113:5432 new connection to server 
2016-11-15 12:26:27.528 582 LOG C-0x11af880: dbname/myuser@127.0.0.1:42250 closing because: client close request (age=0) 
2016-11-15 12:26:27.528 582 LOG S-0x1191a98: dbname/myuser@80.211.128.113:5432 closing because: unclean server (age=0) 
2016-11-15 12:26:27.548 582 LOG C-0x11afb50: dbname/myuser@127.0.0.1:42258 closing because: client close request (age=0) 
2016-11-15 12:26:27.556 582 LOG C-0x11aff88: dbname/myuser@127.0.0.1:42256 closing because: client close request (age=0) 
2016-11-15 12:26:27.556 582 LOG S-0x1191c00: dbname/myuser@80.211.128.113:5432 closing because: unclean server (age=0) 
2016-11-15 12:26:27.564 582 LOG C-0x11aff88: dbname/myuser@127.0.0.1:42264 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.569 582 LOG C-0x11afb50: dbname/myuser@127.0.0.1:42265 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.570 582 LOG S-0x1191c00: dbname/myuser@80.211.128.113:5432 new connection to server 
2016-11-15 12:26:27.593 582 LOG C-0x11af448: dbname/myuser@127.0.0.1:42255 closing because: client close request (age=0) 
2016-11-15 12:26:27.593 582 LOG C-0x11afcb8: dbname/myuser@127.0.0.1:42262 closing because: client close request (age=0) 
2016-11-15 12:26:27.593 582 LOG S-0x1191c00: dbname/myuser@80.211.128.113:5432 closing because: unclean server (age=0) 
2016-11-15 12:26:27.597 582 LOG C-0x11afb50: dbname/myuser@127.0.0.1:42265 closing because: client close request (age=0) 
2016-11-15 12:26:27.603 582 LOG C-0x11afb50: dbname/myuser@127.0.0.1:42267 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.604 582 LOG C-0x11afcb8: dbname/myuser@127.0.0.1:42268 login attempt: db=dbname user=myuser 

Si analysé de près, de nombreux cas de closing because: unclean server et closing because: client close request se trouvent dans la fichier journal. Quelqu'un peut-il expliquer ce que ce sont? Peut-être que je fais quelque chose de mal. En surface, mon application semble fonctionner correctement jusqu'à présent. Mais j'ai besoin de comprendre ce que je vois dans mes fichiers journaux pour être sûr de quoi. Merci d'avance.

Answer 1

• LOG C - journaux avec ces en-têtes sont liés à un client qui se connecte à pgbouncer (pas le serveur postgresql).
• LOG S - sont environ communication entre pgbouncer et le serveur (la vraie connexion à serveur posgres).
• age=0 - indique le temps d'utilisation, c'est-à-dire un LOG C avec age=0, signifie que le client a utilisé la connexion pendant moins d'une seconde.

---

La réponse:

fermeture parce que: client demande de fermeture

n'y a rien à craindre, tout à fait normal. Il enregistre que le client a tout à fait le client n'a plus de connexion en direct à pgbouncer.

Habituellement, les journaux sont comme:

Lors de la première tentative de connexion à pgbouncer

Ligne 1 - tentative de connexion pgbouncer.

Ligne 2 - pgbouncer faisant la tentative de connexion au serveur postgresql.

Ligne 3 - demande du client est terminée et la connexion client-pgbouncer est fermé

2016-11-15 12:26:27.517 582 LOG C-0x11afcb8: dbname/myuser@127.0.0.1:42262 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.523 582 LOG S-0x1192a10: dbname/myuser@80.211.128.113:5432 new connection to server 
2016-11-15 12:26:27.528 582 LOG C-0x11af880: dbname/myuser@127.0.0.1:42250 closing because: client close request (age=0) 

Ligne 1 - tentative de connexion pgbouncer par un nouveau client.Il va réutiliser le déjà ouvert la connexion au serveur postgresql (ouvert pour le dernier client)

Ligne 2 - demande du client est terminée et la connexion client-pgbouncer est fermé

2016-11-15 12:26:27.569 582 LOG C-0x11afb50: dbname/myuser@127.0.0.1:42265 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.593 582 LOG C-0x11af448: dbname/myuser@127.0.0.1:42255 closing because: client close request (age=0) 

Ligne 1 & 2 - 2 clients simultanés qui tentent de connexion pgbouncer

ligne 3 - pgbouncer faire une seconde tentative de connexion au serveur postgresql, pour la deuxième client (premier réutilisera l'un déjà ouvert)

ligne 4 & 5 - Les demandes des clients sont terminées et les connexions client pgbouncer sont fermés

2016-11-15 12:26:27.564 582 LOG C-0x11aff88: dbname/myuser@127.0.0.1:42264 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.569 582 LOG C-0x11afb50: dbname/myuser@127.0.0.1:42265 login attempt: db=dbname user=myuser 
2016-11-15 12:26:27.570 582 LOG S-0x1191c00: dbname/myuser@80.211.128.113:5432 new connection to server 
2016-11-15 12:26:27.593 582 LOG C-0x11af448: dbname/myuser@127.0.0.1:42255 closing because: client close request (age=0) 
2016-11-15 12:26:27.593 582 LOG C-0x11afcb8: dbname/myuser@127.0.0.1:42262 closing because: client close request (age=0) 

---

fermeture parce que: serveur impur

Peut-être un problème, car il semble que pgbouncer devient et fermeture d'une nouvelle connexion au serveur postgres avec chaque nouveau client qui s'y connecte (pgbouncer).

Solution possible/sortie-peut-être avoir quelque chose à voir avec comment le Django works by default.

Comme pgbouncer de mise en commun normale ne doit pas fermer ses connexions au serveur postgres (au moment de la fermeture d'une connexion client) - Vous pouvez obtenir cette connexion au serveur de messages/journaux proches lorsque la connexion peut atteindre server_lifetime ou server_idle_timeout au repos, sinon pas .

---