Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous.
J'ai quelques problèmes avec le process autovacuum sur une de mes tables. Je m'explique ...
Depuis une semaine, j'ai reconstruit la totalité de ma base de données.
En effet, j'avais jusque là laissé les paramètres par défaut concernant les paramètres autovacuum.
Or vu le volume de certaines d'entre elles (3 culminent à 600, 300 et 120 millions de lignes) et la quantité de lignes modifiées quotidiennement, le process autovaccum n'était jamais passé !
Au bout de qqs semaines d'utilisation j'ai noté des dégradations sur les performances, notamment en écriture.
Ainsi, j'ai fait des stats quotidiennes (en scrutant la table pg_stats_user_tables) et ai modifié en conséquence, pour les 3 tables citées, les paramètres autovacuum_vacuum_scale_factor et autovacuum_analyze_scale_factor afin d'obtenir un passage quasi-quotidien des process de nettoyage et d'analyse.
Depuis une semaine, 2 des 3 trois tables ont été analysées puis nettoyées. Sur la dernière H_V1, le quota vacuum fixé (scale_factor modifié, threshold laissé par défaut) a bien été dépassé (n_tup_upd +n_tup_del =728.538 contre 140.000 pour le seuil) , le process autovaccum est lancé mais semble être inactif depuis qqs jours (cf listing).
LISTING1 : table H_V1 - 280M lignes - autovaccum réglé pour 140.000 lignes env.
=============================================================
postgres=# select * from pg_stat_activity ;
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
-------+----------+---------+----------+----------+----------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+-------------+-------------
16385 | bdcp | 3018 | 10 | postgres | autovacuum: VACUUM obs.h_v1 | f | 2010-05-06 10:33:27.627509+00 | 2010-05-06 10:33:27.627509+00 | 2010-05-06 .........
11564 | postgres | 24920 | 10 | postgres | select * from pg_stat_activity ; | f | 2010-05-12 13:01:04.16843+00 | 2010-05-12 13:01:04.16843+00 | 2010-05-12 .......
bdcp=> select schemaname,relname,n_tup_ins,n_tup_upd,n_tup_del,n_dead_tup,last_vacuum,last_autovacuum,last_analyze,last_autoanalyze
from pg_stat_user_tables where relname like 'h_v%';
schemaname | relname | n_tup_ins | n_tup_upd | n_tup_del | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
-------------------------+-----------+-----------+-----------+------------+-------------+-----------------+--------------+-------------------------------
obs | h_v1 | 288157136 | 0 | 728538 | 686634 | | | | 2010-05-06 10:29:51.321024+00
(1 row)
bdcp=> select relname,reltype,relpages,reltuples,relacl,reloptions from pg_class where relname like 'h_v%';
relname | reltype | relpages | reltuples | reloptions
-----------+---------+----------+-------------+---------------------------------------------------+--------------------------------------------------------------------------------
h_v1 | 326354 | 5774704 | 2.86477e+08 | {autovacuum_vacuum_scale_factor=0.0005,autovacuum_analyze_scale_factor=0.0005}
(2 rows)
Il y-a-t-il un moyen de savoir l'état de progression du process ?
Je n'ai aucun retour dans la log pour savoir si le process a été endormi par le postmaster ? A-t-il dépassé un seuil ?
Merci de m'éclairer sur le sujet si vous avez des infos.
David.
Dernière modification par David (12/05/2010 15:29:32)
Hors ligne
Il y-a-t-il un moyen de savoir l'état de progression du process ?
Non, aucun.
Je n'ai aucun retour dans la log pour savoir si le process a été endormi par le postmaster ? A-t-il dépassé un seuil ?
Sur une semaine, ce serait étonnant. Vérifiez néanmoins vos paramètres vacuum_cost_delay et autovacuum_vacuum_vost_delay.
Guillaume.
Hors ligne
Voici qqs paramètres.
J'aimerai avoir un peu plus d'infos sur le calibrage du paramètre cost_limit ?
postgres=# show vacuum_cost_delay;
vacuum_cost_delay
-------------------
0
postgres=# show autovacuum_vacuum_cost_delay ;
autovacuum_vacuum_cost_delay
------------------------------
20ms
postgres=# show autovacuum_vacuum_cost_limit
postgres-# ;
autovacuum_vacuum_cost_limit
------------------------------
-1
(1 row)
postgres=# show vacuum_cost_limit
;
vacuum_cost_limit
-------------------
200
(1 row)
Hors ligne
La table semble faire 44 Go. Avec un cost_delay à 20ms et en considérant que la table est entièrement en mémoire, le VACUUM va attendre 9h à ne rien faire, juste pour laisser les autres programmes accéder au disque. Le VACUUM durera 9h plus tout le temps nécessaire pour parcourir et traiter les 44 Go de cette table.
Dans le pire des cas (table sur disque), l'attente sera plutôt de 90h, soit pratiquement 4 jours.
Bref, un cost_delay à 20ms avec un cost_limit à 200 pour cette table, c'est du suicide. Deux possibilités, virer le cost_delay ou avoir un cost_limit beaucoup plus gros.
Guillaume.
Hors ligne
Bonjour,
Pouvez-vous m'expliquer comment vous estimez le temps que prend un vacuum ?
Cordialement,
Hors ligne
Il n'y a pas de moyen pour estimer le temps que va prendre le VACUUM lui-même. Par contre, le délai supplémentaire imparti par les paramètres de coût du VACUUM est quantifiable sur une fourchette (meilleur cas, pire cas). Le calcul se fait en multipliant le délai par le coût de trouver un bloc en cache multiplié par le nombre de blocs (ie vacuum_cost_delay * vacuum_cost_page_hit / vacuum_cost_page_limit * nb blocs pour le meilleur cas). Si je reprends l'exemple ci-dessus 20 * 1 / 200 * (44 * 1024 * 1024 / 8), soit 576 secondes, soit un peu plus de 9h d'attente. Auquel il faut ajouter le temps de réaliser le VACUUM qui lui est difficilement quantifiable.
Guillaume.
Hors ligne
Merci pour votre explication.
Hors ligne
Bonjour gleu,
comment pouvez vous savoir que la table fait 44GB.
Pouriez vous expliquer un peu plus votre estimation ( surtout la division )
Hors ligne
La colonne relpages de la table pg_class pour la table indique 5774704. Ce sont des blocs de 8 Ko par défaut. Ce qui nous fait 44 Go. C'est évidemment une estimation mais elle devrait être assez proche de la réalité.
Guillaume.
Hors ligne
Pages : 1
