Ottimizza PostgreSQL per molti INSERTI e aggiornamenti bytea

Cosa abbiamo (software):

• PostrgeSQL 9.3 con configurazione di base (nessuna modifica in postgresql.conf)
• Windows 7 a 64 bit

Hardware:

• Intel Core i7-3770 3,9 Ghz
• 32 GB di RAM
• WDC WD10EZRX-00L4HBAta Drive (1000Gb, SATA III)

Quindi, dobbiamo caricare in aprox DB. 100.000.000 di righe con colonna bytea e 500.000.000 di righe più semplici (senza LOB). Ci sono 2 varcharindici sulla 1a tabella (con 13, 19 lunghezze) e 2 varcharindici sulla 2a tabella (18, 10 lunghezze). Esistono anche sequenze per la generazione di ID per ogni tabella.

Ormai queste operazioni stanno effettuando con 8 connessioni in parallelo con 50 dimensioni batch JDBC. L'immagine seguente mostra il carico del sistema: è a carico zero sui postgresqlprocessi. Dopo 24 ore di caricamento abbiamo caricato solo 10.000.000 di righe, il che è un risultato molto lento.

Chiediamo aiuto per ottimizzare la PostrgreSQLconfigurazione allo scopo di:

1) per il caricamento ultra rapido di questa quantità di dati, si tratta di una sola operazione, quindi potrebbe essere una configurazione temporanea

2) per la modalità di produzione per eseguire un numero moderato di SELECT in queste 2 tabelle in base ai loro indici senza join e senza ordinamento.

Per le insertprestazioni, vedere accelerare le prestazioni di inserimento in PostgreSQL e l' inserimento di massa in PostgreSQL .

Stai perdendo tempo con il batch JDBC per insert. PgJDBC non fa nulla di utile con i insertbatch, esegue solo ogni istruzione . <- Questo non è più vero nelle versioni più recenti di PgJDBC, che ora possono raggruppare istruzioni preparate per ridurre considerevolmente i tempi di andata e ritorno. Ma è ancora meglio:

Usa COPYinvece; vedere la copia batch di PgJDBC e il file CopyManager. Per quanto riguarda il numero di caricatori simultanei: mirare a una coppia per disco, se le operazioni sono associate all'I / O del disco. Otto è probabilmente il massimo che vorrai.

Per la tua "modalità di produzione" ti suggerisco di caricare un campione di dati, impostare le query che prevedi di eseguire e utilizzare explain analyzeper esaminare le prestazioni. Solo a scopo di test, utilizzare i enable_parametri per esplorare diverse selezioni di piano. Impostare i parametri di costo di query planner ( random_page_cost, seq_page_cost, effective_cache_size, ecc) in modo appropriato per il sistema, e assicurarsi che shared_bufferssia impostato in modo appropriato. Continuare a monitorare mentre si aggiunge un carico di lavoro di produzione simulato, utilizzando il auto_explainmodulo, l' log_min_duration_statementimpostazione, l' pg_stat_statementsestensione, ecc.

Per i dettagli, consultare il manuale utente di PostgreSQL. Ti suggerisco di tornare qui quando hai un problema più concreto con i explain analyzedettagli sull'esecuzione della query, ecc.