messa a punto di postgresql per grandi quantità di ram

Ho due server identici (in termini di hardware), sono entrambe installazioni standard di Windows Server 2008 R2, con un software minimo installato (fondamentalmente il mio codice e cose richieste come jvm ecc.).

Su un server, sto eseguendo SQL Server 2005, sul secondo server Postgresql 9.1. La differenza nelle prestazioni di questi 2 server è sconcertante, è così grave su postgresql che mi pento del mio discorso iniziale "usiamo postgresql invece di pagare per la licenza del server sql" al mio capo. Stiamo parlando di differenze di 30 secondi contro 15 minuti per lo stesso comando, e non è solo questo comando, è qualsiasi domanda o comando che gli lancio. Entrambi hanno praticamente gli stessi dati (i record sono stati inseriti in un ordine diverso) ed entrambi i database hanno la stessa struttura / indici esatti, ecc.

Ma spero sia solo una questione di ottimizzazione delle prestazioni. Il fatto è che sql server utilizza praticamente tutti i 32 concerti di ram sul server, mentre postgresl non usa nulla, sicuramente meno di un concerto, anche se in realtà non l'ho capito nei minimi dettagli.

Come posso ottenere postgresql per usare più di 20 concerti di ram? Questi server sono stati creati appositamente per questa roba di database, quindi ogni ram non utilizzata dal database e dai processi di supporto è sprecato secondo me.

Esistono molte costanti modificabili, inizializzate tramite postgres.conf. I più importanti sono:

• max_connections: il numero di sessioni simultanee
• work_mem : la quantità massima di memoria da utilizzare per risultati intermedi come le tabelle hash e per l'ordinamento
• shared_buffers la quantità di memoria dedicata allo spazio buffer "bloccato".
• effective_cache_size la quantità di memoria che si presume sia utilizzata dai buffer LRU del sistema operativo.
• random_page_cost : una stima del costo relativo delle ricerche del disco.

max_connectionsnon dovrebbe essere impostato più alto del necessario, le connessioni costano risorse anche quando sono inattive; nella maggior parte dei casi una connessione impiegherebbe più tempo ad aspettare dentro che ad aspettare fuori. (al prezzo della concorrenza) Una buona formula empirica è "numero di mandrini + numero di processori + X"

work_memè complicato: può essere applicato a ogni subquery, quindi una query con 5 HASHJOINSpotrebbe costare 5 * work_mem. E per gli scenari peggiori, dovresti anche pensare a più sessioni che consumano questo importo (di nuovo un motivo per mantenere max_connectionsbasso).

shared_buffersè (IMHO) sopravvalutato. Normalmente si consiglia di impostarlo su circa 1/4 ... 1/2 di tutta la memoria "libera" disponibile, ma tendo a mantenerlo basso e impostare effective_cache_sizesu tutta la memoria "libera" disponibile.

random_page_costè il costo per una ricerca + lettura sul disco. È relativo a sequential_disk_cost, che è 1. L'impostazione predefinita (4) per random_page_costè impostata su un valore troppo alto per le macchine moderne e l'archiviazione di rete, normalmente può essere abbassata tra 2 e 1.x. Per i dischi SSD potresti anche impostarlo su 1.0, poiché la ricerca è quasi gratuita su SSD.

Prendi in considerazione l'utilizzo di pgtune per aiutarti a ottimizzare la configurazione di PostgreSQL. Da PgFoundry:

pgtune prende il postgresql.conf predefinito wimpy ed espande il server di database per essere potente quanto l'hardware su cui viene distribuito

La configurazione predefinita di PostgreSQL è molto conservativa e lo strumento è pensato per aiutare con questa situazione esatta. La documentazione è una lettura leggera e l'utilizzo dello strumento è piuttosto semplice.

Tieni presente che non è necessario utilizzare i suggerimenti esatti di pgtune. Giocare con le sue impostazioni e guardare le modifiche risultanti al file conf ti darà una migliore comprensione della configurazione di PostgreSQL e di come modificarla manualmente.

Se ogni query o comando viene eseguito lentamente, sospetto che:

• ti connetti al database per ogni query che esegui;
• hai configurato una sorta di metodo di autenticazione, che non funziona e interrompe le tue query fino a quando questo particolare metodo di autenticazione non scade.

Potresti dirci quanto tempo ci vuole per eseguire una query del genere select version()? Se dovrebbe essere istantaneo (0,16ms sulla mia workstation).

Se OGNI query è molto più lenta, qualcosa è terribilmente sbagliato nel server o qualcosa del genere. Nella mia esperienza, ogni db ha alcune cose in cui è meglio dell'altro, ma per quanto riguarda le prestazioni pgsql è facilmente nello stesso regno del server mssql.

Quindi, su quale sistema operativo stai eseguendo pgsql? Quale hardware? Quali impostazioni hai già cambiato? Quanto è grande il tuo set di dati? Qual è un esempio di query scadente e l'output di spiegato analizza (Esegui la query in questo modo:

spiegare analizzare selezionare ... resto della query qui ...;

Pubblica l'output su http://explain.depesz.com/ e pubblica il link qui.