web-dev-qa-db-fra.com

Dois-je VACUUM manuellement ma base de données PostgreSQL si le vide automatique est activé?

J'utilise un logiciel qui crée une grande base de données PostgreSQL (il y a une table avec un million de lignes) et les développeurs disent que je devrais VACUUM et ANALYZE périodiquement. Mais la valeur par défaut de la base de données PostgreSQL est autovacuum activée.

Dois-je passer l'aspirateur/analyser du tout? Quels sont les bénéfices? Quelle est la différence entre un aspirateur automatique et manuel

Par exemple, dans Pgadmin3, j'ai ceci:
enter image description here

postgresqlmaintenancevacuum
15
kissgyorgy

Je suis d'accord avec ETL qu'il n'y a pas de réponse courte. La taille n'est pas la seule chose qui compte - nous exécutons de très grandes bases de données PostgreSQL OLTP (avec certaines tables> 100 000 000 lignes) sous forte charge et actuellement, nous comptons uniquement sur le vide automatique.

Pourtant, deux choses me semblent importantes:

  • Il semble y avoir un consensus, que l'autovacuum ne doit jamais être désactivé, sauf si vous avez une charge de travail très bien définie sur votre base de données et que vous savez exactement ce que vous faites. Mais, naturellement, vous pouvez effectuer des exécutions supplémentaires de VACUUM et/ou ANALYZE.

  • Avant d'envisager des exécutions supplémentaires de VACUUM, je vérifierais comment l'autovacuum se maintient. Vous pouvez vérifier si des tables dépassent le seuil de vide automatique en interrogeant pg_stat_user_tables et pg_class. J'ai posté une telle requête sur un autre thread, qui pourrait être intéressante: Aggressive Autovacuum sur PostgreSQL .

    Malheureusement, il n'est pas aussi facile (c'est-à-dire impossible pour le moment) de faire une vérification similaire pour les seuils d'auto-analyse. Cependant, l'analyse automatique intervient bien avant le vide automatique par défaut et c'est beaucoup moins cher. Donc, fondamentalement, si votre base de données peut suivre le vide automatique, ce sera probablement bien aussi avec l'analyse automatique. Les dernières dates d'analyse automatique peuvent également être interrogées à partir de pg_stat_user_tables.

Quelques parties de la documentation PostgreSQL (la plus excellente) que j'ai trouvées utiles:

12
pygrac

Autovacuum devrait assez bien le couvrir, sauf si vous avez mal configuré quelque chose. D'autres réponses couvrent déjà cela.

Il existe un cas clairement défini pour manualVACUUM (et plus important encore: manual ANALYZE) cependant: tables temporaires , ils ne sont pas considérés par le démon autovacuum. Je cite le manuel sur CREATE TABLE ici :

Le démon autovacuum ne peut pas accéder et ne peut donc pas vider ou analyser des tables temporaires. Pour cette raison, les 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.

7
Erwin Brandstetter

Il n'y a pas de réponse courte à cela car cela dépend de beaucoup de facteurs. Le système est-il lent? L'auto-aspirateur touche-t-il réellement cette table? etc.

Voici quelques bons liens à ce sujet:

Pour prendre une décision claire, il faut comprendre la base de données elle-même et plus de détails sur ce qui se passe.

4
ETL

Je ne pense pas que vous ayez besoin de passer l'aspirateur manuellement, sauf si vous commencez à voir une dégradation des performances. Cependant, je recommanderais fortement de revoir vos paramètres de vide et de vide automatique et de l'adapter à vos besoins

Pour voir vos paramètres actuels, exécutez cette requête:

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

La plupart des champs sont explicites, mais voici la documentation à leur sujet: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

Je dirais que votre objectif devrait être de configurer automatiquement le vide pour nettoyer les ordures, mais ne lancez pas le vide automatiquement en permanence

Les paramètres les plus importants sont:

  • autovacuum_vacuum_scale_factor - détermine le pourcentage de tuples qui peuvent être morts avant le déclenchement d'un nettoyage. Valeur par défaut = 0,2
  • autovacuum_vacuum_threshold - nombre minimum de tuples morts avant le déclenchement du nettoyage. Valeur par défaut = 50

Le seuil permet d'éviter que le processus de nettoyage soit déclenché trop souvent pour les petites tables.

Les paramètres par défaut fonctionnent bien, sauf si vous avez de très grandes tables. Autrement dit, si vous avez une table qui prend 100 Go, vous allez accumuler 20 Go de déchets, avant que l'autovacuum ne se déclenche. Ainsi, je recommande généralement de définir un facteur d'échelle bas. À quel point vous devez déterminer par vous-même. J'utilise 0,05 sur mon projet actuel

Les seuils peuvent également être augmentés. De nombreuses applications ont quelques tables, qui sont fréquemment mises à jour et 50 tuples ce n'est pas tant que ça. Augmenter cela à 1000 ne devrait pas poser de problème, mais bien sûr, vous devriez considérer votre propre cas

Vous pouvez également affiner le vide automatique et avoir des paramètres différents pour certaines de vos tables

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

Si vous configurez scale_factor et les seuils, tout devrait bien se passer. Vous pouvez également augmenter autovacuum_vacuum_cost_limit, qui par défaut est égal à vacuum_cost_limit, qui est défini sur 200. Il s'agit d'une caractéristique très importante du vide, qui ne lui permet pas de consommer toutes les ressources et permet à votre application de fonctionner avec des données même pendant le processus de vide, mais la valeur par défaut est trop faible. L'augmenter à 1000 ne devrait pas entraîner de retards importants, mais permettra au processus de vide de se terminer beaucoup plus rapidement

Bien sûr, vous pouvez également exécuter le vide manuellement. Dans le cas le plus simple, vous pouvez avoir un travail cron simple, qui fera un nettoyage complet tous les soirs, lorsque votre base de données n'est pas fréquemment consultée

J'espère que cela pourra aider!

1
Hasan Ammori