Significato dei principali paramentri di configurazione del server PostgreSql presenti nel file postgresql.conf e valorizzazione consigliata per applicazioni di tipo Data Warehouse.
fsync
Se questo parametro è attivo, il server PostgreSQL proverà ad assicurarsi che gli aggiornamenti siano scritti fisicamente su disco, eseguendo chiamate di sistema fsync() o vari metodi equivalenti (si veda wal_sync_method). Questo assicura che il cluster database possa recuperare a uno stato consistente dopo un blocco del sistema operativo o dell'hardware.Mentre disabilitare fsync spesso è un beneficio in termini di prestazioni, questo può risultare in corruzione irrecuperabile dei dati in caso di blocco o arresto inaspettato del sistema. Così è consigliabile disabilitare fsync se è possibile ricreare facilmente l'intero database a partire da dati esterni.
Esempi di circostanze sicure per disabilitare fsync includono il caricamento iniziale di un nuovo cluster di database a partire da un file di backup, l'uso di un cluster per l'elaborazione di statistiche all'ora che vengono quindi ricreate, o per un clone in sola lettura del database che viene ricreato frequentemente e non viene usato per il failover. Hardware di alta qualità da solo non è sufficiente a giustificare la disabilitazione di fsync.
In molte situazioni, disabilitare synchronous_commit per le transazioni non critiche può fornire molti dei potenziali benefici equivalenti a disattivare fsync, senza i rischi collegati di corruzione di dati.
fsync può essere impostato solo nel file postgresql.conf o dalla linea di comando del server. Se di disabilita questo parametro, considerare anche la disabilitazione di full_page_writes.
Per datawarehouse valorizzato a off
synchronous_commit
Specifica se il commit della transazione aspetterà che i record WAL siano scritti su disco prima che il comando restituisca un indicazione di «successo» al client. L'impostazione predefinita, e sicura, è on. Quando impostato a off, ci può essere un ritardo tra quando viene riportato il successo al client e quando la transazione è veramente garantita essere sicura rispetto a un blocco del server. (Il massimo ritardo è tre volte wal_writer_delay). Diversamente da fsync, impostare questo parametro a off non crea nessun rischio di inconsistenza del database: un blocco del sistema operativo o del database potrebbe risultare nella perdita di alcune transazioni presumibilmente sottoposte a commit, ma lo stato del database sarà comunque lo stesso come se quelle transazioni fossero state annullate di recente. Quindi, disabilitare synchronous_commit può essere un'alternativa utile quando le prestazioni sono più importanti rispetto alla certezza assoluta sulla durabilità di una transazione.
Questo parametro può essere cambiato in qualsiasi momento; il comportamento per qualsiasi transazione è determinato dall'impostazione effettiva quando viene effettuato il commit. È inoltre possibile, e utile, avere alcune transazione che fanno il commit in modo sincrono e altre che lo fanno in modo asincrono. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction.
Questo parametro può essere cambiato in qualsiasi momento; il comportamento per qualsiasi transazione è determinato dall'impostazione effettiva quando viene effettuato il commit. È inoltre possibile, e utile, avere alcune transazione che fanno il commit in modo sincrono e altre che lo fanno in modo asincrono. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction.
Per datawarehouse valorizzato a off
full_page_writes
Disabilitare questo parametro velocizza le operazioni normali, ma potrebbe portare o a una corruzione non recuperabile dei dati, o a una corruzione dei dati silenziosa, dopo un fallimento del sistema. I rischi solo simili a disabilitare fsync, sebbene minori, e dovrebbe essere disabilitato solo nelle stesse circostanze raccomandate per quel parametro.
Per datawarehouse valorizzato a off
max_connections
Per datawarehouse scegliere un valore tra 10 e 40
shared_buffers (integer)
Imposta l'ammontare di memoria che il server database usa per i buffer di memoria condivisa. Il valore predefinito è tipicamente 32 megabyte (32MB), ma potrebbe essere meno se le impostazioni del kernel non lo supportano (come determinato durante l'initdb). Questa impostazione deve essere almeno 128 kilobytes. (Valori non predefiniti di BLCKSZ cambiano il minimo). Comunque, impostazioni significativamente maggiori rispetto al minimo sono di solito necessarie per buone prestazioni. Questo parametro può essere impostato solo all'avvio del server.
Se si ha un server database dedicato con 1GB o più di RAM, un valore di partenza ragionevole per shared_buffers è il 25% della memoria del sistema. Ci sono molti carichi di lavoro anche dove sono in vigore grandi valori per shared_buffers, ma dato chePostgreSQL fa affidamento anche sulla cache del sistema operativo, è improbabile che un'allocazione di più del 40% della RAM per shared_buffers funzionerà meglio rispetto a un quantitativo minore. Impostazioni più grandi per shared_buffers di solito richiedono un incremento corrispondente in checkpoint_segments, per diffondere il processo di scrittura di grandi quantità di dati nuovi o cambiati in un periodo di tempo più lungo.
Su sistemi con meno di 1GB di RAM, una percentuale di RAM più piccola è appropriata, quindi da lasciare spazio adeguato per il sistema operativo. Inoltre, su Windows, valori grandi per shared_buffers non sono così efficaci. Si potrebbero avere risultati migliori mantenendo il valore relativamente basso e usando maggiormente la cache del sistema operativo. L'intervallo utile pershared_buffers su sistemi Windows è generalmente da 64MB a 512MB.
Incrementare questo parametro potrebbe causare che PostgreSQL richieda più memoria System V condivisa rispetto a quello che permette il valore predefinito del sistema operativo. Si veda la sezione «Memoria condivisa e semafori» della guida per informazioni su come aggiustare questi parametri, se necessario.
¼ of RAM
work_mem
Specifica l'ammontare di memoria che deve essere usata da operazioni di ordinamento interne e dalle tabelle hash prima di scrivere in file disco temporanei. Il valore predefinito è un megabyte (1MB). Si noti che per una query complessa, diverse operazioni di ordinamento o hash potrebbero essere eseguite in parallelo; ogni operazione potrà usare tanta memoria quanto specificato da questo valore prima che cominci a scrivere dati in file temporanei. Inoltre, diverse sessioni in esecuzione potrebbero fare tali operazioni concorrentemente. Perciò, la memoria totale usata potrebbe essere molte volte più grande di work_mem; è necessario tenerlo a mente quando si sceglie il valore. Operazioni di ordinamento sono usate per ORDER BY, DISTINCT e join merge. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.
128MB to 1GB
maintenance_work_mem (integer)
Specifica l'ammontare di mamoria massimo da usare per operazioni di manutenzione, tipo VACUUM, CREATE INDEX e ALTER TABLE ADD FOREIGN KEY. Il valore predefinito è 16 megabyte (16MB). Dato che solo una di queste operazioni può essere eseguita alla volta da una sessione di database, e normalmente un'installazione non ne ha molte in esecuzione consorrentememte, è sicuro impostare questo valore significativamente maggiore rispetto a work_mem. Valori maggiori potrebbero aumentare le prestazioni del vacuum e del ripristino dei dump del database.
Si noti che quando autovacuum è in esecuzione, questa memoria potrebbe essere allocata autovacuum_max_workers volte, quindi fare attenzione a non impostare un valore predefinito troppo alto.
512MB to 1GB
temp_buffers
Imposta il massimo numero di butter temporanei usati da ogni sessione di database. Questi sono buffer locali alla sessione usati solo per accedere a tabelle temporanee. Il valore predefinito è otto megabyte (8MB). L'impostazione può essere cambiata all'interno di sessioni individuali, ma solo prima del primo utilizzo di tabelle temporanee all'interno della sessione; tentativi successivi di cambiare il valore non avranno effetto su quella sessione.
Una sessione allocherà buffer temporanei come richiesto dal limite fornito da temp_buffers. Il costo di impostare un valore grande in sessioni che effettivamente non necessitano di molti buffer temporanei è solo quello di un destrittore di buffer, o circa 64 byte per incremento in temp_buffers. Comunque se un buffer è effettivamente usato, 8192 byte aggiuntivi saranno consumati (o in generale,BLCKSZ byte).
128MB to 1GB
effective_cache_size
¾ of RAM
wal_buffers
L'ammontare di memoria usata nella memoria condivisa per dati WAL. Il valore predefinito è 64 kilobyte (64kB). L'impostazione necessita solo di essere larga abbastanza per contenere l'ammontare di dati WAL generati da una transazione tipica, dato che i dati sono scritto fuori dal disco ad ogni commit di transazione. Questo parametro può essere impostato solo all'avvio del server.
Incrementare questo parametro potrebbe causare che PostgreSQL richieda più memoria condivisa System V rispetto a quello che permette la configurazione predefinita del sistema operativo.
16MB
max_connections
Per datawarehouse scegliere un valore tra 10 e 40
shared_buffers (integer)
Imposta l'ammontare di memoria che il server database usa per i buffer di memoria condivisa. Il valore predefinito è tipicamente 32 megabyte (32MB), ma potrebbe essere meno se le impostazioni del kernel non lo supportano (come determinato durante l'initdb). Questa impostazione deve essere almeno 128 kilobytes. (Valori non predefiniti di BLCKSZ cambiano il minimo). Comunque, impostazioni significativamente maggiori rispetto al minimo sono di solito necessarie per buone prestazioni. Questo parametro può essere impostato solo all'avvio del server.
Se si ha un server database dedicato con 1GB o più di RAM, un valore di partenza ragionevole per shared_buffers è il 25% della memoria del sistema. Ci sono molti carichi di lavoro anche dove sono in vigore grandi valori per shared_buffers, ma dato chePostgreSQL fa affidamento anche sulla cache del sistema operativo, è improbabile che un'allocazione di più del 40% della RAM per shared_buffers funzionerà meglio rispetto a un quantitativo minore. Impostazioni più grandi per shared_buffers di solito richiedono un incremento corrispondente in checkpoint_segments, per diffondere il processo di scrittura di grandi quantità di dati nuovi o cambiati in un periodo di tempo più lungo.
Su sistemi con meno di 1GB di RAM, una percentuale di RAM più piccola è appropriata, quindi da lasciare spazio adeguato per il sistema operativo. Inoltre, su Windows, valori grandi per shared_buffers non sono così efficaci. Si potrebbero avere risultati migliori mantenendo il valore relativamente basso e usando maggiormente la cache del sistema operativo. L'intervallo utile pershared_buffers su sistemi Windows è generalmente da 64MB a 512MB.
Incrementare questo parametro potrebbe causare che PostgreSQL richieda più memoria System V condivisa rispetto a quello che permette il valore predefinito del sistema operativo. Si veda la sezione «Memoria condivisa e semafori» della guida per informazioni su come aggiustare questi parametri, se necessario.
¼ of RAM
work_mem
Specifica l'ammontare di memoria che deve essere usata da operazioni di ordinamento interne e dalle tabelle hash prima di scrivere in file disco temporanei. Il valore predefinito è un megabyte (1MB). Si noti che per una query complessa, diverse operazioni di ordinamento o hash potrebbero essere eseguite in parallelo; ogni operazione potrà usare tanta memoria quanto specificato da questo valore prima che cominci a scrivere dati in file temporanei. Inoltre, diverse sessioni in esecuzione potrebbero fare tali operazioni concorrentemente. Perciò, la memoria totale usata potrebbe essere molte volte più grande di work_mem; è necessario tenerlo a mente quando si sceglie il valore. Operazioni di ordinamento sono usate per ORDER BY, DISTINCT e join merge. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.
128MB to 1GB
maintenance_work_mem (integer)
Specifica l'ammontare di mamoria massimo da usare per operazioni di manutenzione, tipo VACUUM, CREATE INDEX e ALTER TABLE ADD FOREIGN KEY. Il valore predefinito è 16 megabyte (16MB). Dato che solo una di queste operazioni può essere eseguita alla volta da una sessione di database, e normalmente un'installazione non ne ha molte in esecuzione consorrentememte, è sicuro impostare questo valore significativamente maggiore rispetto a work_mem. Valori maggiori potrebbero aumentare le prestazioni del vacuum e del ripristino dei dump del database.
Si noti che quando autovacuum è in esecuzione, questa memoria potrebbe essere allocata autovacuum_max_workers volte, quindi fare attenzione a non impostare un valore predefinito troppo alto.
512MB to 1GB
temp_buffers
Imposta il massimo numero di butter temporanei usati da ogni sessione di database. Questi sono buffer locali alla sessione usati solo per accedere a tabelle temporanee. Il valore predefinito è otto megabyte (8MB). L'impostazione può essere cambiata all'interno di sessioni individuali, ma solo prima del primo utilizzo di tabelle temporanee all'interno della sessione; tentativi successivi di cambiare il valore non avranno effetto su quella sessione.
Una sessione allocherà buffer temporanei come richiesto dal limite fornito da temp_buffers. Il costo di impostare un valore grande in sessioni che effettivamente non necessitano di molti buffer temporanei è solo quello di un destrittore di buffer, o circa 64 byte per incremento in temp_buffers. Comunque se un buffer è effettivamente usato, 8192 byte aggiuntivi saranno consumati (o in generale,BLCKSZ byte).
128MB to 1GB
effective_cache_size
¾ of RAM
wal_buffers
L'ammontare di memoria usata nella memoria condivisa per dati WAL. Il valore predefinito è 64 kilobyte (64kB). L'impostazione necessita solo di essere larga abbastanza per contenere l'ammontare di dati WAL generati da una transazione tipica, dato che i dati sono scritto fuori dal disco ad ogni commit di transazione. Questo parametro può essere impostato solo all'avvio del server.
Incrementare questo parametro potrebbe causare che PostgreSQL richieda più memoria condivisa System V rispetto a quello che permette la configurazione predefinita del sistema operativo.
16MB
Nessun commento:
Posta un commento