Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Alors je vous explique ce que je tente de faire.
J'ai 12 serveurs (on les appellera logs1-12) sous le coude qui produisent un grand nombre de logs / sec (~800/sec/serveurs) donc 9600 requètes / sec au total.
J'utilise un programme maison en C (libpq) pour parser ces logs et les insérer sur un autre serveur Postgres qu'on appellera postgres-1.
Alors, sur postgres-1, j'ai un PgBouncer en mode transaction qui tourne, avec un max_client_conn = 15000 et un pool_size de 30, ainsi qu'un consumer pgq écrit en PHP.
Les serveurs logs1-12 envoient tout vers le consumer postgres-1 qui à son tour insère les entrées dans la bonne table.
Tout à l'air de bien fonctionner pendant un certain temps (quelques minutes), jusqu'à ce que sur mes serveurs logs1-12 je retrouve ces messages d'erreurs :
Connection to database failed: could not connect to server: Connection refused
Is the server running on host "192.168.x.x" and accepting
TCP/IP connections on port 6432?
Je retrouve les mêmes messages d'erreur sur mon serveur postgres-1 dans les logs de pgbouncer. Pourtant je monitor le bouncer avec la console d'admin, et celui-ci ne semble pas recevoir trop de connexions.
Quelqu'un aurait une idée ?
Je précise au cas ou la config de postgres-1 qui tient quand même la route :
Intel Quad core Xeon L5420 (2.5 Ghz, 2 x 6 Mo cache)
32 Go DDR2 667 MHz
RAID 1 : 2 x 500 Go SATA 7200 tr/mins
Dernière modification par bouchigreque (18/09/2014 14:16:59)
Hors ligne
bonjour,
Quelle est la valeur de max_connections sur vos différents clusters ?
Assurez vous aussi que votre programme en C libère bien les connexions proprement.
Cordialement,
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Merci pour votre réponse ! 
Alors, au niveau de la valeur de max_connections sur le cluster, celle-ci est à 200.
Pour ce qui est de la libération des connexions, je close bien celles-ci après chaque requête effectuée.
Cordialement.
Dernière modification par bouchigreque (18/09/2014 10:11:04)
Hors ligne
Bonjour,
Essayez d'augmenter max_connections à plus de 1000 pour voir si ça corrige votre problème.
Cordialement,
Cordialement,
Sébastien.
Hors ligne
J'ai essayé en passant le max_connetions à 1200, j'ai restart postgres, toujours pareil. 
Après il me semble que justement pgbouncer est là pour ne pas avoir à monter le nombre max de connections trop haut dans Postgres non ?
Merci pour l'aide en tout cas !
Hors ligne
Oui, le but d'un pooler est entre autres de mettre les connexions file d'en attente un cours moment. Cela suppose donc qu'il ne s'agit pas de connexions persistantes.
Je n'ai pas trop compris le fonctionnement de votre application. Quand vous parlez de log, s'agit-t-il de fichier log ou d'enregistrements dans une table ?
Sinon, il est possible qu'avec un nombre de connexion aussi grand côté pgBouncer, il faille augmenter la limite de descripteur de fichier pour l'utilisateur lançant pgBouncer. Sur une debian, cette limite est à 1024 , donc largement inférieure à vos 1500 connexions. Vous pouvez le vérifier avec » ulimit -n » en tant qu'utilisateur lançant pgBouncer.
Julien.
https://rjuju.github.io/
Hors ligne
Oui, le but d'un pooler est entre autres de mettre les connexions file d'en attente un cours moment. Cela suppose donc qu'il ne s'agit pas de connexions persistantes.
Je n'ai pas trop compris le fonctionnement de votre application. Quand vous parlez de log, s'agit-t-il de fichier log ou d'enregistrements dans une table ?
Sinon, il est possible qu'avec un nombre de connexion aussi grand côté pgBouncer, il faille augmenter la limite de descripteur de fichier pour l'utilisateur lançant pgBouncer. Sur une debian, cette limite est à 1024 , donc largement inférieure à vos 1500 connexions. Vous pouvez le vérifier avec » ulimit -n » en tant qu'utilisateur lançant pgBouncer.
Pour le fonctionnement de l'application, en fait mon programme s'occupe de parser un flux de texte pour l'insérer directement dans une table sur postgres-1. Sur logs1-12 aucun serveur Postgres n'est présent, seulement la libpq.
Très bonne idée pour les file descriptors, je n'y avais pas pensé ! Je teste d'augmenter la limite et je vous fait un retour.
Merci !
Dernière modification par bouchigreque (18/09/2014 11:31:51)
Hors ligne
Bon, même après avoir augmenté la limite des FD sur mon serveur, toujours le même message malheureusement...
Je vais continuer à creuser.
Sinon côté consumer PHP, celui-ci passe aussi par le bouncer, je pense que ça n'a pas d'influence sur cette erreur non ?
Edit : Tiens, après avoir jeté un oeil dans les syslog, j'ai ça qui apparaît de très nombreuses fois :
[ 586.088630] nf_conntrack: table full, dropping packet.
Du coup je vais essayer de désactiver le conntrack, parce que bon, si c'est le kernel qui drop des paquets, je comprends mieux pourquoi mes connexions drop aussi.
Edit 2 : C'était donc bien le kernel qui avait sa conntrack table pleine. J'ai donc mis ce qui arrivait depuis mon réseau local en NOTRACK, et depuis plus de soucis ! Rien à voir donc avec Postgresql qui fait bien son taff comme d'habitude.
Dernière modification par bouchigreque (18/09/2014 17:31:24)
Hors ligne
Pages : 1
