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 me disent que je devrais VACUUMet ANALYZEpériodiquement. Mais la valeur par défaut de la base de données PostgreSQL est autovacuumactivé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:
Réponses:
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 des bases de données PostgreSQL OLTP assez volumineuses (avec certaines tables> 100 000 000 lignes) sous une forte charge et actuellement nous comptons uniquement sur le vide automatique.
Pourtant, deux choses me semblent importantes:
Il semble y avoir un consensus, à savoir 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 pourriez faire des courses supplémentaires VACUUMet / ou ANALYZE.
Avant d'envisager des VACUUMexécutions supplémentaires , 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_tableset pg_class. J'ai posté une telle requête sur un autre thread, qui pourrait être intéressant: Aggressive Autovacuum sur PostgreSQL .
Malheureusement, il n'est pas aussi facile (c'est-à-dire impossible pour le moment) d'effectuer une vérification similaire des 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'auto-analyse peuvent également être interrogées pg_stat_user_tables.
Quelques parties de la documentation PostgreSQL (la plus excellente) que j'ai trouvées utiles:
Autovacuum devrait assez bien le couvrir, sauf si vous avez mal configuré quelque chose. D'autres réponses couvrent déjà cela.
Il y a un cas clairement défini pour le manuel VACUUM (et plus important encore: manuel ANALYZE): les tables temporaires , elles ne sont pas prises en compte par le démon autovacuum. Je cite le manuel CREATE TABLEici :
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 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 sage de l'exécuter
ANALYZEsur la table temporaire après son remplissage.
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.
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:
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'auto-vide 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 l'autovacuum 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, ce qui équivaut par défaut à 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 nettoyage. , 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!