Discussion :

[Pierrot le fou]

Bonjour,

Sur une de mes bases PostgreSQL (de recette), je constate une explosion du nombre de fichiers WALs (417 fichiers de 16 Mo sur 7 Go, provoquant l'arrêt de la base par manque de place sur le fs full [100 %]).
La config est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
 
# - Settings -
 
wal_level = archive                     # minimal, archive, or hot_standby
                                        # (change requires restart)
#fsync = on                             # turns forced synchronization on or off
#synchronous_commit = on                # synchronization level;
                                        # off, local, remote_write, or on
#wal_sync_method = fsync                # the default is the first option
                                        # supported by the operating system:
                                        #   open_datasync
                                        #   fdatasync (default on Linux)
                                        #   fsync
                                        #   fsync_writethrough
                                        #   open_sync
#full_page_writes = on                  # recover from partial page writes
wal_buffers = 16MB                      # min 32kB, -1 sets based on shared_buffers
                                        # (change requires restart)
#wal_writer_delay = 200ms               # 1-10000 milliseconds
 
#commit_delay = 0                       # range 0-100000, in microseconds
#commit_siblings = 5                    # range 1-1000
 
# - Checkpoints -
 
checkpoint_segments = 10                # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 5min              # range 30s-1h
#checkpoint_completion_target = 0.5     # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s               # 0 disables
 
# - Archiving -
 
archive_mode = on               # allows archiving to be done
                                # (change requires restart)
archive_command = 'test ! -f /data/C1INFGL/postgres/C1INFGL1/dbs/archivelog/%f && cp %p /data/C1INFGL/postgres/C1INFGL1/dbs/archivelog/%f'              # command to use to archive a logfile segment
                                # placeholders: %p = path of file to archive
                                #               %f = file name only
                                # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
archive_timeout = 3600          # force a logfile segment switch after this

Sur une autre base (de prod), j'ai les paramètres suivants :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
checkpoint_segments = 10                # in logfile segments, min 1, 16MB each
checkpoint_timeout = 5min               # range 30s-1h
checkpoint_completion_target = 0.9      # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s               # 0 disables
 
# - Archiving -
 
archive_mode = off              # allows archiving to be done
                                # (change requires restart)
archive_command = 'test ! -f /data/P1INFGL/postgres/P1INFGL1/dbs/archivelog/%f && cp %p /data/P1INFGL/postgres/P1INFGL1/dbs/archivelog/%f'
archive_timeout = 3600          # force a logfile segment switch after this

et là tout va bien (22 fichiers de 16 Mo sur 2.5 Go).
Les 2 bases sont alimentées exactement de la même manière, avec les mêmes données provenant de la même source, en même temps, et purgées de même.
Le(s)quel(s) de ces paramètres peu(ven)t provoquer cet engorgement ?

Merci,
Pierrot le fou.

[SQLpro]

archive_mode = on conserve tous les journaux même ceux inactifs (dont les transactions on été achevées et les données écrites).

Techniquement ce sont des "redo logs". Le fait de passer à off va réduire le nombre de journaux (purge automatique), mais vous empêchera de procéder à une restauration PITR.

A +

[Pierrot le fou]

Bonjour,

Bon, alors n'ayant technique pas besoin de restauration PITR, j'ai repris le paramétrage du serveur de prod, maintenant tout va bien.
Je suppose que la brusque augmentation des xlogs était due à l'ajout récent d'une purge automatique de la base (suivie d'un VACUUM FULL).
Je marque donc ce sujet comme étant résolu.

Merci SQLpro.

Pierrot le fou.