Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Aspirer et analyser automatiquement les tables
Autovacuum est un démon (c'est-à-dire qu'il s'exécute en arrière-plan) qui *aspire* (nettoie) automatiquement les tuples morts, récupère le stockage et collecte des statistiques. Il vérifie la présence de tables surchargées dans la base de données et efface la surcharge pour réutiliser l'espace. Il surveille les tables et les index de base de données et les ajoute à une tâche de mise sous vide une fois qu'ils ont atteint un certain seuil d'opérations de mise à jour ou de suppression.
Autovacuum gère l'aspiration en automatisant `VACUUM` PostgreSQL et les commandes. `ANALYZE` `VACUUM`élimine la surcharge des tables et permet de récupérer de l'espace, tout en mettant à `ANALYZE` jour les statistiques qui permettent à l'optimiseur de produire des plans efficaces. `VACUUM`effectue également une tâche majeure appelée *congélation sous vide* pour éviter les problèmes d'encapsulation des identifiants de transaction dans la base de données. Chaque ligne mise à jour dans la base de données reçoit un ID de transaction du mécanisme de contrôle des transactions de PostgreSQL. Ils IDs contrôlent la visibilité de la ligne par rapport aux autres transactions simultanées. L'ID de transaction est un numéro de 32 bits. Deux milliards IDs sont toujours conservés dans le passé visible. Les autres (environ 2,2 milliards) IDs sont préservés pour les transactions qui auront lieu dans le futur et ne seront pas inclus dans la transaction en cours. PostgreSQL nécessite un nettoyage *et* un gel occasionnels des anciennes lignes afin d'empêcher les transactions de s'enrouler et de rendre les anciennes lignes existantes invisibles lors de la création de nouvelles transactions. Pour plus d'informations, consultez la section [Prévention des échecs d'encapsulation des identifiants de transaction](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) dans la documentation de PostgreSQL.
L'aspiration automatique est recommandée et activée par défaut. Ses paramètres sont les suivants.
| | | | |
| --- |--- |--- |--- |
| **Paramètre** | **Description** | **Par défaut pour Amazon RDS** | **Par défaut pour Aurora** |
| `autovacuum_vacuum_threshold` | Le nombre minimum d'opérations de mise à jour ou de suppression de tuples qui doivent avoir lieu sur une table avant qu'Autovacuum ne l'aspire. | 50 opérations | 50 opérations |
| `autovacuum_analyze_threshold` | Le nombre minimum d'insertions, de mises à jour ou de suppressions de tuples qui doivent se produire sur une table avant qu'Autovacuum ne l'analyse. | 50 opérations | 50 opérations |
| `autovacuum_vacuum_scale_factor` | Le pourcentage de tuples qui doivent être modifiés dans une table avant qu'Autovacuum ne l'aspire. | 0.1 | 0.1 |
| `autovacuum_analyze_scale_factor` | Pourcentage de tuples qui doivent être modifiés dans une table avant qu'Autovacuum ne l'analyse. | 0,05 | 0,05 |
| `autovacuum_freeze_max_age` | L'âge maximum pour IDs être congelé avant qu'une table ne soit passée à l'aspirateur afin d'éviter les problèmes d'encapsulation des numéros de transaction. | 200 000 000 transactions | 200 000 000 transactions |
Autovacuum dresse une liste de tables à traiter en fonction de formules de seuil spécifiques, comme suit.
+ Seuil pour courir `VACUUM` sur une table :
```
vacuum threshold = autovacuum_vacuum_threshold + (autovacuum_vacuum_scale_factor * Total row count of table)
```
+ Seuil pour courir `ANALYZE` sur une table :
```
analyze threshold = autovacuum_analyze_threshold + (autovacuum_analyze_scale_factor * Total row count of table)
```
Pour les tables de petite ou moyenne taille, les valeurs par défaut peuvent être suffisantes. Cependant, une grande table dont les données sont fréquemment modifiées comportera un plus grand nombre de tuples morts. Dans ce cas, l'aspirateur automatique peut traiter fréquemment la table à des fins de maintenance, et la maintenance des autres tables peut être retardée ou ignorée jusqu'à ce que la grande table soit terminée. Pour éviter cela, vous pouvez régler les paramètres d'autovacuum décrits dans la section suivante.
## Paramètres liés à la mémoire Autovacuum
**`autovacuum_max_workers`**
Spécifie le nombre maximum de processus d'aspiration automatique (autres que le lanceur d'aspiration automatique) pouvant être exécutés simultanément. Ce paramètre ne peut être défini que lorsque vous démarrez le serveur. Si le processus d'aspiration automatique est occupé par une grande table, ce paramètre permet d'exécuter le nettoyage des autres tables.
**`maintenance_work_mem`**
Spécifie la quantité maximale de mémoire à utiliser par les opérations de maintenance telles que `VACUUM``CREATE INDEX`, et`ALTER`. Dans Amazon RDS et Aurora, la mémoire est allouée en fonction de la classe d'instance à l'aide de la formule`GREATEST({DBInstanceClassMemory/63963136*1024},65536)`. Lorsque l'autovacuum fonctionne, cette valeur calculée peut être allouée jusqu'à `autovacuum_max_workers` plusieurs fois. Veillez donc à ne pas définir une valeur trop élevée. Pour contrôler cela, vous pouvez définir `autovacuum_work_mem` séparément.
**`autovacuum_work_mem`**
Spécifie la quantité maximale de mémoire à utiliser par chaque processus d'aspiration automatique. La valeur par défaut de ce paramètre est -1, ce qui indique que vous devez utiliser la valeur de à la `maintenance_work_mem` place.
Pour plus d'informations sur les paramètres de mémoire Autovacuum, consultez la section [Allocation de mémoire pour Autovacuum dans la documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory) Amazon RDS.
## Réglage des paramètres d'autovacuum
Les utilisateurs peuvent avoir besoin de régler les paramètres d'autovacuum en fonction de leurs opérations de mise à jour et de suppression. Les paramètres suivants peuvent être définis au niveau de la table, de l'instance ou du cluster.
### Au niveau du cluster ou de l'instance
Prenons l'exemple d'une base de données bancaire dans laquelle des opérations en langage DML (Continuous Data Manipulation Language) sont attendues. Pour préserver l'intégrité de la base de données, vous devez régler les paramètres d'autovacuum au niveau du cluster pour Aurora et au niveau de l'instance pour Amazon RDS, et appliquer également le même groupe de paramètres au lecteur. En cas de basculement, les mêmes paramètres doivent s'appliquer au nouveau rédacteur.
### Niveau de la table
Par exemple, dans une base de données pour la livraison de nourriture où des opérations DML continues sont attendues sur une seule table appelée`orders`, vous devez envisager de régler le `autovacuum_analyze_threshold` paramètre au niveau de la table à l'aide de la commande suivante :
```
ALTER TABLE SET (autovacuum_analyze_threshold = )
```
### Utilisation de réglages d'aspiration automatique agressifs au niveau de la table
L'exemple de `orders` table comportant des opérations de mise à jour et de suppression continues devient un candidat à l'aspiration en raison des paramètres d'aspiration automatique par défaut. Cela entraîne une mauvaise génération de plans et des requêtes lentes. L'élimination du problème et la mise à jour des statistiques nécessitent des paramètres d'autovaccum agressifs au niveau de la table.
Pour déterminer les paramètres, suivez la durée des requêtes exécutées sur cette table et identifiez le pourcentage d'opérations DML qui entraînent des modifications du plan. La `pg_stat_user_tables` vue vous permet de suivre les opérations d'insertion, de mise à jour et de suppression.
Exemple :
Supposons que l'optimiseur génère de mauvais plans chaque fois que 5 % de la `orders` table change. Dans ce cas, vous devez modifier le seuil du facteur d'échelle à 2 % comme suit :
```
ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.02)
```
**Astuce**
Sélectionnez soigneusement les réglages d'aspiration automatique agressifs pour éviter une consommation élevée de ressources.
Pour plus d’informations, consultez les ressources suivantes :
+ [Comprendre l'autovacuum dans les environnements Amazon RDS for](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)AWS PostgreSQL (article de blog)
+ [Aspiration automatique](https://www.postgresql.org/docs/17/runtime-config-autovacuum.html) (documentation PostgreSQL)
+ [Réglage des paramètres PostgreSQL dans Amazon RDS et Amazon AWS Aurora](https://docs.aws.amazon.com//prescriptive-guidance/latest/tuning-postgresql-parameters/) (directives prescriptives)
Pour vous assurer que l'aspirateur automatique fonctionne efficacement, surveillez régulièrement les lignes mortes, l'utilisation du disque et la dernière fois que l'aspirateur automatique `ANALYZE` a été exécuté ou exécuté. La `pg_stat_all_tables` vue fournit des informations sur chaque table (`relname`) et sur le nombre de tuples morts (`n_dead_tup`) qu'elle contient.
La surveillance du nombre de tuples morts dans chaque table, en particulier dans les tables fréquemment mises à jour, vous permet de déterminer si les processus d'autovacuum suppriment régulièrement les tuples morts afin que leur espace disque puisse être réutilisé pour de meilleures performances. Vous pouvez utiliser la requête suivante pour vérifier le nombre de tuples morts et la date à laquelle le dernier autovacuum a été exécuté sur les tables :
```
SELECT
relname AS TableName,n_live_tup AS LiveTuples,n_dead_tup AS DeadTuples,
last_autovacuum AS Autovacuum,last_autoanalyze AS Autoanalyze_FROM
pg_stat_user_tables;
```
## Avantages et limites
Autovacuum offre les avantages suivants :
+ Il élimine automatiquement le gonflement des tables.
+ Cela empêche l'encapsulation des identifiants de transaction.
+ Il tient à jour les statistiques de la base de données.
Limites:
+ Si les requêtes utilisent le traitement parallèle, le nombre de processus de travail risque de ne pas être suffisant pour Autovacuum.
+ Si Autovacuum fonctionne pendant les heures de pointe, l'utilisation des ressources peut augmenter. Vous devez ajuster les paramètres pour résoudre ce problème.
+ Si les pages du tableau sont occupées au cours d'une autre session, Autovacuum peut ignorer ces pages.
+ Autovacuum ne peut pas accéder aux tables temporaires.