Si tu utilises l'autovacuum p

sparky/ = 15 Avril, 2008 - 22:56

Si tu utilises l'autovacuum pourquoi encore le faire manuellement ?

La question est intéressante

paftek/ = 17 Avril, 2008 - 10:17

La question est intéressante vu que je ne suis que novice dans ce domaine.

L'autovacuum me dispense t'il d'effectuer ces VACUUM ANALYSE et VACUUM FULL ANALYSE ? (Je précise que ces VACUUM "manuels" ne s'appliquent qu'aux plus grosses tables de ma base de données.)

Pourrait-il y avoir conflit entre l'autovacuum et mes VACUUM ?

Plusieurs réponses

SAS/ = 18 Avril, 2008 - 09:47

Bonjour,

La réponse la plus importante, mais qui ne résoudra pas forcément le problème est : "Oui, vous devez installer la dernière version mineure". De manière générale, les versions mineures contiennent des correctifs de bogues qu'il est impératif d'appliquer. La mise-à-jour d'une version mineure n'implique qu'un simple redémarrage du serveur.

D'autre part, un autovacuum bien configuré, des FSM bien taillées... devraient vous permettre de ne plus utiliser le vacuum full.

Le vacuum full est une récupération physique d'espace. Les vacuum, tels que lancés par l'autovacuum, permettent de récupérer l'espace en mémoire, et donc d'éviter l'xplosion de la taille occupée sur le disque.

Un vacuum analyze se contente de recalculer des statistiques permettant au planificateur de déterminer s'il doit utiliser un index particulier lors de la détermination d'un plan de requête. Ils n'ont aucun impact sur le stockage des données.

Un autre point concerne les blocages de l'opération de vacuum full. Un vacuum full pose des verrous exclusifs, puisqu'il modifie physiquement les tables.
Or, il se trouve que vous constater des processus 'idle in transaction'. Il y a fort à parier qu'il y a des attentes de verrous entre les différents transactions ouvertes et le vacuum full.
Il serait intéressant d'essayer de déterminer l'origine des transactions qui restent ouvertes.

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr

Merci pour cette réponse tr

paftek/ = 18 Avril, 2008 - 12:24

Merci pour cette réponse très complète.

Je vais travailler sur ces différents point et je vous tiendrai au courant.

Premier retour

paftek/ = 16 Mai, 2008 - 10:06

- L'installation de la dernière version mineure n'a pas résolu le problème
- Mon autovacuum ne doit pas être correctement configuré : je suis obligé dans lancer hebdomadairement un VACUUM FULL pour ne pas perdre en performance
- Nous travaillons toujours à empêcher ces connexions "IDLE in transaction"...

Maintenant, question de débutant : en quelques mots, qu'est-ce qu'un "autovacuum correctement configuré" ?

Merci !

vacuum full et analyse 2 choses differentes

chione/ = 18 Juillet, 2008 - 11:13

Avez-vous tené de ne faire que ANALYZE (le vacuum devant s'effectuer par l'autovacum).

En faisant VACUUM FULL ANALYZE vous faites en réaliter 2 opérations d'un coté VACUUM qui récupère de la place disque et de l'autre coté ANALYZE qui fait des statistiques des tables (combien de données par tables etc).

Ces statistiques permetent ensuite à postgres de faire des requêtes plus efficaces. Sans ces statistiques, il n'est pas capable de savoir où sont les petites tables référencielles avec 20 enregistrements et ou sont les tables avec 2 millions de lignes, or quand on fait des join ces informations sont indispensables pour optimiser les requêtes.

Pour info sur des très grosses tables, le temps d'execution peut-être divisé par 1000 avec un analyze (on l'a testé sur notre base).

Donc pour résoudre votre problème tentez de ne faire qu'un ANALYZE qui n'aura peut-être pas besoin de verouiller les tables et qui donnera en fin de compte peut-être le même résultat.

Enfin il faut bien verifier que derrière il n'y a pas de baisses de performances.