Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Général » Freeze postgres avec requete d'update 500 paramètres dans le IN » 21/10/2016 11:01:25
Merci pour votre réactivité !
#2 Re : Général » Freeze postgres avec requete d'update 500 paramètres dans le IN » 13/10/2016 17:54:08
Je viens de trouver d'ou cela vient : le chargement de shared_preload_libraries pour POWA ...
shared_preload_libraries='pg_stat_statements,powa,pg_stat_kcache,pg_qualstats'
C'est l'une des différences que j'avais entre mes 2 serveurs, et une fois désactivées, la requête passait bien ...
#3 Re : Général » Freeze postgres avec requete d'update 500 paramètres dans le IN » 13/10/2016 15:54:15
C'est la version 9.5.3
J'ai joué cette batterie de tests sur 3 serveurs différents, 2 ont freezé, et sur le 3eme (pourtant beaucoup moins puissant), c'est passé correctement.
Le plus simple serait que je puisse joindre des fichiers pour reproduire le problèmes, mais il n'y a à priori pas cette possibilité.
Comment puis-je vous les fournir ?
#4 Général » Freeze postgres avec requete d'update 500 paramètres dans le IN » 13/10/2016 12:01:46
- tsn77130
- Réponses : 7
Bonjour à tous,
je rencontre un problème de freeze de postgres lors de la mise a jour d'un champ par rapport à une liste de valeurs passée en argument dans le IN de la clause WHERE.
Ce qui est étrange, c'est que le freeze n'intervient qu'a partir de 500 arguments, ce qui me ferait penser a une sorte de buffer overflow
Ex :
update accounts_v1
set active = true
where (account_id, field_id) in ( (6262,5),(6622,22),(2254,7),(2698,70),(2310,4),(6135,22),... )
A 499 entrées dans le IN, l'update passe instantanément, à 500 postgres freeze, et je suis obligé de restart le process.
Ce que j'entend par "freeze", c'est qu'il est possible de se connecter, mais que postgres ne répond plus à aucune requete (meme un "select 1" reste bloqué)
Auriez vous une idée de ce qui se passe ?
#5 Re : Général » statement_timeout » 28/08/2014 14:06:04
Le temsp de réponse est vraiment lié a ce serveur, tout comme le fait que le statement timeout ne fonctionne pas, car sur mon autre serveur j'ai ma réponse en 1s dans pgadmin, et ma requete est bien stoppée par timeout_statement ...
#6 Re : Général » statement_timeout » 28/08/2014 14:00:08
Effectivement, lorsque je lance un "select * from pg_sleep(2)" après avoir validé "set statement_timeout to 1000;", j'ai bien un statement timeout.
Par contre, si je lance un "select * from users;", ma requete n'est pas stoppée.
Comment cela se fait il ?
Pour la base, j'ai un autre utilisateur qui arrive au même résultat, 1s en psql , et 40s en pgadmin.
Pour info, j'étais en 9.3.4 ce matin, j'ai monté le serveur en 9.3.5, rien n'a changé.
#7 Re : Général » statement_timeout » 28/08/2014 10:10:57
Nouveaux tests effectués, je n'y comprend rien.
J'ai mis le même statement sur une autre base d'un autre serveur, il est bien pris en compte par pgadmin.
Par contre, sur mon serveur 'principal', rien n'y fait, il n'en tient pas compte.
Mes 2 serveurs sont en 9.3 , pgadmin 1.18.1
Meme le "set statement_timeout to '2000'; " n'est pas pris en compte via pgadmin (ca fonctionne bien via psql), alors que sur ma seconde base, il fonctionne parfaitement...
D'ailleurs, une même requête n'a pas le même temps de réponse via psql ou pgadmin (1s en psql, environ 40 !! via pgadmin)
Pourtant, je suis bien sur que c'est la même base, et le même compte.
Y a il des éléments de conf de pgadmin qui pourraient interférer ?
#8 Re : Général » statement_timeout » 27/08/2014 17:25:19
J'ai revérifié, c'est bien les mêmes infos de connexion 
#9 Re : Général » statement_timeout » 27/08/2014 16:12:52
Merci de la réponse rjuju
Il est toujours la, défini comme ceci :
ALTER ROLE techs SET statement_timeout = '1500000';
Après recherches, je me suis aperçu que postgres killait bien les requêtes avec la mention explicite "ERROR: canceling statement due to statement timeout", SAUF lorsque cette requête est lancée depuis un client PGADMIN !! (la même requête, lancée depuis la même machine via psql avec les mêmes identifiants de connexion est bien killée
Des idées ?
#10 Général » statement_timeout » 27/08/2014 11:45:35
- tsn77130
- Réponses : 10
Bonjour à tous,
J'ai sur la ma base une contrainte user statement_timeout limitée à 1800000 (30mns) pour un compte donné.
Normalement, lorsque ce compte effectue une requête > à 30 mns, elle est killée par postgres.
hors, hier soir, j'ai une requete de cet user qui a duré plus de 15 heures, mettant par la même occasion le bazar sur ma base.
Avez vous une idée de pourquoi ma requête n'a pas été arrêtée par postgres cette fois ?
Merci d'avance !
#11 Re : Sécurité » probleme de CRL » 09/05/2014 14:42:22
J'étais déjà tombé dessus, merci.
De ce que je comprend, la personen a eu cette erreur lorsqu'elle ne fournissait pas au serveur le CA root, or dans mon cas je l'ai fait, d'ailleurs ça fonctionne très bien dès lors que je ne fournit pas de CRL.
Je n'ai pas réussi a trouver du mode débug de la transaction SSL via psql, ni réussi a afficher sur le serveur plus d'infos, du coup je ne sais pas trop comment investiguer sur ce problème.
#12 Re : Sécurité » probleme de CRL » 09/05/2014 11:47:02
Bon, 1ère partie du problème résolu, le durée de vie de la CRL était expirée...
Mais maintenant, j'ai l'erreur suivante : "psql: SSL error: tlsv1 alert unknown ca", toujours seulement lorsque ma CRL est activée sur le serveur
Mon pg_hba.conf
#local network
hostssl DB1 prod 172.20.0.0/16 cert clientcert=1 map=prod_srvs
(je précise que la map fonctionne bien)
#13 Sécurité » probleme de CRL » 09/05/2014 10:47:13
- tsn77130
- Réponses : 4
Bonjour à tous,
je suis actuellement en train de mettre en place un système d'authentification par certificats pour ma DB.
J'ai créé via une pki les certificats de ma db ainsi que de mes clients.
test de connexion OK
Par contre, j'ai un problème au niveau de mes CRL.
J'ai effectué quelques tests de révocation de certificats, et maintenant, dès que j'active la directive crl dans postgresql.conf, mes connexions sont rejetées, que le certificat ait effectivement été rejeté ... ou pas.
Voici les logs du serveur :
2014-05-09 10:19:08.163 CEST [14141]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=172.20.0.102 port=46148
2014-05-09 10:19:08.173 CEST [14141]: [2-1] user=[unknown],db=[unknown] LOG: could not accept SSL connection: no certificate returned
2014-05-09 10:19:08.173 CEST [14142]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=172.20.0.102 port=46149
2014-05-09 10:19:08.174 CEST [14142]: [2-1] user=prod,db=DB1 FATAL: no pg_hba.conf entry for host "172.20.0.102", user "prod", database "DB1", SSL off
2014-05-09 10:19:08.174 CEST [14142]: [3-1] user=prod,db=DB1 DETAIL: Client IP address resolved to "172.20.0.102", forward lookup not checked.
Et du client :
psql -h 172.20.0.11 -U prod DB1
psql: SSL error: sslv3 alert certificate expired
FATAL: no pg_hba.conf entry for host "172.20.0.102", user "prod", database "DB1", SSL off.
J'ai bien vérifié les serial numbers, le certificat avec lequel je tente de me connecter n'est pas listé dans la liste des certificats révoqués
Client :
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Server :
Revoked Certificates:
Serial Number: 01
Revocation Date: May 7 15:37:02 2014 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: 03
Revocation Date: May 6 14:13:28 2014 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: 06
Revocation Date: May 7 16:05:16 2014 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Superseded
Avez vos une idée d'ou peut venir le problème ?
Merci !
#14 Re : Général » fonctionnement des inxdexs » 27/01/2014 18:17:58
Bonjour rjuju, merci pour le retour.
Le problème vient en fait du temps que met postgres pour fixer un exclusive lock sur la table avant de pouvoir drop l'index.
Pour info si cela en intéresse certains, il a été rajouté une option concurrently sur le drop à partir de la 9.2
#15 Re : Général » fonctionnement des inxdexs » 23/01/2014 18:20:42
bonjour,
j'ai mis en place cette solution depuis quelques jours et elle fonctionne bien, et ce jour, j'ai eu un soucis lors du drop d'un index (non utilisé du coup, comme un nouvel index avait été créé) : la requete a mis beaucoup de temps a s’exécuter, et a mis en Wait toutes les requêtes suivantes.
Pourriez vous m'expliquer pourquoi cela se produit ?
Merci d'avance !
#16 Re : Général » fonctionnement des inxdexs » 07/01/2014 09:55:25
Oui, il s'agit du même index, le but étant de ne pas voir mes indexs grandir indéfiniment en terme d'espace disque notamment.
Je n'avais pas réussi à trouver cette information dans la doc...
Je ne fais pas tout dans une transaction, juste le drop de l'ancien index et le rename du nouveau (toto_idx_new) pour lui donner le nom de l'ancien (toto_idx), dans le but d'éviter le cas de figure ou le drop se passe bien, et le rename non. (et donc dans ce cas, et si je vous suit bien, mon index sera tout de même fonctionnel, il n'aurait juste pas le bon nom ?)
#17 Général » fonctionnement des inxdexs » 06/01/2014 18:07:41
- tsn77130
- Réponses : 9
Bonjour à tous,
Je cherche à remplacer certains indexs de ma base trop bloatés par des indexs recréés via un "create index concurrently" , suivi d'un "drop index idx ; alter index idx_new rename to idx" englobé dans une transaction.
Je me pose une question sur comment la base fonctionne pendant le laps de temps ou les 2 indexs coexistent, le temps que le drop / rename ait eu lieu.
Comment la base sait quel index elle doit interroger ?
Est ce que cela peut poser des problèmes ?
Merci
#18 Re : Général » Taille totale base » 06/01/2014 15:09:11
Merci de votre réponse guillaume
La transaction s'est arrêtée car j'ai renseigné le paramètre statement_timeout=1800000 sur la base (30 mns), et que la transaction a duré ce temps la.
Il n'y a a priori pas de fichiers temporaires sur la base, c'est bein le dossier dans 'base' qui fait cette taille la (j'ai créé un tablespace temporaire sur un autre volume, il est vide)
De plus, ils auraient du se supprimer après restart de la base dans ce cas, non ?
J’avais peut etre pensé à une table temporaire, amis lorsque je trie les tables par tailles, je ne voit rien qui correspond à ça...
#19 Général » Taille totale base » 03/01/2014 15:14:46
- tsn77130
- Réponses : 2
Bonjour à tous,
Il y a peu, nous avons tenté sur notre base une requête d'ajout de colonne dans une table de 20 Go avec un default false. (base en production)
La requête a mis énormément de temps a se faire, ne s'est pas terminée, et à surtout fait grimper la taille totale de la base de 170 à 200Go environ.
Suite au plantage, nous avons refait le même requête, sans le default false, et la cela a fonctionné nickel, en quelques secondes la requête s'était terminée, la base n'a pas bougé niveau taille.
Bref.
Ce qui est étrange, c'est que lorsque je regarde la taille des tables une à une, je ne vois aucune table qui a grossi, et je ne comprend pas ou sont passés ces 30 Go !
Pour tenter de regagner cet espace , j'ai effectué un vacuum full, mais malgré cela, je ne retrouve toujours pas mes 30 GO
Différences vues :
psql db
\l+
db | toto | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | | 131 GB | pg_default |
Et la requête que je lance pour voir le détail de ma base :
select sum(pg_table_size(table_schema || '.' || table_name)) as data,
sum(pg_indexes_size(table_schema || '.' || table_name)) as index,
sum(pg_total_relation_size(table_schema || '.' || table_name)) As total
FROM information_schema.tables;
Résultat : 99 Go
65117700096 | 33858953216 | 98976653312
Quand je fais le cumul des tailles de toutes les tables (data + index + toast), je tombe aussi sur 99 Go.
Sauriez vous pourquoi j'ai ce soucis ?
ps : Je suis en version 9.0
#20 Re : Réplication » node pgpool » 18/12/2012 17:05:24
Je ne l'avais pas fait, effectivement
Cela marche beaucoup mieux, pgbenchs a l'appui.
Merci beaucoup rjuju
#21 Réplication » node pgpool » 18/12/2012 13:18:06
- tsn77130
- Réponses : 2
salut a tous,
j'utilise pgpool en tant que pooler de connexion (aucun soucis) , et j'essaie en ce moment de le passer en mode load balancer pour les requetes select.
J'ai donc activé l'option load_balance_mode = true,
et changé le
backend_hostname0 = 'localhost'
backend_port0 = 5432
backend_weight0 = 1
en
backend_hostname0 = '192.168.1.230'
backend_port0 = 5432
backend_weight0 = 0.5
backend_hostname1 = '192.168.1.231'
backend_port1 = 5432
backend_weight1 = 0.5
pour y ajouter mes 2 hotes (localhost est le .230)
Le .230 étant le maitre, le .231 l'esclave.
Mon soucis, c'est que pgpool ne semble pas vouloir prendre les 2 hotes en compte.
Mes autorisations sur les serveurs postgres sont OK dans pg_hba.conf ; d'ailleurs si je met seulement l'un des 2 hotes en hostname0, ça fonctionne, les requetes lui sont bien envoyées. (avec pgbench ou via un select manuel par exemple)
Des que je met les 2, ca ne prend en compte que le premier que je déclare.
Pourtant, lorsque le lance pgpool avec l'option de debug, il semble me prendre les 2 nodes
------
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_hostname0
2012-12-18 12:12:42 DEBUG: pid 10173: value: '192.168.1.230' kind: 4
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_port0
2012-12-18 12:12:42 DEBUG: pid 10173: value: 5432 kind: 2
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: port slot number 0
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_weight0
2012-12-18 12:12:42 DEBUG: pid 10173: value: 0.5 kind: 3
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: weight slot number 0 weight: 0.500000
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_hostname1
2012-12-18 12:12:42 DEBUG: pid 10173: value: '192.168.1.231' kind: 4
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_port1
2012-12-18 12:12:42 DEBUG: pid 10173: value: 5432 kind: 2
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: port slot number 1
2012-12-18 12:12:42 DEBUG: pid 10173: key: backend_weight1
2012-12-18 12:12:42 DEBUG: pid 10173: value: 0.5 kind: 3
2012-12-18 12:12:42 DEBUG: pid 10173: pool_config: weight slot number 1 weight: 0.500000
2012-12-18 12:12:42 DEBUG: pid 10173: key: enable_pool_hba
2012-12-18 12:12:42 DEBUG: pid 10173: value: true kind: 1
2012-12-18 12:12:42 DEBUG: pid 10173: num_backends: 2 num_backends: 2 total_weight: 1.000000
2012-12-18 12:12:42 DEBUG: pid 10173: backend 0 weight: 1073741823.500000
2012-12-18 12:12:42 DEBUG: pid 10173: backend 1 weight: 1073741823.500000
----
Est ce que je rate quelque chose ?
Merci d'avance !
#22 Général » Rolled back transactions » 25/09/2012 09:39:17
- tsn77130
- Réponses : 1
Bonjour a tous,
petite question du jour,
j'ai dans ma supervision (munin) un graphe des transactions, et j'ai remarqué par rapport à ça que j'avaus des rolled back transactions sur ma base (pics environ toutes les 2h)
Y a il un moyen de savoir quelles sont ces transactions, et pourquoi elles 'ont pu être commitées ?
Merci de votre aide !
#23 Re : Général » verrous sur tables » 18/09/2012 17:32:31
Dans le meme genre, j'ai ma base qui s'est complètement bloquée à cause du nombre trop important de connexions, et je n'ai eu d'autres choix que de l'arreter et la redémarrer.
Dans ma supervision munin, je joius qu'il y a eu un nombre très importans de connexions en "waiting for lock"
Je penche donc pour une requete qui aurait bloqué tout le reste ... y a il un moyen de savoir laquelle ? (car si j'ai bien compris pg stat activity / pg locks ne gèrent que les requetes en cours non ?)
Merci !
#24 Re : Général » verrous sur tables » 17/09/2012 14:36:07
Parfait, je vous remercie !
#25 Général » verrous sur tables » 17/09/2012 11:36:46
- tsn77130
- Réponses : 5
bonjour a tous,
j'ai sur la base que j'administre des verrous RowExclusiveLocks depuis quelques jours, et ce beaucoup plus qu'a l'accoutumée, (vues dans mes graphes puis dans pg_locks).
J'aimerais savoir quelles sont les requetes qui en sont la cause, pourriez vous me dire comment les trouver ?
Merci d'avance