Mantengo una serie di progetti il cui scopo nella vita è rendere più semplici i test di parti di PostgreSQL. Tutti questi hanno ricevuto un aggiornamento decente nell'ultima settimana.
il ridimensionamento del flusso verifica come la velocità della memoria aumenta sui server man mano che vengono messi in gioco più core. Sono dati affascinanti, abbastanza per iniziare a vedere alcune tendenze reali. Ora funziona correttamente su sistemi con grandi quantità di cache della CPU, perché hanno molti core. In precedenza era possibile che fosse così aggressivo con il dimensionamento del set di test per evitare l'impatto sulla cache da utilizzare più memoria di quella che potrebbe essere allocata con l'attuale progettazione del codice di flusso. Questo è stato ridimensionato. Se hai un server con 48 core o più grandi, potrei usare un po' più di test di questo nuovo codice per vedere se il nuovo modo in cui gestisco questo ha senso.
peg è uno script che ho scritto per semplificare la compilazione di PostgreSQL dal sorgente, in genere per il lavoro degli sviluppatori o per provare temporaneamente una versione più recente su un sistema di produzione. Prima era molto facile confondersi con il passaggio da un progetto all'altro e i rami git associati; la documentazione in quest'area è molto migliorata.
pgbench-tools è il mio laboratorio di test delle prestazioni, che ti consente di mettere in coda giorni per un punteggio di riferimento e quindi avere strumenti di analisi sufficienti per dargli un senso. Il programma ora tiene traccia del parametro pg_stat_bgwriter.buffers_backend_fsync introdotto di recente se si dispone di una versione che lo supporta (attualmente solo una build soure recente, il che ci riporta al motivo per cui peg è utile). Puoi anche dirgli di eseguire ogni test per un periodo di tempo fisso, il che rende molto più semplice il test con valori di clienti/dimensioni estremamente variabili.
Per quanto riguarda ciò che puoi fare con pgbench-tools... ad oggi condivido i test di benchmarking che sto facendo su PostgreSQL 9.1 sul server più potente di cui ho un uso illimitato. 8 core, 16 GB di RAM, 3 unità di database RAID-0 del disco, 1 volume WAL del disco, cache con batteria tampone Areca. Puoi vedere i risultati. Le esecuzioni sono organizzate in set di test, ognuno dei quali rappresenta una sorta di modifica alla configurazione. Ad esempio, n. 1 in questi dati esegue solo SELECT, n. 2 esegue in modo simile a TPC-B ma con 8 GB di RAM e codice più antico, mentre la roba calda è n. 3, esegue TPC-B con 16 GB di RAM e codice che tracce buffers_backend_fsyncs.
Ci sono diverse patch nella coda di PostgreSQL 9.1 relative alle prestazioni nelle aree evidenziate da questi risultati:Linux può avere una latenza estremamente elevata nel caso peggiore su carichi di database pesanti in scrittura. Un buon esempio medio è il test 215: scala di 1000, 32 client, 365 TPS., Ma la latenza nel caso peggiore è di 43 secondi e puoi vedere i punti morti nel grafico del TPS. È semplicemente terribile e ci sono alcuni concetti in giro su come farlo.
Se qualcuno che sta leggendo questo ha un potente server disponibile per alcune settimane su cui eseguire test come questo, sarei felice di aiutarti a replicare questo ambiente e vedere che tipo di risultati vedi. L'unica magia che ho è un po' di pratica su come impostare il ridimensionamento e i carichi del client in modo da non perdere molto tempo per test improduttivi. Il resto del mio processo è tutto gratuito e documentato.
