Configurazione di un ambiente ottimale per PostgreSQL

Benvenuto in PostgreSQL, un potente sistema di database open source in grado di ospitare qualsiasi cosa, da pochi megabyte di dati dei clienti per un'azienda di piccole città, a centinaia di terabyte di "big data" per le multinazionali. Indipendentemente dall'applicazione, è probabile che sarà necessario un aiuto per l'installazione e la configurazione per preparare il database all'azione.

Quando viene installato un nuovo server, le impostazioni di PostgreSQL sono minime poiché sono progettate per funzionare con la minor quantità di hardware possibile. Tuttavia sono molto raramente ottimali. Qui analizzeremo una configurazione di base per i nuovi progetti e come impostare PostgreSQL per funzionare in modo ottimale sui nuovi progetti.

Ospitare

Hosting in loco

Con un database in loco, l'opzione migliore è per un host bare metal, poiché le macchine virtuali generalmente funzionano più lentamente a meno che non si parli di VM di livello aziendale di fascia alta. Ciò consente anche un controllo più stretto sulle impostazioni di CPU, memoria e disco. Ciò, tuttavia, deriva dalla necessità di avere un esperto a disposizione (o un contratto) per eseguire la manutenzione del server.

Nuvola

Ospitare un database nel cloud può essere meraviglioso per alcuni aspetti o un incubo per altri. A meno che la piattaforma cloud scelta non sia altamente ottimizzata (che in genere significa un prezzo più elevato), potrebbe avere problemi con ambienti di carico più elevati. Tieni d'occhio se il server cloud è condiviso o dedicato (dedicato che consente prestazioni complete dal server per l'applicazione), nonché il livello di IOPS (Operazioni di input/output al secondo) fornito da un server cloud. Quando (o se) l'applicazione cresce al punto che la maggior parte dei dati non può essere archiviata in memoria, la velocità di accesso al disco è fondamentale.

Configurazione generale dell'host

I pilastri principali necessari per configurare PostgreSQL in modo affidabile si basano sulle capacità di CPU, memoria e disco dell'host. A seconda delle esigenze delle applicazioni, un host sufficiente e una configurazione PostgreSQL ben ottimizzata avranno un impatto straordinario sulle prestazioni del sistema di database.

Scelta di un sistema operativo

PostgreSQL può essere compilato sulla maggior parte dei sistemi operativi simili a Unix, nonché su Windows. Tuttavia, le prestazioni su Windows non sono nemmeno paragonabili a un sistema simile a Unix, quindi, a meno che non si tratti di un piccolo progetto usa e getta, attenersi a un sistema simile a Unix consolidato sarà la strada da percorrere. Per questa discussione, ci atterremo ai sistemi basati su Linux.

La distribuzione Linux apparentemente più utilizzata per l'hosting di PostgreSQL è un sistema basato su Red Hat, come CentOS o Scientific Linux, o anche lo stesso Red Hat. Poiché Red Hat e CentOS si concentrano sulla stabilità e sulle prestazioni, la comunità dietro questi progetti lavora duramente per assicurarsi che le applicazioni importanti, come i database, utilizzino la build di Linux più sicura e affidabile possibile.

NOTA:Linux ha una gamma di versioni del kernel che non sono ottimali per l'esecuzione di PostgreSQL, quindi è altamente consigliato evitarle se possibile (specialmente su applicazioni in cui le massime prestazioni sono la massima importanza). I benchmark hanno mostrato che il numero di transazioni al secondo diminuisce dalla versione del kernel 3.4 – 3.10, ma si ripristina e migliora significativamente nel kernel 3.12. Questo purtroppo esclude l'utilizzo di CentOS 7 se si utilizza il percorso CentOS. CentOS 6 è ancora una versione valida e supportata del sistema operativo e si prevede che CentOS 8 venga rilasciato prima che la 6 non diventi più supportata.

Installazione

L'installazione può essere eseguita sia dal sorgente, sia utilizzando repository gestiti dalla distribuzione di Linux scelta o, meglio ancora, dal PostgreSQL Global Development Group (PGDG), che gestisce repository per sistemi basati su Red Hat (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux e Fedora), nonché pacchetti per Debian e Ubuntu. L'utilizzo dei pacchetti PGDG garantirà che gli aggiornamenti di PostgreSQL siano disponibili per l'aggiornamento al momento del rilascio, anziché attendere che i repository integrati della distribuzione Linux li approvino e li forniscano.

CPU

Al giorno d'oggi, non è difficile avere più core disponibili per un host di database. PostgreSQL stesso ha iniziato solo di recente ad aggiungere funzionalità multi-threading a livello di query e negli anni a venire migliorerà molto. Ma anche senza questi nuovi e imminenti miglioramenti, PostgreSQL stesso genera nuovi thread per ogni connessione al database da parte di un client. Questi thread utilizzeranno essenzialmente un core quando sono attivi, quindi il numero di core richiesti dipenderà dal livello di connessioni simultanee e query simultanee necessarie.

Una buona base per iniziare è un sistema a 4 core per una piccola applicazione. Supponendo che le applicazioni eseguano una danza tra l'esecuzione delle query e la sospensione, un sistema a 4 core può gestire un paio di dozzine di connessioni prima di essere sovraccaricato. L'aggiunta di più core consentirà di scalare con un carico di lavoro crescente. Non è raro che database PostgreSQL di grandi dimensioni abbiano più di 48 core per servire molte centinaia di connessioni.

Suggerimenti per l'ottimizzazione: Anche se è disponibile l'hyper-threading, le transazioni al secondo sono generalmente più elevate quando l'hyper-threading è disabilitato. Per le query di database che non sono troppo complesse, ma con una frequenza maggiore, più core sono più importanti di core più veloci.

Memoria

La memoria è un aspetto estremamente importante per le prestazioni complessive di PostgreSQL. L'impostazione principale per PostgreSQL in termini di memoria è shared_buffers, che è un pezzo di memoria allocato direttamente al server PostgreSQL per la memorizzazione nella cache dei dati. Maggiore è la probabilità che i dati necessari vivano in memoria, più rapidamente vengono restituite query e query più rapide significano una configurazione del core della CPU più efficiente, come discusso nella sezione precedente.

Le query, inoltre, a volte richiedono memoria per eseguire operazioni di ordinamento sui dati prima che vengano restituiti al client. Questo utilizza memoria ad hoc aggiuntiva (separata da shared_buffers) o file temporanei su disco, che è molto più lento.

Suggerimenti per l'ottimizzazione: Un punto di partenza di base per impostare shared_buffers è impostarlo su 1/4 del valore della ram di sistema disponibile. Ciò consente al sistema operativo di eseguire anche la propria memorizzazione nella cache dei dati, nonché qualsiasi processo in esecuzione diverso dal database stesso.

L'aumento di work_mem può accelerare le operazioni di ordinamento, tuttavia un aumento eccessivo può costringere l'host a esaurire la memoria del tutto, poiché il valore impostato può essere emesso parzialmente o completamente più volte per query. Se più query richiedono più blocchi di memoria per l'ordinamento, è possibile aggiungere rapidamente più memoria di quella disponibile sull'host. Tienilo basso e alzalo lentamente finché le prestazioni non sono dove desiderato.

Usando il comando 'free' (come 'free -h'), imposta la dimensione_cache_effettiva sulla somma della memoria libera e memorizzata nella cache. Ciò consente al pianificatore di query di sapere il livello di memorizzazione nella cache del sistema operativo potrebbe essere disponibile ed eseguire piani di query migliori.

Disco

Le prestazioni del disco possono essere una delle cose più importanti da considerare durante la configurazione di un sistema. Le velocità di input/output sono importanti per carichi di dati di grandi dimensioni o per il recupero di enormi quantità di dati da elaborare. Determina anche la velocità con cui PostgreSQL può sincronizzare la memoria con il disco per mantenere il pool di memoria ottimale.

Una certa preparazione nei dischi può aiutare a migliorare istantaneamente le prestazioni potenziali, oltre a rendere il sistema di database a prova di futuro per la crescita.

• Dischi separati

  Una nuova installazione di PostgreSQL creerà la directory dei dati del cluster da qualche parte sull'unità principale (e possibilmente unica) disponibile sul sistema.

  Una configurazione di base che utilizza più unità sarebbe l'aggiunta di un'unità separata (o set di unità tramite RAID). Ha il vantaggio di avere tutti i trasferimenti di dati relativi al database che operano su un canale I/O diverso dal sistema operativo principale. Consente inoltre al database di crescere senza timore che lo spazio insufficiente causi problemi ed errori in altre parti del sistema operativo.

  Per i database con una quantità estrema di attività, la directory PostgreSQL Transaction Log (xlog) può essere posizionata su un'altra unità, separando I/O più pesanti su un altro canale lontano dal sistema operativo principale e dalla directory dei dati principale. Questa è una misura avanzata che aiuta a ottenere più prestazioni da un sistema, che altrimenti potrebbe essere vicino ai suoi limiti.

• Utilizzo di RAID

  La configurazione del RAID per le unità del database non solo protegge dalla perdita di dati, ma può anche migliorare le prestazioni se si utilizza la corretta configurazione RAID. RAID 1 o 10 sono generalmente considerati i migliori e 10 offre parità e velocità complessiva. RAID 5, tuttavia, pur avendo livelli di ridondanza più elevati, soffre di un calo significativo delle prestazioni a causa del modo in cui distribuisce i dati su più dischi. Pianifica la migliore opzione disponibile con molto spazio per la crescita dei dati e questa sarà una configurazione che non dovrà essere modificata spesso, se non del tutto.

• Utilizzo di SSD

  Le unità a stato solido sono eccezionali per le prestazioni e, se soddisfano il budget, le unità SSD aziendali possono rendere più veloci i carichi di lavoro di elaborazione dati pesanti notte e giorno. Database di dimensioni medio-piccole con carichi di lavoro medio-piccoli possono essere eccessivi, ma quando si lotta per il più piccolo aumento percentuale su applicazioni di grandi dimensioni, SSD può essere il proiettile d'argento.

Suggerimenti per l'ottimizzazione: Scegli una configurazione dell'unità che sia la migliore per l'applicazione in questione e abbia molto spazio per crescere nel tempo man mano che i dati aumentano.

Se si utilizza un SSD, l'impostazione di random_page_cost su 1.5 o 2 (il valore predefinito è 4) sarà vantaggioso per il pianificatore di query, poiché il recupero casuale dei dati è molto più rapido di quanto visto sui dischi rotanti.

Impostazioni di configurazione iniziale

Quando si configura PostgreSQL per la prima volta, ci sono alcune impostazioni di configurazione che possono essere facilmente modificate in base alla potenza dell'host. Poiché l'applicazione interroga il database nel tempo, è possibile eseguire un'ottimizzazione specifica in base alle esigenze dell'applicazione. Tuttavia, questo sarà l'argomento di un blog di ottimizzazione separato.

Impostazioni memoria

shared_buffers:impostato su 1/4 della memoria di sistema. Se il sistema ha meno di 1 GB di memoria totale, impostare ~ 1/8 della memoria totale del sistema

work_mem:l'impostazione predefinita è 4 MB e potrebbe anche essere sufficiente per l'applicazione in questione. Ma se i file temporanei vengono creati spesso e quei file sono abbastanza piccoli (decine di megabyte), potrebbe valere la pena aumentare questa impostazione. Un'impostazione di livello base conservativo può essere (1/4 della memoria di sistema / max_connections). Questa impostazione dipende fortemente dal comportamento effettivo e dalla frequenza delle query al database, quindi dovrebbe essere aumentata solo con cautela. Preparati a riportarlo ai livelli precedenti in caso di problemi.

Effective_cache_size:Imposta la somma della memoria libera e memorizzata nella cache segnalata dal comando 'free'.

Impostazioni checkpoint

Per PostgreSQL 9.4 e versioni precedenti:
checkpoint_segments:un numero di segmenti di checkpoint (16 megabyte ciascuno) per fornire il sistema Write Ahead Log. Il valore predefinito è 3 e può essere tranquillamente aumentato a 64 per database anche piccoli.

Per PostgreSQL 9.5 e versioni successive:
max_wal_size:questo ha sostituito checkpoint_segments come impostazione. L'impostazione predefinita è 1 GB e può rimanere qui fino a quando non saranno necessarie ulteriori modifiche.

Sicurezza

listen_address:questa impostazione determina su quali indirizzi IP personali/schede di rete ascoltare le connessioni. In una configurazione semplice, probabilmente ce ne sarà solo una, mentre le reti più avanzate potrebbero avere più schede per connettersi a più reti. * Significa ascoltare tutto. Tuttavia, se l'applicazione che accede al database deve risiedere sullo stesso host del database stesso, è sufficiente mantenerlo come "localhost".

Registrazione

Alcune impostazioni di registrazione di base che non sovraccaricano i registri sono le seguenti.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0