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.

Cette section décrit les facteurs qui contribuent souvent au ralentissement des performances de l'aspirateur et explique comment résoudre ces problèmes.

Aspirez de grands index

VACUUM fonctionne selon des phases séquentielles : initialisation, analyse des tas, aspiration des index et des tas, nettoyage des index, troncature des tas et nettoyage final. Pendant le scan en tas, le processus élague les pages, les défragmente et les fige. Une fois l'analyse du tas terminée, VACUUM nettoie les index, renvoie les pages vides au système d'exploitation et effectue les dernières tâches de nettoyage, telles que le nettoyage de la carte de l'espace libre et la mise à jour des statistiques.

L'aspiration de l'index peut nécessiter plusieurs passages lorsque maintenance_work_mem (ouautovacuum_work_mem) est insuffisante pour traiter l'index. Dans PostgreSQL 16 et versions antérieures, une limite de mémoire de 1 Go pour le stockage des IDs tuples morts imposait souvent des transmissions multiples sur des index volumineux. PostgreSQL 17 TidStore introduit, qui alloue de la mémoire de manière dynamique au lieu d'utiliser un tableau à allocation unique. Cela permet de supprimer la contrainte de 1 Go, d'utiliser la mémoire de manière plus efficace et de réduire le besoin de plusieurs analyses d'index pour chaque index.

Les index volumineux peuvent toujours nécessiter plusieurs passes dans PostgreSQL 17 si la mémoire disponible ne permet pas de traiter l'intégralité des index en une seule fois. Généralement, les index plus grands contiennent davantage de tuples morts qui nécessitent plusieurs passes.

Détection des opérations de vide lentes

La postgres_get_av_diag() fonction peut détecter le ralentissement des opérations d'aspiration en raison d'une mémoire insuffisante. Pour plus d'informations sur cette fonction, consultez.

La postgres_get_av_diag() fonction émet les notifications suivantes lorsque la mémoire disponible n'est pas suffisante pour terminer l'aspiration de l'index en un seul passage.

rds_tools1,8

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory. 
        Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).

rds_tools1,9

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more 
        memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual 
        vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see 
        Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide
        .

Lorsque la postgres_get_av_diag() fonction identifie une opération d'aspiration lente qui nécessite plusieurs analyses d'index en raison d'une insuffisanceautovacuum_work_mem, elle génère le message suivant :

NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming. 
        For more information, see Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide.

Orientations

Vous pouvez appliquer les solutions de contournement suivantes à l'aide du manuel VACUUM FREEZE pour accélérer le gel du tableau.

Augmentez la mémoire pour passer l'aspirateur

Comme suggéré par la postgres_get_av_diag() fonction, il est conseillé d'augmenter le autovacuum_work_mem paramètre pour faire face aux contraintes de mémoire potentielles au niveau de l'instance. Bien qu'il autovacuum_work_mem s'agisse d'un paramètre dynamique, il est important de noter que pour que le nouveau paramètre de mémoire prenne effet, le démon autovacuum doit redémarrer ses serveurs de travail. Pour ce faire, procédez comme suit :

Cette approche garantit que l'allocation de mémoire ajustée est appliquée aux nouvelles opérations d'autovacuum.

Pour des résultats plus immédiats, pensez à effectuer manuellement une VACUUM FREEZE opération avec un maintenance_work_mem réglage accru au cours de votre session :

SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;

Si vous utilisez Amazon RDS et que vous constatez que vous avez besoin de mémoire supplémentaire pour prendre en charge des valeurs plus élevées pour maintenance_work_mem ouautovacuum_work_mem, envisagez de passer à une classe d'instance avec plus de mémoire. Cela peut fournir les ressources nécessaires pour améliorer les opérations d'aspiration manuelles et automatiques, ce qui se traduit par une amélioration des performances globales de l'aspirateur et des bases de données.

Désactiver INDEX_CLEANUP

Le mode manuel VACUUM de PostgreSQL version 12 et versions ultérieures permet d'ignorer la phase de nettoyage de l'index, tandis que l'aspirateur automatique d'urgence dans PostgreSQL version 14 et versions ultérieures le fait automatiquement en fonction du paramètre. vacuum_failsafe_age

Pour obtenir des conseils supplémentaires sur la gestion des index volumineux, reportez-vous à la documentation surGestion de la fonction autovacuum avec de grands index .

Aspirateur à indice parallèle

À partir de PostgreSQL 13, les index peuvent être nettoyés et nettoyés en parallèle par défaut VACUUM manuellement, avec un processus d'aspiration assigné à chaque index. Cependant, pour que PostgreSQL puisse déterminer si une opération sous vide peut être exécutée en parallèle, des critères spécifiques doivent être remplis :

Vous pouvez ajuster le max_parallel_maintenance_workers paramètre en fonction du nombre de v CPUs disponibles sur votre instance Amazon RDS et du nombre d'index sur la table afin d'optimiser le délai d'aspiration.

Pour plus d'informations, consultez Parallel vacuuming in Amazon RDS for PostgreSQL et Amazon Aurora PostgreSQL.

Trop de tables ou de bases de données pour être vidées

Comme indiqué dans la documentation The Autovacuum Daemon de PostgreSQL, le démon autovacuum fonctionne par le biais de plusieurs processus. Cela inclut un lanceur d'aspiration automatique permanent chargé de démarrer les processus de travail d'aspiration automatique pour chaque base de données du système. Le lanceur programme ces travailleurs pour qu'ils initient environ toutes les autovacuum_naptime secondes par base de données.

Avec les bases de données « N », un nouveau travailleur commence environ toutes les [autovacuum_naptime/N secondes]. Cependant, le nombre total de travailleurs simultanés est limité par le autovacuum_max_workers paramètre. Si le nombre de bases de données ou de tables à nettoyer dépasse cette limite, la base de données ou table suivante sera traitée dès qu'un travailleur sera disponible.

Lorsque de nombreuses tables ou bases de données volumineuses doivent être nettoyées simultanément, tous les opérateurs d'autovacuum disponibles peuvent être occupés pendant une période prolongée, ce qui retarde la maintenance des autres tables et bases de données. Dans les environnements où les taux de transactions sont élevés, ce goulot d'étranglement peut rapidement s'aggraver et potentiellement entraîner des problèmes de vide généraux au sein de votre instance Amazon RDS.

Lorsqu'il postgres_get_av_diag() détecte un nombre élevé de tables ou de bases de données, il fournit la recommandation suivante :

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.

Orientations

Augmenter autovacuum_max_workers

Pour accélérer l'aspiration, nous vous recommandons de régler le autovacuum_max_workers paramètre afin de permettre à un plus grand nombre d'aspirateurs automatiques de travailler simultanément. Si les problèmes de performances persistent, envisagez de faire évoluer votre instance Amazon RDS vers une classe contenant plus de vCPUs, ce qui peut améliorer encore les capacités de traitement parallèle.

Un aspirateur agressif (pour éviter tout enroulement) fonctionne

L'âge de la base de données (MaximumUsedTransactionIDs) dans PostgreSQL ne diminue que lorsqu'un vide agressif (pour empêcher toute encapsulation) est terminé avec succès. Jusqu'à ce que ce vide soit terminé, l'âge continuera d'augmenter en fonction du taux de transaction.

La postgres_get_av_diag() fonction génère ce qui suit NOTICE lorsqu'elle détecte un vide agressif. Cependant, il ne déclenche cette sortie qu'après que le vide a été actif pendant au moins deux minutes.

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.

Pour plus d'informations sur l'aspirateur agressif, voir Lorsqu'un aspirateur agressif fonctionne déjà.

Vous pouvez vérifier si un aspirateur agressif est en cours à l'aide de la requête suivante :

SELECT
    a.xact_start AS start_time,
    v.datname "database",
    a.query,
    a.wait_event,
    v.pid,
    v.phase,
    v.relid::regclass,
    pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
    (
        SELECT
            string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS index_sizes,
    trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
    v.index_vacuum_count || '/' || (
        SELECT
            count(*)
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS step2_vacuum_indexes,
    trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
    age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
    pg_stat_activity a
    INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;

Vous pouvez déterminer s'il s'agit d'un vide agressif (pour éviter toute distorsion) en vérifiant la colonne de requête dans la sortie. L'expression « pour empêcher l'enveloppement » indique qu'il s'agit d'un aspirateur agressif.

query                  | autovacuum: VACUUM public.t3 (to prevent wraparound)

Supposons, par exemple, que vous disposiez d'un bloqueur à l'âge d'un milliard de transactions et d'une table nécessitant un aspirateur agressif pour éviter toute encapsulation au même âge de transaction. De plus, il existe un autre bloqueur à l'âge de 750 millions de transactions. Après avoir éliminé le bloqueur à l'âge d'un milliard de transactions, l'âge des transactions ne tombera pas immédiatement à 750 millions. Il restera élevé jusqu'à ce que la table nécessitant un vide agressif ou toute transaction portant sur un âge de plus de 750 millions de dollars soit terminée. Pendant cette période, l'âge des transactions de votre cluster PostgreSQL continuera d'augmenter. Une fois le processus d'aspiration terminé, l'âge des transactions tombera à 750 millions, mais recommencera à augmenter jusqu'à ce que l'aspiration soit terminée. Ce cycle se poursuivra tant que ces conditions persisteront, jusqu'à ce que l'âge des transactions atteigne finalement le niveau configuré pour votre instance Amazon RDS, spécifié parautovacuum_freeze_max_age.