Forums PostgreSQL.fr

ruizsebastien

Membre

[RESOLU] pgbackrest archive push trop lent

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.

Marc Cousin

Membre

Re : [RESOLU] pgbackrest archive push trop lent

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.

ruizsebastien

Membre

Re : [RESOLU] pgbackrest archive push trop lent

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.

Marc Cousin

Membre

Re : [RESOLU] pgbackrest archive push trop lent

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.

ruizsebastien

Membre

Re : [RESOLU] pgbackrest archive push trop lent

oh mais "archive-async=y" ça m'a l'air très prometteur !!
je vais étudier ça !

---

Cordialement,

Sébastien.

ruizsebastien

Membre

Re : [RESOLU] pgbackrest archive push trop lent

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.