Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai un pb d'autovacuum, sur des suppression massives il semble qu'il s'arrête d'analyser une table ( celle ou il y a les suppressions ). Si je relance le traitement de suppression au début il repasse un autovacuum puis plus rien???
Le pire c'est qu'il ne réutilise pas les lignes vides pour de nouvelle insertion ?
Insertion 767736 lignes
Taille de l'instance 5Go
Suppression 767111 lignes - lignes mortes a récupérer 757008
Table | lignes_inserees | lignes_maj | lignes_supprimees | l_vivantes | l_mortes | autovacuum | autoanalyze | last_vacuum | analyze
----------------+-----------------+------------+-------------------+------------+----------+------------------+------------------+-------------+---------
jbm_counter | 2 | 2 | 0 | 2 | 2 | | | |
jbm_user | 5 | 0 | 0 | 5 | 0 | | | |
jbm_role | 9 | 0 | 0 | 9 | 0 | | | |
jbm_id_cache | 500 | 767236 | 0 | 500 | 0 | 13/01/2010 15:23 | 13/01/2010 15:23 | |
jbm_msg | 767736 | 0 | 767111 | 7417 | 757008 | 13/01/2010 15:06 | 13/01/2010 15:02 | |
jbm_postoffice | 26 | 0 | 0 | 26 | 0 | | | |
jbm_msg_ref | 767736 | 1994168 | 767135 | 181 | 15777 | 13/01/2010 15:31 | 13/01/2010 15:31 | |
jbm_dual | 1 | 0 | 0 | 1 | 0 | | | |
jbm_tx | 0 | 0 | 0 | 0 | 0 | | | |
(9 rows)
Taille de l'instance 5Go
arret de la suppression car plus déclenchement d'autovacuum aprés 5mn de traitement
Relance de la suppression l'autovacuum libère les lignes mortes supprimé avant et laisse pour morte les nouvelles soit environ :7589
Table | lignes_inserees | lignes_maj | lignes_supprimees | l_vivantes | l_mortes | autovacuum | autoanalyze | last_vacuum | analyze
----------------+-----------------+------------+-------------------+------------+----------+------------------+------------------+-------------+---------
jbm_counter | 2 | 2 | 0 | 2 | 2 | | | |
jbm_user | 5 | 0 | 0 | 5 | 0 | | | |
jbm_role | 9 | 0 | 0 | 9 | 0 | | | |
jbm_id_cache | 500 | 767236 | 0 | 500 | 0 | 13/01/2010 15:23 | 13/01/2010 15:23 | |
jbm_msg | 767736 | 0 | 767277 | 7589 | 135 | 13/01/2010 15:36 | 13/01/2010 15:02 | |
jbm_postoffice | 26 | 0 | 0 | 26 | 0 | | | |
jbm_msg_ref | 767736 | 1994225 | 767291 | 0 | 47 | 13/01/2010 15:37 | 13/01/2010 15:37 | |
jbm_dual | 1 | 0 | 0 | 1 | 0 | | | |
jbm_tx | 0 | 0 | 0 | 0 | 0 | | | |
(9 rows)
Taille de l'instance 5Go
Relance de l'insertion massive, pas de réutilisation des lignes vide ???
Table | lignes_inserees | lignes_maj | lignes_supprimees | l_vivantes | l_mortes | autovacuum | autoanalyze | last_vacuum | analyze
----------------+-----------------+------------+-------------------+------------+----------+------------------+------------------+-------------+---------
jbm_counter | 2 | 2 | 0 | 2 | 2 | | | |
jbm_user | 5 | 0 | 0 | 5 | 0 | | | |
jbm_role | 9 | 0 | 0 | 9 | 0 | | | |
jbm_id_cache | 500 | 1666651 | 0 | 500 | 27 | 13/01/2010 16:06 | 13/01/2010 16:06 | |
jbm_msg | 1667153 | 0 | 767736 | 906547 | 594 | 13/01/2010 15:36 | 13/01/2010 15:02 | |
jbm_postoffice | 26 | 0 | 0 | 26 | 0 | | | |
jbm_msg_ref | 1667166 | 2889471 | 767736 | 899796 | 157454 | 13/01/2010 15:54 | 13/01/2010 16:06 | |
jbm_dual | 1 | 0 | 0 | 1 | 0 | | | |
jbm_tx | 0 | 0 | 0 | 0 | 0 | | | |
Taille de l'instance 9Go
conf par defaut sur l'autovaccuum
#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least that time.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20 # default vacuum cost delay for
# autovacuum, -1 means use
# vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit
PS la table jbm_msg est toasté
Merci pour vos pistes
Hors ligne
Bonjour,
Quel rapport entre les stats de pg_stat_user_table et le fait que l'espace soit réutilisé ou non ? Qu'avez vous fait exactement pour vous assurer de ce que vous affirmez ? (est-ce reproductible à chaque fois ?) Avez vous le détail de vos manipulations (le delete est fait comment ? comment l'interrompez vous ?)
Marc.
Hors ligne
Il me semble de le fait de passer l'autovacuum libère les pointeurs des lignes mortes pour pouvoir les réutiliser par la suite pour d'autre insertion.
L'espace n'est pas rendu au system, mais postgres la considère comme libre puisque le lignes n'existe plus.
Pour voir l'augmentation disque je fait un df sur le filesystem de l'instance.
Les deletes sont fais un a un par un ordre classique de delete sql sur un identifiant de pk de la table.
Hors ligne
Passer le vacuum libère les pointeurs de lignes mortes. L'autovacuum n'est qu'un moyen de déclencher vacuum quand cela devient nécessaire. Ce n'est pas parce qu'un select sur la table indique la ligne comme n'existant plus qu'elle est réellement libérée. Elle est simplement devenue invisible pour la transaction en cours. Il y a de nombreuses raisons qui peuvent faire qu'autovacuum ne se déclenche pas ou que vacuum ne puisse pas libérer des enregistrements (les deux plus fréquents étant une transaction en cours, ou une freespacemap trop petite)
Pour avancer : sur les stats on constate qu'autovacuum s'est déclenché, puisque les compteurs augmententent. N'ayant pas le détail de vos traitements ni les horodatages correspondants, je ne peux pas vous dire si ils se sont déclenchés avant ou après. Votre requête sur pg_stat_user_table ne nous éclaire pas sur ce sujet, puisqu'elle ne nous donne que les heures de traitement, et le nombre d'opérations logiques (insert, select, delete) sur la table.
Si vous voulez approfondir, et savoir exactement ce qui se trouve dans la table, je vous recommande de regarder les docs des modules de contrib suivants :
pg_freespacemap : http://docs.postgresql.fr/8.3/pgfreespacemap.html
(il permet de savoir ce qui est réutilisable dans une table, via la freespacemap)
pgstattuple : http://docs.postgresql.fr/8.3/pgstattuple.html
(il permet d'avoir des statistiques précises sur le contenu d'une table, en la scannant entièrement : enregistrements actifs, enregistrements morts, espace vide potentiellement réutilisable)
Marc.
Hors ligne
Bonjour,
Vous dite qu'une transaction en cours sur la table bloque le déclenchement de l'autovacuum ?
Je consulte les documentations et contrib merci
Hors ligne
Une transaction en cours ne bloque pas l'autovacuum. Elle fait que le vacuum lancé par la commande autovacuum ne peut pas faire le ménage correctement, puisque des enregistrement supprimés doivent rester visibles pour cette transaction. Mais commencez par analyser le problème, rien ne dit que c'est un problème de transaction longue, c'est juste une des pistes possibles.
Marc.
Hors ligne
Pages : 1
