Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je rencontre actuellement un petit souci et j'aimerai vous en faire part :
J'effectue une requête de jointure à l'intérieur d'une transaction qui n'est pas terminée (pas de END;). Jusque là pas de souci.
Ensuite, sur une autre connexion, je viens faire un VACUUM. Et la je constate que le VACUUM ne se termine pas (il attend apparemment).
Lorsque je cloture la transaction sur l'autre connexion, le VACUUM s'achève bien.
Mon problème c'est que j'ai deux requêtes de jointure, sur 2 connexions différentes, et qui ne sont jamais terminées, sauf si j'en démarre une nouvelle.
La première requête ne pose aucun problème vis à vis du VACUUM, tandis que la deuxième bloque le VACUUM. Sauriez vous pourquoi?
Si vous avez une idée de où cela pourrait il venir, j'en serai fort intéressé!
Merci d'avance!
Hors ligne
Une jointure ne doit pas gêner vacuum. Sauf si c'est un vacuum full.
Ou à moins que votre transaction ne fasse autre chose posant un verrou sur un objet à déterminer.
Si vous voulez avancer davantage, il faudra inspecter pg_locks lorsque le problème se produit, afin de déterminer qui bloque qui pour quoi.
Marc.
Hors ligne
En fait j'ai regardé avec pg_locks et je n'ai rien trouvé d'aberrant.
Les relations utilisées pour la transaction #2 (celle qui pose problème), ressemblent aux relations utilisées pour la transaction #1 (celle qui ne pose pas problème), mais avec des noms de table différents, ce qui est normal. Il n'y a aucun verrouillage exclusif (à part des locktype virtualxid qui posent un ExclusiveLock, mais je suppose que c'est dû à la vue pg_locks ?).
J'ai remarqué autre chose d'intéressant :
Concernant la transaction qui pose problème, si la table utilisée ne contient que peu d'enregistrements, je n'ai pas de problèmes pour le VACUUM. Dès qu'un certain nombre d'enregistrement est atteint (a peu pres 500, voire moins), le VACUUM bloque.
Hors ligne
Laissez tomber la piste des nombres d'enregistrement pour le moment. Dans pg_locks, ce qui m'intéresse c'est :
Recherchez les verrous en granted à false. Recherchez ensuite les autres verrous s'appliquant au même objet. Copiez le tout ici (le verrou en attente, et les verrous le bloquant)
Vous aurez des pids dans la table de verrous, ce qui vous permettra aussi de savoir à quelle session chaque verrou correspond.
Marc.
Hors ligne
Il n'y a rien en granted à false.
Par contre je pense que ceci peu vous intéresser : Une fois le vacuum lancé et bloqué, je fais un select pg_locks joint avec pg_class et un RowExclusiveLock apparait :
----;------;---------;---------
pid;mode;granted;relname
----;------;---------;---------
1272;"RowExclusiveLock";t;"CTX_DICT_pkey"
1272;"ShareUpdateExclusiveLock";t;"CTX_DICT"
le pid 1272 correspond à la session qui appelle le VACUUM.
En tout cas merci pour votre aide
Hors ligne
Si vous n'avez aucun verrou avec granted à false, aucune session n'est bloquée. Le vacuum n'a donc aucune raison d'être bloqué.
Comment diagnostiquez vous qu'il bloque ? Êtes vous sûr que c'est un blocage, pas un simple ralentissement ? Qu'avez vous positionné comme valeurs pour vacuum_cost_limit et vacuum_cost_delay ? (et les 3 autres, si vous les avez modifiées)
Marc.
Hors ligne
Pour mon diagnostique :
1) Sur une session, la #1, je démarre une transaction, suivi d'un appel à ma procédure stockée (qui produit la jointure).
2) Sur une autre session, la #2, je lance un VACUUM. Rien ne se passe, la commande est en cours d'exécution. Je peux la laisser des heures, rien ne changera.
3) Je fais "END;" sur la session #1.
4) Le VACUUM s'achève tout de suite sur la session #2.
Pour les valeurs que vous me demandez, ce sont celles par défaut :
#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
Hors ligne
Je me rends compte que je n'ai pas posé la question : quelle version de PG ?
Marc.
Hors ligne
8.3
Hors ligne
Ça n'a donc vraiment pas de sens. Vous avez un moyen pour le reproduire, à partir d'une base vierge ?
Marc.
Hors ligne
Je n'ai pas essayé de reproduire sur une base vierge... Par contre j'ai déjà restauré la base plusieurs fois et le problème est toujours là.
Je fais un simple VACUUM ANALYSE, (de toute manière même un VACUUM tout court pose problème), et je ne comprends pas pourquoi je me retrouve avec un RowExclusiveLock dans la vue pg_locks...
Je tiens aussi a préciser que le RowExclusiveLock n'est pas forcément toujours sur la même relation. Tout à l'heure c'était sur CTX_DICT_pkey je crois, maintenant c'est sur CTX_HISTORY_pkey...
Dernière modification par slash (22/07/2010 10:48:22)
Hors ligne
Marc, je n'avais pas pensé à faire un VACUUM verbose. Je viens de le faire, et je me demande si ces informations ne sont pas utiles :
CPU 0.00s/0.00u sec elapsed 0.00 sec.INFO: vacuuming "public.CTX_HISTORY"
INFO: index "CTX_HISTORY_pkey" now contains 4982 row versions in 3071 pages
DETAIL: 0 index row versions were removed.
3054 index pages have been deleted, 3054 are currently reusable.
CPU 0.02s/0.02u sec elapsed 65.57 sec.INFO: "CTX_HISTORY": found 0 removable, 4982 nonremovable row versions in 26 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
1 pages contain useful free space.
0 pages are entirely empty.
Ca fait beaucoup de pages non?
Hors ligne
rowexclusive est un verrou de type table.
http://docs.postgresqlfr.org/8.4/explic … ing-tables
Elle indique simplement qu'une transaction modifie des données dans la table. C'est pour éviter par exemple qu'une indexation sur la table puisse se faire en même temps.
Marc.
Hors ligne
OK, c'est donc le VACUUM qui modifie des choses dans la table
Hors ligne
Poun 5000 enregistrements, 3071 pages, c'est effectivement énorme.
Mais sans façon de le reproduire, je ne vois pas comment aider. J'ai bien sûr testé sur une 8.3, le problème ne se manifeste pas. Et si il se produisait dans les cas courants, vous vous doutez bien que c'est une question qui reviendrait constamment.
Je crois qu'il faut vraiment trouver une façon de le reproduire.
Marc.
Hors ligne
Pages : 1
