Postgres DISK IO molto alto. Cosa posso fare per ridurlo immediatamente?

Sono consapevole che dischi più veloci di quelli che sto usando aiuteranno, ma ci vorrà più tempo per inserirli e sto cercando di usare alcune misure di emergenza per ridurre l'IO del disco. in cima riporta quasi costantemente l'utilizzo del DSK sul rosso. Questo è per Postgres 8.3.

La mia impostazione shared_buffers è a 24 MB sebbene il server abbia 16 GB di RAM che non sono completamente utilizzati. Il mio primo pensiero è stato quello di dare al database tutte le ram che poteva richiedere ma non sono sicuro di come farlo (questo è un server di database dedicato).

È preferibile qualsiasi soluzione che non richiede un riavvio, ma prenderò quello che posso ottenere a questo punto.

Grazie!

L'impostazione share_buffers da 24 MB è l'impostazione predefinita conservativa, direi che deve essere molto più alta per un database dedicato con 16 GB di RAM disponibili. Sì, dovrai riavviare il server per ridimensionarlo. http://wiki.postgresql.org/wiki/Performance_Optimization è un buon punto di partenza per le linee guida per la configurazione delle prestazioni. L'impostazione di shared_buffers su 4 GB o 6 GB sembrerebbe più ragionevole.

Si noti che su Linux è necessario regolare l'impostazione sysctl kernel.shmmax (in /etc/sysctl.conf o semplicemente scrivendo / proc / sys / kernel / shmmax) per allocare un blocco di questa memoria condivisa. In caso contrario, verrà visualizzato un errore che specifica quanto è stato richiesto, è necessario impostare kernel.shmmax su un valore superiore.

Dato che hai un sacco di memoria, potresti anche considerare di impostare un work_mem predefinito più alto, il che farà sì che cose come ordinamenti e hash (gruppo / ordine / distinto ecc.) Tendano a funzionare in memoria piuttosto che usare i file temporanei. Non è necessario riavviare il server per fare ciò, basta aggiornare il file di configurazione, ricaricare il servizio e le nuove sessioni otterranno la nuova impostazione. La memoria di lavoro predefinita per una sessione è 1 MB, è possibile calcolare il massimo che può essere utilizzato in una sola volta work_mem * max_client_connectionse stimare quale impatto avrà.

Dovresti anche aumentare effect_cache_size per indicare al pianificatore che è probabile che il layer FS del kernel stia memorizzando nella cache molte pagine in memoria al di fuori dei buffer condivisi di postgresql.

ecc. ecc. spero che questo ti faccia iniziare bene.

Rimontare i dischi con noatime

A parte i suggerimenti forniti qui, potresti anche voler esaminare le tue impostazioni di auto vaccum. Per impostazione predefinita, si innescherà dopo circa 50 aggiornamenti e se il database sta eseguendo molti aggiornamenti / inserimenti, ciò può innescare una quantità non necessaria di dichiarazioni di vuoto che genereranno molti IO.

Su un sistema molto vicino alla velocità effettiva I / O massima durante il normale funzionamento, è possibile aumentare il checkpoint_completion_target per ridurre il carico I / O dai punti di controllo . Lo svantaggio di ciò è che il prolungamento dei checkpoint influisce sui tempi di recupero, poiché sarà necessario mantenere un numero maggiore di segmenti WAL per un possibile utilizzo nel recupero

Vedi di più qui .

Se la diskio di postgresql è molto alta, dovresti controllare le istruzioni in esecuzione, specialmente per le istruzioni, facendo un "ordinamento su disco" e impostare gli indici corretti.

Basta google per "Postgresql Performance Tuning", troverai abbastanza spunti da dove cominciare.