I checkpoint si verificano troppo frequentemente durante pg_restore

In PostgreSQL 9.2.2 (Windows 32 bit), ho un pg_restorecomando che genera sistematicamente avvisi di registro sulla frequenza del checkpoint, ad esempio:

LOG:  checkpoints are occurring too frequently (17 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

Il database ha una dimensione di circa 3,3 GB con 112 tabelle / 160 visualizzazioni e ripristina in circa 14 minuti.

È normale che ciò accada durante un pg_restore?

Non insolito durante un ripristino dell'intero DB perché si tratta di un'operazione eccezionalmente enorme. Se lo vedi durante il normale funzionamento, considera di aumentare l'impostazione in modo checkpoint_segmentspermanente, proprio come i suggerimenti sul messaggio di errore.

Potresti andare al problema di impostare un valore checkpoint_segmentspiù alto appena prima del ripristino e quindi abbassarlo di nuovo. Questo è anche ciò che suggerisce il manuale (inclusa una spiegazione) :

L'aumento temporaneo della checkpoint_segmentsvariabile di configurazione può anche velocizzare il caricamento di dati di grandi dimensioni. Questo perché il caricamento di una grande quantità di dati in PostgreSQL farà sì che si verifichino checkpoint più spesso della normale frequenza di checkpoint (specificata dalla checkpoint_timeoutvariabile di configurazione). Ogni volta che si verifica un checkpoint, tutte le pagine sporche devono essere scaricate sul disco. Aumentando checkpoint_segmentstemporaneamente durante i carichi di dati in blocco, è possibile ridurre il numero di punti di controllo richiesti.

Risposta correlata con maggiori dettagli:

• Configurazione di PostgreSQL per le prestazioni di scrittura

Postgres 9.5

L'imminente nuova versione ha un approccio più intelligente. Citando le note sulla versione beta :

Sostituisci il parametro di configurazione checkpoint_segmentscon min_wal_size e max_wal_size(Heikki Linnakangas)

Ciò consente l'allocazione di un gran numero di file WAL senza conservarli se non sono necessari. Pertanto, il valore predefinito per max_wal_size è stato aumentato a 1GB.

A parte: il numero di viste è appena rilevante, quelle non contengono alcun dato, solo la "ricetta", ovvero: la query e alcuni attributi della vista. Per la domanda a portata di mano, in pratica conta solo la dimensione totale del file di backup.