Vous n'êtes pas identifié(e).
Pages : 1
J'ai une base qui génère je trouve beaucoup d'archives, surtout trop fréquemment :
-rw------- 1 postgres postgres 16777216 sep 13 14:06 000000010000000100000060
-rw------- 1 postgres postgres 16777216 sep 13 14:07 000000010000000100000061
-rw------- 1 postgres postgres 16777216 sep 13 14:08 000000010000000100000062
-rw------- 1 postgres postgres 16777216 sep 13 14:10 000000010000000100000063
-rw------- 1 postgres postgres 16777216 sep 13 14:11 000000010000000100000064
-rw------- 1 postgres postgres 16777216 sep 13 14:12 00000001000000010000006
et cela sur presque toute la journée, 1 wall d'archive par minute. il me semble que cette fréquence est trop importante.
Je me suis dit qu'augmenter la taille des wall était une solution pour réduire la fréquence de génération des wall d'archive.
J'ai vu qu'en 9 on peu faire un configure avec --with-wal-segsize mais je suis en 8 et cette solution me plairait moyennement.
Je bloque sur jouer sur le paramétrage car à priori les wall sont plein quand ils switchs
ci dessous quelques valeurs de mon postgressql.conf :
archive_command | cp "%p" "/archive/xlog_archives/%f"
archive_mode | on
archive_timeout | 0
commit_delay | 0
commit_siblings | 5
checkpoint_completion_target | 0.8
checkpoint_segments | 6
checkpoint_timeout | 300
checkpoint_warning | 30
wal_buffers | 128
wal_sync_method | fdatasync
wal_writer_delay | 200
Y-a-il une autre solution ?
Merci
Hors ligne
Les journaux de transactions dépendent de l'activité (sur laquelle vous ne pouvez pas faire grand-chose) et du nombre de CHECKPOINT (car après un CHECKPOINT, on enregistre des blocs complets pour les nouveaux blocs modifiés). Donc votre seule solution, c'est d'augmenter les paramètres checkpoint_segments et checkpoint_timeout. Essayez par exemple avec un checkpoint_segments à 20 et un checkpoint_timeout à 15 minutes.
Guillaume.
Hors ligne
Les journaux de transactions dépendent de l'activité (sur laquelle vous ne pouvez pas faire grand-chose) et du nombre de CHECKPOINT (car après un CHECKPOINT, on enregistre des blocs complets pour les nouveaux blocs modifiés). Donc votre seule solution, c'est d'augmenter les paramètres checkpoint_segments et checkpoint_timeout. Essayez par exemple avec un checkpoint_segments à 20 et un checkpoint_timeout à 15 minutes.
Bonjour,
Ça va juste retarder l’écriture des données sur disque (dans la base), cela ne va pas empêcher la génération de fichiers WAL.
Comme le dit Gleu, si la base a de l'activité (transactions), vous allez générer des fichiers WAL ...
Hors ligne
Ça ne va pas retarder l'écriture des données, ça va surtout la diminuer. Comme je l'ai dit, juste après un CHECKPOINT, PostgreSQL utilise des blocs complets (si full_page_writes est à on), y compris si l'utilisateur n'a modifié qu'un octet dans le bloc. À la seconde écriture de ce bloc, PostgreSQL n'enregistre que le delta. Donc, plus on fait de CHECKPOINT, plus on a d'écritures dans les journaux. Du coup, plus on espace les CHECKPOINT, moins on fait d'écritures.
Guillaume.
Hors ligne
Super, merci pour vos réponses qui me permettent de mieux comprendre le mécanisme.
Hors ligne
Pages : 1