Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Sur une instance de production j'ai remarqué que l'archivage (via pgbackrest) était trop lent en cas de forte activité.
Cela provoque un remplissage du répertoire des WAL (donc en attente d'archivage).
Y a t'il des pistes à étudier pour accélérer l'archivage ?
conf pgbackrest :
[global]
repo1-path=/mon_path_backup/
log-level-console=info
start-fast=y
process-max=6
[IPDHCX1]
pg1-path=/mon_path_admin/
repo1-retention-full-type=time
repo1-retention-full=28
repo1-retention-archive-type=full
quelques conf postgresql.conf :
name | setting
------------------------------+-----------
archive_command | /usr/bin/pgbackrest --stanza=IPDHCX1 archive-push %p
archive_mode | on
archive_timeout | 3600
default_text_search_config | pg_catalog.french
gin_fuzzy_search_limit | 0
max_standby_archive_delay | 30000
max_wal_senders | 2
max_wal_size | 20480
min_wal_size | 100
wal_block_size | 8192
wal_buffers | 1024
wal_compression | off
wal_consistency_checking |
wal_keep_segments | 0
wal_level | replica
wal_log_hints | off
wal_receiver_status_interval | 10
wal_receiver_timeout | 60000
wal_retrieve_retry_interval | 5000
wal_segment_size | 16777216
wal_sender_timeout | 60000
wal_sync_method | fdatasync
wal_writer_delay | 200
wal_writer_flush_after | 128
check_function_bodies | on
checkpoint_completion_target | 0.5
checkpoint_flush_after | 32
checkpoint_timeout | 300
checkpoint_warning | 30
data_checksums | off
ignore_checksum_failure | off
log_checkpoints | on
wal_consistency_checking |
Postgresql v11.10
pgbackrest v2.27
pas de traces dans les traces PostgreSQL de checkpoint trop fréquents.
Merci à tous par avance.
Dernière modification par ruizsebastien (14/12/2020 08:46:29)
Cordialement,
Sébastien.
Hors ligne
Sans savoir ce qui bloque c'est impossible de répondre. Il faut savoir si c'est le réseau qui ne suit pas, ou si c'est la production d'archives.
Vous pouvez toujours augmenter le nombre de processus, ou bien utiliser un algorithme de compression plus rapide (mettre compress-type à zst ça peut être un bon point de départ)
Marc.
Hors ligne
bonjour Marc,
Une chose est sûr ce n'est pas le réseau (c'est à ça qu'on a pensé en premier en tant que facteur de contention, mais non).
pour le nombre de processus, vous parlez de process-max de pgbackrest.conf ? ça entre en jeu dans l'archivage ?
Pourtant dans les traces postgresql en peut voir qu'un seul processus (P00) est utilisé dans l'archivage.
Cordialement,
Sébastien.
Hors ligne
ah. oui, comme écrit dans la doc, "Asynchronous operation is more efficient because it can reuse connections and take advantage of parallelism". mettez déjà "archive-async=y" . il vous faudra certainement aussi définir un spool-path
Marc.
Hors ligne
oh mais "archive-async=y" ça m'a l'air très prometteur !!
je vais étudier ça !
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Effectivement le paramètre archive-async=y permet de paralléliser l'archivage des WAL via pgbackrest.
Avec cett config par exemple, ça marche très bien (mettre un spool-path sur le FS des WAL, c'est conseillé pour les performances dixit la doc et calibrer process-max en fonction du nb de CPU du serveur) :
[global]
epo1-path=/mon_path_backup/
log-level-console=info
start-fast=y
process-max=6
archive-async=y
spool-path=/mon_path_wal/spool
[IPHDRX1]
pg1-path=/mon_path_admin/
repo1-retention-full-type=time
repo1-retention-full=7
repo1-retention-archive-type=full
Merci Marc pour les conseils !
Dernière modification par ruizsebastien (14/12/2020 08:51:02)
Cordialement,
Sébastien.
Hors ligne
Pages : 1
