web-dev-qa-db-fra.com

L'ANALYSE SOUS VIDE régulière est-elle toujours recommandée sous 9.1?

J'utilise PostgreSQL 9.1 sur Ubuntu. Sont programmés VACUUM ANALYZE toujours recommandé, ou est-ce que l'autovacuum est suffisant pour répondre à tous les besoins?

Si la réponse est "cela dépend", alors:

  • J'ai une grande base de données (30 GiB taille de vidage compressé, 200 GiB répertoire de données)
  • Je fais ETL dans la base de données, en important près de 3 millions de lignes par semaine
  • Les tables avec les modifications les plus fréquentes sont toutes héritées d'une table principale, sans données dans la table principale (les données sont partitionnées par semaine)
  • Je crée des cumuls horaires, et à partir de là, des rapports quotidiens, hebdomadaires et mensuels

Je demande parce que le VACUUM ANALYZE a une incidence sur mes rapports. Il fonctionne pendant plus de 5 heures, et j'ai dû le tuer deux fois cette semaine, car cela affectait les importations régulières de bases de données. check_postgres ne signale pas de ballonnement significatif sur la base de données, donc ce n'est pas vraiment un problème.

À partir des documents, autovacuum devrait également s'occuper de l'ID de transaction. La question se pose: ai-je encore besoin d'un VACUUM ANALYZE?

postgresqletlvacuum
38
François Beausoleil

VACUUM n'est nécessaire que sur les lignes mises à jour ou supprimées dans les tables non temporaires. De toute évidence, vous faites beaucoup d'insertions, mais il n'est pas évident d'après la description que vous faites également beaucoup de mises à jour ou de suppression.

Ces opérations peuvent être suivies avec le pg_stat_all_tables vue, en particulier la n_tup_upd et n_tup_del Colonnes. De plus, plus précisément, il existe un n_dead_tup colonne qui indique, par table, combien de lignes doivent être nettoyées. (voir Monitoring statistics dans le doc pour les fonctions et vues liées à la collecte de statistiques).

Une stratégie possible dans votre cas serait de supprimer le VIDE prévu, en gardant un œil sur cette vue et en vérifiant sur quelles tables le n_dead_tup augmente considérablement. Ensuite, appliquez le VIDE agressif uniquement sur ces tables. Ce sera une victoire s'il existe de grandes tables dont les lignes ne sont jamais supprimées ni mises à jour et que le VACUUM agressif n'est vraiment nécessaire que sur les tables plus petites.

Mais continuez à exécuter l'ANALYSE pour que l'optimiseur ait toujours de nouvelles statistiques.

32
Daniel Vérité

Je ne vois rien dans votre question dont autovacuum ne s'occupe pas. Cela dépend en grande partie du modèle de vos activités d'écriture . Vous mentionnez 3 millions nouveau lignes par semaine, mais INSERT (ou COPY) ne créent généralement pas de ballonnement de table et d'index. (autovacuum ne doit prendre en charge que statistiques de colonne , carte de visibilité et quelques travaux mineurs). UPDATE et DELETE sont la cause dominante du ballonnement des tables et des index, en particulier lors du ciblage de lignes aléatoires. Je ne vois rien de tout cela dans votre question.

autovacuum a parcouru un long chemin et fait un excellent travail dans Postgres 9.1 ou version ultérieure. Je voudrais jeter un œil aux autovacuum settings . Si l'aspiration a tendance à interférer avec votre charge de travail, jetez également un œil à "Délai de vide basé sur les coûts" . L'aspiration manuelle devrait être la rare exception.

Si vous avez beaucoup de UPDATEs aléatoires, vous souhaiterez peut-être définir FILLFACTOR sur une valeur inférieure à 100, pour autoriser les mises à jour HOT tout de suite et réduire le besoin de VACUUM. Plus d'informations sur les mises à jour HOT:

Notez également que les tables temporaires nécessitent un manuel VACUUM & ANALYZE. Je cite le manuel sur CREATE TABLE :

Le démon autovacuum ne peut pas accéder et ne peut donc pas vider ou analyser des tables temporaires. Pour cette raison, des opérations de mise sous vide et d'analyse appropriées doivent être effectuées via les commandes SQL de session. Par exemple, si une table temporaire doit être utilisée dans des requêtes complexes, il est judicieux d'exécuter ANALYZE sur la table temporaire après son remplissage.

25
Erwin Brandstetter

Bien que je convienne qu'il est préférable d'utiliser les fonctionnalités automatiques au lieu de l'exécuter à l'échelle de la base de données, dans la plupart des cas, le réglage par table est nécessaire.

Je ne suis pas tout à fait d'accord avec le choix de conception des postgres pour relier le vide et l'analyse, j'ai vu plusieurs cas où les bases de données qui font beaucoup d'insertion/mise à jour mais peu de suppression ne sont jamais analysées et commencent à mal fonctionner.

La solution consiste à entrer dans les tableaux qui sont largement utilisés et qui sont soumis à de grandes requêtes et à définir les paramètres d'analyse automatique de ces tableaux à quelque chose à l'endroit où ils sont analysés une fois ou tous les deux jours.

Vous pouvez accéder aux paramètres par table dans l'interface graphique de l'onglet de vide automatique et vous y verrez analyser les paramètres que vous pouvez définir indépendamment du vide.

Les paramètres se retrouvent dans le tableau des réoptions et peuvent être vus avec la requête

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

et une valeur d'échantillon d'une analyse agressive pourrait être

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Pour voir quand la dernière fois que vos tables ont été analysées automatiquement

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;
6
MvcCmsJon