Uno dei bit più utili della
documentazione PostgreSQL su cui abbia mai lavorato è l'ottimizzazione del server PostgreSQL
. Quando è stato scritto nell'estate del 2008, pochi mesi dopo il
rilascio di PostgreSQL 8.3, era difficile trovare una guida simile che
era sia (relativamente) concisa che attuale. Da allora, io e
molti altri contributori di PostgreSQL abbiamo contribuito a mantenere aggiornato quel documento
fino a quando sono state apportate modifiche a PostgreSQL.
La tendenza interessante e utile
durante quel periodo è che i parametri continuano a scomparire dall'insieme
di quelli di cui devi preoccuparti. In PostgreSQL 8.2, c'era un lungo
elenco di parametri che probabilmente dovevi regolare per ottenere buone prestazioni
su un server PostgreSQL:shared_buffers, Effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers e (se si utilizza
partizionamento) constraint_exclusion.
8.3 ha attivato l'autovacuum per impostazione predefinita
con un comportamento ragionevole, oltre a rimuoverne alcuni
parametri dello scrittore in background che non hanno causato altro che problemi (non
non sono mai entrati nell'elenco). 8.4 ha eliminato la necessità dei due parametri
max_fsm_*, aumentato default_statistics_target a un valore iniziale molto
migliore e reso l'impostazione di constraint_exclusion
non necessaria nei casi più comuni. Sono sei parametri in meno
che probabilmente dovrai regolare.
Purtroppo la versione 9.0 ha solo reso
più complicata la configurazione del server. Inoltre, i kernel Linux più recenti
hanno persino spostato il comportamento predefinito all'indietro. A partire dal kernel Linux
2.6.33, il valore predefinito selezionato per wal_sync_method è cambiato in
open_datasync. Questo risulta avere terribili implicazioni in termini di prestazioni
per PostgreSQL, in particolare se combinato con l'impostazione predefinita
bassa per wal_buffers nel server.
Ma la marcia verso un migliore default
comportamento è recentemente ripreso per quello che alla fine dovrebbe essere
PostgreSQL 9.1. Durante l'ultimo CommitFest, Marti ha creato una patch
Raudsepp per risolvere il problema wal_sync_method
dopo alcune pesanti discussioni su quale forma dovrebbe assumere quella modifica.
Scoprire che questa modifica del comportamento ha interrotto completamente PostgreSQL
durante l'esecuzione su ext4 con l'opzione "data=journal" ha aiutato
definire la cosa giusta da fare qui per impostazione predefinita.
Due parametri che non consiglio
di toccare nella maggior parte dei casi sono commit_siblings e commit_delay,
artefatti di un precedente tentativo di migliorare le prestazioni su sistemi con
tempi di commit lenti (che include la maggior parte dei sistemi che non dispongono di una
cache di scrittura con batteria tampone per accelerare quell'area). Al giorno d'oggi
disattivare il parametro synchronous_commit introdotto in 8.3 è
molto più probabile che aiuti qui. Sebbene sia improbabile che questi migliorino
le prestazioni, le persone che provano a impostarli hanno sofferto più del
necessario gli aspetti negativi di tale decisione. Il comportamento nel peggiore dei casi
in questo caso è stato notevolmente migliorato in una patch che ho scritto per ottimizzare il modo in cui viene eseguita la logica di controllo di quei parametri.
E questa settimana l'ultimo parametro da
essere effettivamente eliminato nella maggior parte dei casi è wal_buffers. Una modifica che
suggerito è stata impegnata a impostarla automaticamente come percentuale della dimensione (circa il 3%)
allocata ai parametri shared_buffers normalmente molto più grandi.
Questo imposta il valore di wal_buffers su limite superiore normale del suo
intervallo effettivo, 16 MB, una volta assegnati almeno 512 MB a
shared_buffers. E se hai aumentato shared_buffers dal suo minuscolo
default, otterrai un corrispondente miglioramento in questo
importante parametro delle prestazioni del commit. Dovrai fare di tutto
per interrompere l'impostazione di questo parametro per colpire le cattive
situazioni possibili nelle versioni precedenti.
Avere la quantità di configurazione che
devi fare al server per impostazione predefinita diventa meno complicata è sempre
è utile e vedere i parametri scomparire dall'elenco delle criticità è
un cambiamento gradito. Qual è il prossimo? I problemi principali con l'allocazione
della memoria condivisa su sistemi operativi derivati da UNIX, in particolare Linux,
rendono molto difficile l'eliminazione dei buffer_condivisi. E le preoccupazioni
per il fatto che il server prenda il controllo del sistema limitano del tutto la capacità
di impostare automaticamente parametri come work_mem nell'intervallo corretto.
Alcune proposte per una migliore gestione del pool di memoria di lavoro sono state
suggerito, in modo che si possa vedere qualche miglioramento.
Il prossimo parametro che tengo d'occhio è
checkpoint_segments. Dopo aver aggiunto solo registrazioni extra in quest'area durante
l'ultimo CommitFest, ci sono alcuni miglioramenti in quest'area che si avvicinano a
impegnati ora per migliorare effettivamente il comportamento dei checkpoint. Spero di
alla fine passare dall'ottimizzazione del checkpoint in modo che sia rigorosamente controllata
tramite parametri orientati al tempo, piuttosto che richiedere agli utenti di
comprendere i meccanismi di come funziona il registro write-ahead per ottimizzare il
sistema. Ci sono ancora troppe brutte situazioni possibili qui da fare
in tempo per 9.1, ma impostare automaticamente il conteggio dei segmenti è
possibile puntare a 9.2.
