Cosa succede nel checkpoint PostgreSQL?

Ecco parte del mio registro del checkpoint:

2014-03-26 11:51:29.341 CDT,,,18682,,532854fc.48fa,4985,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 15047 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 30 recycled; write=68.980 s, sync=1.542 s, total=70.548 s; sync files=925, longest=0.216 s, average=0.001 s",,,,,,,,,""
2014-03-26 11:56:05.430 CDT,,,18682,,532854fc.48fa,4987,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 16774 buffers (1.6%); 0 transaction log file(s) added, 0 removed, 31 recycled; write=72.542 s, sync=17.164 s, total=89.733 s; sync files=885, longest=3.812 s, average=0.019 s",,,,,,,,,""
2014-03-26 12:01:21.650 CDT,,,18682,,532854fc.48fa,4989,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 14436 buffers (1.4%); 0 transaction log file(s) added, 0 removed, 33 recycled; write=122.350 s, sync=5.212 s, total=127.676 s; sync files=924, longest=3.740 s, average=0.005 s",,,,,,,,,""
2014-03-26 12:06:25.028 CDT,,,18682,,532854fc.48fa,4991,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 13277 buffers (1.3%); 0 transaction log file(s) added, 0 removed, 29 recycled; write=126.217 s, sync=5.733 s, total=131.991 s; sync files=894, longest=1.859 s, average=0.006 s",,,,,,,,,""
2014-03-26 12:10:41.958 CDT,,,18682,,532854fc.48fa,4993,,2014-03-18 09:15:24 CDT,,0,LOG,00000,"checkpoint complete: wrote 20765 buffers (2.0%); 0 transaction log file(s) added, 0 removed, 28 recycled; write=88.015 s, sync=10.818 s, total=98.872 s; sync files=881, longest=2.690 s, average=0.012 s",,,,,,,,,""

Ho notato che a volte il nostro database è molto lento - è possibile vedere un numero molto elevato di query normalmente brevi bloccate per molto più tempo di adesso. Succede regolarmente senza un chiaro colpevole.

Domanda: il checkpoint potrebbe causare questo? Cosa succede nella fase di "sincronizzazione" del checkpoint?

Durante il suo funzionamento, PostgreSQL registra le modifiche ai file di registro delle transazioni, ma non le scarica immediatamente nelle tabelle del database effettive. Di solito mantiene solo le modifiche in memoria e le restituisce dalla memoria quando vengono richieste, a meno che la RAM non si riempia e non debba scriverle.

Ciò significa che se si arresta in modo anomalo, le tabelle su disco non saranno aggiornate. Deve riprodurre i registri delle transazioni, applicando le modifiche alle tabelle su disco, prima di poter eseguire il backup. Questo può richiedere del tempo per un database grande e occupato.

Per questo motivo, e in modo che i registri delle transazioni non continuino a crescere per sempre, PostgreSQL esegue periodicamente un checkpoint in cui si assicura che il DB sia in uno stato pulito. Svuota tutte le modifiche in sospeso sul disco e ricicla i registri delle transazioni che sono stati utilizzati per mantenere un registro di ripristino delle modifiche.

Questo flush avviene in due fasi:

• Tamponato write()di sporco shared_buffersai tavoli; e
• fsync() dei file interessati per assicurarsi che le modifiche abbiano colpito davvero il disco

Entrambi possono aumentare il carico di I / O del disco. Le controversie causate da queste scritture possono rallentare le letture e possono anche rallentare lo svuotamento dei segmenti WAL necessari per eseguire il commit delle transazioni.

È stata una sfida di vecchia data, ma sta peggiorando quando vediamo sistemi con sempre più RAM in modo che possano bufferizzare più dati e impiegare più tempo a scriverli. C'è una discussione tra le comunità Linux e PostgreSQL su come gestirlo al momento, come discusso in questo articolo di LWN.net . (LWN.net non sarà in grado di continuare a scrivere questo tipo di ottimo lavoro se le persone non si iscrivono. Sono un abbonato e condivido questo link perché è utile e informativo. Ti preghiamo di prendere in considerazione l'abbonamento se vuoi vedere di più su questo genere di cose.)

La cosa principale che puoi fare per ridurre l'impatto dei checkpoint al momento è di diffondere l'attività del checkpoint aumentando in checkpoint_completion_targetmodo che una quantità maggiore di dati sia stata scritta al momento dell'arrivo del checkpoint finale. Questo ha un costo, tuttavia: se aggiorni una pagina (diciamo) dieci volte, potrebbe essere scritta su disco più volte prima del checkpoint con un obiettivo di completamento elevato, anche se doveva essere rigorosamente scritta una sola volta per motivi di sicurezza. Un target di completamento più elevato rende i modelli di I / O più fluidi ma un overhead di I / O più generale.

L'altra cosa che puoi fare per aiutare è dire al tuo sistema operativo di iniziare immediatamente a scrivere i dati quando vengono scritti nel buffer. Questo è come il lato kernel dell'impostazione checkpoint_completion_targete ha un compromesso simile. Vedere la documentazione vm Linux , in particolare dirty_background_bytes, dirty_background_ratio, dirty_expire_centisecs.

Svuotare i buffer del file system del SO sporchi a causa del superamento dirty_byteso dirty_ratio è un'operazione di blocco in primo piano!

I parametri sintonizzabili del kernel dirty_bytes, dirty_background_bytes, dirty_ratio, dirty_background_ratioe dirty_centisecsil controllo di vampate di calore sporchi buffer file del sistema operativo di sistema su disco. dirty_bytesè la soglia in byte, dirty_ratioè la soglia come rapporto della memoria totale. dirty_background_bytese dirty_background_ratiosono soglie simili, ma il flushing avviene in background e non blocca altre operazioni di lettura / scrittura fino al completamento. dirty_centisecsè il numero di centisecondi che può passare prima che inizi un flush.

Recentemente le impostazioni predefinite per questi parametri sintonizzabili sono state ridotte in Linux, poiché le dimensioni della memoria per le macchine moderne sono aumentate notevolmente. Anche i rapporti del 5 e 10% per dirty_background_ratioe dirty_ratiosu una macchina da 256 GB possono inondare un sistema I / O.

Sintonizzare dirty_background_byteso dirty_background_ratioiniziare a svuotare i buffer sporchi in background è complicato. Fortunatamente è possibile ottimizzare queste impostazioni senza dover arrestare PostgreSQL o l'host ripetendo i nuovi valori nei file appropriati:

$ sudo echo [int value of bytes] > /proc/sys/vm/dirty_background_bytes

ad esempio per impostare il numero di byte sporcati per attivare un flush di sfondo. Se si utilizza un condensatore-backed, o scheda di memoria flash RAID con batteria tampone (si fa desidera mantenere i dati in caso di un incidente, non è vero?) Iniziare la sintonizzazione dirty_background_bytesa 1/2 la cache di scrittura dimensione del buffer e dirty_bytesa 3/4 quella dimensione. Monitora il tuo profilo I / O con iostats e se riscontri ancora problemi di latenza, ciò significa che il carico di scrittura del database sta ancora travolgendo i flush della cache del buffer di file. Abbassa i valori fino a quando la latenza migliora o considera di aggiornare il tuo sottosistema I / O. Schede FusionIO e SSD sono due possibilità per un throughput I / O estremo.

In bocca al lupo!