Vous n'êtes pas identifié(e).
Pages : 1
Bonjour, j'ai deux serveurs (9.1)en streaming replication,le deuxième est en hot standby. J'utilise la 3.2.1 de pgpool.
Je ne m'étais jamais trop posé la question de comment travaille le parser, et je viens d'étudier la logique du loadbalancing : http://www.pgpool.net/docs/latest/where … ueries.pdf .
J'ai fait qques tests que je n'arrive pas à comprendre :
1) Avec une requête du type "SELECT x,y,z FROM A limit 2", je la lance 100x (dans un script qui ouvre une connexion à chaque itération) : 50 vont sur le noeud 1 et 50 sur le noeud 2.
2) Avec une requête du "PREPARE toto(int) as SELECT x,y,z FROM A limit $1; execute toto(2)", je la lance 100x : les 100 partent sur le noeud 1.
J'avais l'impression en lisant le schéma de conditionnement, qu'il allait parser la requête dans le prepare et pourtant ça ne semble pas être le cas.
Je me trompe en lisant le schéma ? (je penche plutôt là dessus)
J'ai un loupé dans ma configuration du pgpool ?
Hors ligne
Je ne sais pas exactement comment cela fonctionne dans pgpool mais le comportement ne me paraît pas aberrant. La requête est préparée sur un serveur, les exécutions se font donc sur ce serveur. pgpool pourrait être plus malin et préparer la requête sur les deux serveurs pour pouvoir faire la répartition de l'exécution des requêtes sur les deux serveurs mais d'après vos tests, il ne le fait pas.
Guillaume.
Hors ligne
Je ferais mieux de lire le message complètement avant de répondre. Je crois que le problème vient du fait que vous exécutez deux instructions en même temps, ce qui désactive la répartition de charge.
Guillaume.
Hors ligne
Voilà, indiqué dans la doc : pgpool-II cannot process multi-statement queries.
Guillaume.
Hors ligne
Ah oui effectivement,merci . C'est donc toujours le cas pour une instructions préparée puisqu'elle n'existe que dans la session en cours et ne peut donc être exécutée que dans celle-ci ?
Hors ligne
Une instruction peut être préparée puis utilisée. À priori, pgpool doit pouvoir la prendre en compte dans la répartition de charge. Il faudrait faire un autre test du style:
* connexion
* prepare
* 5 requêtes execute séparées
* déconnexion
De toute façon, ça n'avait pas de sens de le faire comme vous l'aviez fait. Faire un PREPARE puis un seul EXECUTE casse l'intérêt de la requête préparée.
Guillaume.
Hors ligne
De mémoire il n' y a pas de balance de charge avec les prepare statement, car cela nécessiterait l'exécution du prepare sur chacun des nœuds, ce qui peut poser problème (plusieurs noms pour des requêtes différentes par exemple).
Julien.
https://rjuju.github.io/
Hors ligne
Ok, j'ai donc recommencé avec 5 EXECUTE derrière un PREPARE et pas de loadbalancing ce qui semble confirmer que comme un prepare statement n'est jamais loadbalancé les EXECUTE ne le sont pas non plus derrière.
Merci encore pour l'éclairage.
Dernière modification par uruvela (04/01/2013 14:55:08)
Hors ligne
Pages : 1
