Incertitudes PGBouncer
J'essaie de PGbouncer pour la première fois avec un simple Python (Flacon + psycopg2), et j'ai du mal à interpréter la signification de ses messages de journal par simple googling. Je suis essentiellement voir un tas de:
2014-06-09 09:25:07.867 20980 LOG C-0x1b1b240: vinum/vinum@unix:6432 login attempt: db=vinum user=vinum
2014-06-09 09:25:07.867 20980 LOG S-0x1b38bf0: vinum/[email protected]:5432 new connection to server
2014-06-09 09:25:07.875 20980 LOG C-0x1b1b240: vinum/vinum@unix:6432 closing because: client close request (age=0)
2014-06-09 09:25:15.626 20980 LOG C-0x1b1b240: vinum/vinum@unix:6432 login attempt: db=vinum user=vinum
2014-06-09 09:25:16.058 20980 LOG C-0x1b1b240: vinum/vinum@unix:6432 closing because: client close request (age=0)
2014-06-09 09:25:16.762 20980 LOG C-0x1b1b240: vinum/vinum@unix:6432 login attempt: db=vinum user=vinum
2014-06-09 09:25:16.796 20980 LOG C-0x1b1b3a8: vinum/vinum@unix:6432 login attempt: db=vinum user=vinum
2014-06-09 09:25:16.796 20980 LOG S-0x1b38d58: vinum/[email protected]:5432 new connection to server
2014-06-09 09:25:17.181 20980 LOG C-0x1b1b240: vinum/vinum@unix:6432 closing because: client close request (age=0)
2014-06-09 09:25:17.240 20980 LOG C-0x1b1b3a8: vinum/vinum@unix:6432 closing because: client close request (age=0)
Je trouve ces multiples fermetures avec age=0 Vous inquiétez-vous que les connexions sont toujours recréées, donc jamais regroupées?
Je trouve ces multiples fermetures avec l'âge = 0 inquiétant
Non, tout ce journal a l'air bien et tend à montrer que la mise en commun fonctionne.
Ces entrées avec age=0 être étiqueté comme LOG C, ils concernent la communication entre un client et PGbouncer. age=0 signifie simplement que le client a utilisé la connexion pendant moins de 1 seconde, ce qui correspond aux dates de millisecondes apparaissant dans ce journal.
Une ligne 1, un client se connecte à PGbouncer.
A la ligne 2, il y a une première connexion faite avec un nouveau backend Postgres.
A la ligne 3, le client quitte.
A la ligne 4, un nouveau client arrive et aucune nouvelle connexion n'est faite avec un backend, ce qui implique que le précédent est réutilisé comme prévu.
A la ligne 8, une deuxième connexion de serveur (LOG S) est fabriqué avec un nouveau backend Postgres, qui est nécessaire car il existe deux clients simultanés (voir les tentatives de connexion successives sur les deux précédents LOG C lignes dans la même seconde).
Ensuite, les clients quittent et il n'y a aucune mention de connexions aux retombées des postgres étant fermées, comme prévu à nouveau. Ils devraient être tenus ouverts jusqu'à ce qu'ils atteignent server_lifetime ou server_idle_timeout quand il est ralenti.