Oggi è la scadenza per la tariffa speciale della camera presso l'hotel che ospita la PostgreSQL Conference East 2010 di questo mese. Se hai procrastinato la prenotazione di un posto alla conferenza, da domani inizierà a costarti.
Il mio intervento è su Database Hardware Benchmarking ed è previsto per il tardo pomeriggio del primo giorno, giovedì 25 marzo. Coloro che potrebbero aver già visto questo discorso, dal vivo al PGCon 2009 o tramite il collegamento video disponibile lì, potrebbero chiedersi se trascinerò le stesse diapositive e parlerò di nuovo. Non è il caso; mentre la filosofia generale del discorso ("non fidarti di nessuno, esegui i tuoi benchmark") rimane la stessa, gli esempi e il mix di test suggeriti sono stati aggiornati per riflettere un altro anno di progressi hardware, lavoro su PostgreSQL e la mia ricerca durante quello tempo. La situazione tra Intel e AMD, in particolare, è cambiata parecchio, richiedendo una nuova serie di benchmark di memoria per seguire davvero quello che sta succedendo ora.
E PostgreSQL 9.0 ha risolto un grave problema che gli impediva di fornire normalmente risultati accurati su Linux, a causa di una regressione del kernel che ha peggiorato molto una situazione già troppo comune: è facile che un singolo client pgbench diventi il collo di bottiglia durante l'esecuzione, piuttosto rispetto al database stesso. La recensione che ho fatto per pgbench multi-thread (che può anche essere pgbench multi-processo su sistemi che non supportano i thread) ha suggerito un solido aumento di>30% anche su sistemi che non avevano la cattiva incompatibilità del kernel su di essi. Test successivi suggeriscono che possono facilmente essere necessari 8 processi pgbench per ottenere il pieno throughput da processori moderni anche poco costosi con i recenti kernel Linux. Esaminerò esattamente come ciò finisce per funzionare su tali sistemi e come questa nuova funzionalità consente di nuovo di utilizzare pgbench come modo principale per misurare le prestazioni della CPU che esegue il database.
Recentemente ho anche aggiornato il repository git per pgbench-tools che aggiunge il supporto funzionante per PostgreSQL 8.4 e la compatibilità di base 9.0, e il prossimo aggiornamento includerà il supporto per l'opzione multi-thread ora che ho mappato come questo ha bisogno di lavorare. Tutto questo porta da qualche parte. Una volta che abbiamo misurazioni accurate per le prestazioni di PostgreSQL che sono limitate dalla CPU sul lato server, cosa che non accade spesso da oltre due anni, quelle diventano di nuovo un modo utile per monitorare le regressioni delle prestazioni nella base di codice di PostgreSQL. I test inclusi dovranno espandersi per poterne coprire di più alla fine, ma per ora abbiamo raggiunto un punto in cui pgbench può essere utilizzato per trovare regressioni che influiscano sulla velocità di esecuzione delle semplici istruzioni SELECT. So che funziona come previsto, perché ogni volta che creo accidentalmente PostgreSQL con asserzioni su ciò viene catturato perché vedo che la velocità di elaborazione media diminuisce drasticamente.
Una volta che ho configurato un paio di sistemi qui per testare tali regressioni, la domanda diventa come automatizzare ciò che sto facendo e quindi fare la stessa cosa contro una gamma più ampia di checkout di build. Idealmente, saresti in grado di vedere un grafico delle prestazioni medie di SELECT ogni giorno, suddivise per versione, in modo che quando è stato introdotto un commit che lo ha ridotto, sarebbe immediatamente ovvio quando le prestazioni sono diminuite. Questo è l'obiettivo dei sogni per la creazione di una performance farm simile alla buildfarm di PostgreSQL. I pezzi sono quasi tutti insieme ora: le mie parti di pgbench si stanno concludendo, le estensioni a buildfarm per farlo parlare direttamente a git stanno procedendo (non è un requisito, ma nessuno che lavora a questo progetto vuole usare CVS se possiamo evitarlo) , e la cosa principale che manca a questo punto è qualcuno a cui dedicare il tempo necessario per integrare ciò che ho fatto in un client simile a buildfarm.
E sembra che ora abbiamo uno sponsor aziendale disposto ad aiutare con quel pezzo di lavoro, di cui lascerò prendere il merito quando avremo finito, e questo dovrebbe accadere quest'estate. Mi aspetto pienamente che lo sviluppo di PostgreSQL 9.1 e il backpatching 9.0 avvengano con una prima performance farm in atto per proteggersi dalle regressioni delle prestazioni. Se possiamo eseguire il backport del nuovo pgbench multi-thread su versioni precedenti di PostgreSQL, potremmo includerle anche nel mix. Ho già un backport del pgbench 8.3, che ha molti miglioramenti, mantengo solo per testare i sistemi 8.2. Con pgbench come modulo contrib abbastanza autonomo, è possibile crearne uno successivo diverso dal resto del sistema, a condizione che non si aspettino anche nuove funzionalità del database.
Se questo è qualcosa che ti interessa, il mio intervento alla conferenza tratterà le basi su cui mi aspetto che venga costruito. In ogni caso, spero che tu possa partecipare alla conferenza e goderti il lungo elenco di discorsi presentati lì.
