Innanzitutto, usa sempre l'ultima versione di PostgreSQL. I miglioramenti delle prestazioni sono sempre in arrivo, quindi probabilmente stai perdendo tempo se stai sintonizzando una vecchia versione. Ad esempio, PostgreSQL 9.2 migliora notevolmente la velocità di TRUNCATE e ovviamente aggiunge scansioni solo indice. Anche le versioni minori dovrebbero essere sempre seguite; vedere la politica della versione.
Non fare
NON metti un tablespace su un RAMdisk o altro spazio di archiviazione non durevole.
Se perdi uno spazio tabella, l'intero database potrebbe essere danneggiato e difficile da usare senza un lavoro significativo. C'è molto poco vantaggio in questo rispetto al semplice utilizzo di UNLOGGED tabelle e avere comunque molta RAM per la cache.
Se vuoi veramente un sistema basato su ramdisk, initdb un cluster completamente nuovo sul ramdisk da initdb ing una nuova istanza PostgreSQL sul ramdisk, in modo da avere un'istanza PostgreSQL completamente usa e getta.
Configurazione del server PostgreSQL
Durante il test, puoi configurare il tuo server per un funzionamento non durevole ma più veloce.
Questo è uno degli unici usi accettabili per fsync=off impostazione in PostgreSQL. Questa impostazione praticamente dice a PostgreSQL di non preoccuparsi delle scritture ordinate o di qualsiasi altra brutta protezione dell'integrità dei dati e della sicurezza contro gli arresti anomali, dandogli il permesso di eliminare completamente i tuoi dati se si perde energia o si verifica un arresto anomalo del sistema operativo.
Inutile dire che non dovresti mai abilitare fsync=off in produzione a meno che tu non stia utilizzando Pg come database temporaneo per i dati che puoi rigenerare da altrove. Se e solo se stai facendo per disattivare fsync puoi anche attivare full_page_writes spento, perché non serve più a niente allora. Attenzione che fsync=off e full_page_writes presentare domanda al cluster livello, quindi influiscono su tutti database nella tua istanza PostgreSQL.
Per l'uso in produzione puoi eventualmente utilizzare synchronous_commit=off e imposta un commit_delay , poiché otterrai molti degli stessi vantaggi di fsync=off senza il gigantesco rischio di corruzione dei dati. Hai una piccola finestra di perdita di dati recenti se abiliti il commit asincrono, ma il gioco è fatto.
Se hai la possibilità di modificare leggermente il DDL, puoi anche usare UNLOGGED tabelle in Pg 9.1+ per evitare completamente la registrazione WAL e ottenere un vero aumento di velocità a costo della cancellazione delle tabelle in caso di crash del server. Non esiste alcuna opzione di configurazione per annullare la registrazione di tutte le tabelle, deve essere impostata durante CREATE TABLE . Oltre ad essere utile per i test, questo è utile se hai tabelle piene di dati generati o non importanti in un database che altrimenti contiene cose che devi essere al sicuro.
Controlla i tuoi log e verifica se ricevi avvisi su troppi checkpoint. Se lo sei, dovresti aumentare i tuoi segmenti di checkpoint. Potresti anche voler ottimizzare il tuo checkpoint_completion_target per rendere più agevoli le scritture.
Ottimizza shared_buffers per adattarsi al tuo carico di lavoro. Questo dipende dal sistema operativo, dipende da cos'altro sta succedendo con la tua macchina e richiede alcuni tentativi ed errori. Le impostazioni predefinite sono estremamente prudenti. Potrebbe essere necessario aumentare il limite massimo di memoria condivisa del sistema operativo se aumenti shared_buffers su PostgreSQL 9.2 e precedenti; 9.3 e versioni successive hanno modificato il modo in cui utilizzano la memoria condivisa per evitarlo.
Se stai usando solo un paio di connessioni che fanno molto lavoro, aumenta work_mem per dare loro più RAM con cui giocare per ordinamenti ecc. Fai attenzione a un work_mem troppo alto l'impostazione può causare problemi di memoria insufficiente perché è per ordinamento non per connessione, quindi una query può avere molti ordinamenti nidificati. Tu solo davvero devono aumentare work_mem se riesci a vedere gli ordinamenti che si riversano su disco in EXPLAIN o loggato con i log_temp_files impostazione (consigliata), ma un valore più alto può anche consentire a Pg di scegliere piani più intelligenti.
Come detto da un altro poster qui è saggio mettere xlog e le tabelle/indici principali su HDD separati, se possibile. Partizioni separate sono piuttosto inutili, vuoi davvero unità separate. Questa separazione ha molti meno vantaggi se stai utilizzando fsync=off e quasi nessuno se stai usando UNLOGGED tabelle.
Infine, sintonizza le tue domande. Assicurati che il tuo random_page_cost e seq_page_cost rifletta le prestazioni del tuo sistema, assicurati che il tuo effective_cache_size è corretto, ecc. Usa EXPLAIN (BUFFERS, ANALYZE) per esaminare i singoli piani di query e attivare auto_explain modulo attivo per segnalare tutte le query lente. Spesso puoi migliorare notevolmente le prestazioni delle query semplicemente creando un indice appropriato o modificando i parametri di costo.
AFAIK non c'è modo di impostare un intero database o cluster come UNLOGGED . Sarebbe interessante poterlo fare. Prendi in considerazione la possibilità di chiedere nella mailing list di PostgreSQL.
Ottimizzazione del sistema operativo host
Ci sono alcune regolazioni che puoi fare anche a livello di sistema operativo. La cosa principale che potresti voler fare è convincere il sistema operativo a non scaricare le scritture sul disco in modo aggressivo, dal momento che non ti interessa davvero quando/se lo fanno sul disco.
In Linux puoi controllarlo con dirty_* del sottosistema di memoria virtuale impostazioni, come dirty_writeback_centisecs .
L'unico problema con l'ottimizzazione delle impostazioni di writeback per essere troppo lente è che uno svuotamento da parte di qualche altro programma può causare lo svuotamento anche di tutti i buffer accumulati di PostgreSQL, causando grandi stalli mentre tutto si blocca durante le scritture. Potresti essere in grado di alleviare questo problema eseguendo PostgreSQL su un file system diverso, ma alcuni svuotamenti potrebbero essere a livello di dispositivo o a livello di intero host non a livello di file system, quindi non puoi fare affidamento su quello.
Questa messa a punto richiede davvero di giocare con le impostazioni per vedere cosa funziona meglio per il tuo carico di lavoro.
Sui kernel più recenti, potresti voler assicurarti che vm.zone_reclaim_mode è impostato su zero, poiché può causare gravi problemi di prestazioni con i sistemi NUMA (la maggior parte dei sistemi in questi giorni) a causa delle interazioni con il modo in cui PostgreSQL gestisce shared_buffers .
Ottimizzazione delle query e del carico di lavoro
Queste sono cose che richiedono modifiche al codice; potrebbero non essere adatti a te. Alcune sono cose che potresti essere in grado di applicare.
Se non stai raggruppando il lavoro in transazioni più grandi, inizia. Molte piccole transazioni sono costose, quindi dovresti raggruppare le cose ogni volta che è possibile e pratico farlo. Se stai usando il commit asincrono, questo è meno importante, ma comunque altamente raccomandato.
Quando possibile, utilizzare tabelle temporanee. Non generano traffico WAL, quindi sono molto più veloci per inserimenti e aggiornamenti. A volte vale la pena inserire un mucchio di dati in una tabella temporanea, manipolarli come è necessario, quindi eseguire un INSERT INTO ... SELECT ... per copiarlo al tavolo finale. Si noti che le tabelle temporanee sono per sessione; se la sessione termina o perdi la connessione, la tabella temporanea scompare e nessun'altra connessione può vedere il contenuto delle tabelle temporanee di una sessione.
Se stai usando PostgreSQL 9.1 o versioni successive puoi usare UNLOGGED tabelle per i dati che puoi permetterti di perdere, come lo stato della sessione. Questi sono visibili in diverse sessioni e conservati tra le connessioni. Vengono troncati se il server si spegne in modo non pulito, quindi non possono essere utilizzati per nulla che non puoi ricreare, ma sono ottimi per cache, viste materializzate, tabelle di stato, ecc.
In generale, non DELETE FROM blah; . Usa TRUNCATE TABLE blah; invece; è molto più veloce quando si scaricano tutte le righe in una tabella. Tronca molte tabelle in un TRUNCATE chiama se puoi. C'è un avvertimento se stai facendo molti TRUNCATES di tavolini ancora e ancora, però; vedi:Velocità di troncamento Postgresql
Se non hai indici sulle chiavi esterne, DELETE I messaggi che coinvolgono le chiavi primarie a cui fanno riferimento quelle chiavi esterne saranno terribilmente lenti. Assicurati di creare tali indici se ti aspetti di DELETE dalle tabelle di riferimento. Gli indici non sono richiesti per TRUNCATE .
Non creare indici che non ti servono. Ogni indice ha un costo di manutenzione. Prova a utilizzare un set minimo di indici e lascia che le scansioni dell'indice bitmap li combinino piuttosto che mantenere troppi indici a più colonne enormi e costosi. Laddove sono richiesti gli indici, prova a popolare prima la tabella, quindi crea gli indici alla fine.
Hardware
Avere abbastanza RAM per contenere l'intero database è una grande vittoria se riesci a gestirlo.
Se non hai abbastanza RAM, più veloce sarà l'archiviazione, meglio sarà. Anche un SSD economico fa un'enorme differenza rispetto alla ruggine rotante. Tuttavia, non fidarti degli SSD economici per la produzione, spesso non sono a prova di crash e potrebbero consumare i tuoi dati.
Apprendimento
Il libro di Greg Smith, PostgreSQL 9.0 High Performance rimane rilevante nonostante si riferisca a una versione un po' più vecchia. Dovrebbe essere un riferimento utile.
Unisciti alla mailing list generale di PostgreSQL e seguila.
Lettura:
- Ottimizzazione del tuo server PostgreSQL - wiki PostgreSQL
- Numero di connessioni al database - wiki PostgreSQL
