Hari ini adalah batas waktu untuk tarif kamar khusus di hotel yang menyelenggarakan PostgreSQL Conference East 2010 bulan ini. Jika Anda menunda-nunda memesan tempat di konferensi, mulai besok Anda akan dikenakan biaya.
Pembicaraan saya adalah tentang Benchmarking Perangkat Keras Basis Data dan dijadwalkan sore hari pada hari pertama, Kamis 25 Maret. Mereka yang mungkin pernah melihat pembicaraan ini sebelumnya, baik secara langsung di PGCon 2009 atau melalui tautan video yang tersedia di sana, mungkin bertanya-tanya apakah saya akan menarik slide yang sama dan berbicara lagi. Bukan kasusnya; sementara filosofi umum pembicaraan ("jangan percaya siapa pun, jalankan tolok ukur Anda sendiri") tetap sama, contoh dan campuran uji yang disarankan telah diperbarui untuk mencerminkan kemajuan perangkat keras yang bernilai satu tahun lagi, pekerjaan PostgreSQL, dan penelitian saya sendiri selama itu waktu. Situasi Intel vs. AMD khususnya telah sedikit berubah, membutuhkan serangkaian benchmark memori baru untuk benar-benar mengikuti apa yang terjadi sekarang.
Dan PostgreSQL 9.0 memperbaiki masalah utama yang membuatnya tidak memberikan hasil yang akurat secara normal di Linux, karena regresi kernel yang memperburuk situasi yang sudah terlalu umum: mudah bagi satu klien pgbench menjadi hambatan saat menjalankannya, bukan daripada database itu sendiri. Tinjauan yang saya lakukan untuk pgbench multi-utas (yang juga dapat berupa pgbench multi-proses pada sistem yang tidak mendukung utas) menyarankan percepatan>30% yang solid bahkan pada sistem yang tidak memiliki inkompatibilitas kernel yang buruk. Pengujian selanjutnya menunjukkan dapat dengan mudah mengambil 8 proses pgbench untuk mendapatkan throughput penuh bahkan dari prosesor modern yang murah di bawah kernel Linux baru-baru ini. Saya akan membahas dengan tepat bagaimana hal itu akhirnya dimainkan pada sistem seperti itu, dan bagaimana fitur baru ini memungkinkan lagi untuk menggunakan pgbench sebagai cara utama untuk mengukur kinerja CPU yang menjalankan database.
Baru-baru ini saya juga telah memperbarui git repo untuk pgbench-tools yang menambahkan dukungan kerja untuk kompatibilitas PostgreSQL 8.4 dan dasar 9.0, dan pembaruan berikutnya akan menyertakan dukungan untuk opsi multi-utas sekarang setelah saya memetakan caranya perlu bekerja. Ini semua mengarah ke suatu tempat. Setelah kami memiliki pengukuran yang akurat untuk kinerja PostgreSQL yang CPU terbatas di sisi server, sesuatu yang tidak sering terjadi selama lebih dari dua tahun sekarang, itu lagi-lagi menjadi cara yang berguna untuk memantau regresi kinerja di basis kode PostgreSQL. Pengujian yang disertakan perlu diperluas agar dapat mencakup lebih banyak pada akhirnya, tetapi untuk saat ini kami telah mencapai titik di mana pgbench dapat digunakan untuk menemukan regresi yang memengaruhi seberapa cepat pernyataan SELECT sederhana dijalankan. Saya tahu itu berfungsi seperti yang diharapkan, karena setiap kali saya secara tidak sengaja membuat PostgreSQL dengan pernyataan yang tertangkap karena saya melihat kecepatan pemrosesan rata-rata turun drastis.
Setelah saya memiliki beberapa pengaturan sistem di sini untuk menguji regresi semacam itu, pertanyaannya adalah bagaimana mengotomatiskan apa yang saya lakukan, dan kemudian melakukan hal yang sama terhadap berbagai checkout build. Idealnya, Anda akan dapat melihat grafik kinerja SELECT rata-rata setiap hari, dipecah menurut versi, sehingga ketika komit yang dikurangi itu diperkenalkan, akan segera terlihat jelas ketika kinerja turun. Ini adalah tujuan impian untuk membangun performance farm yang mirip dengan buildfarm PostgreSQL. Potongan-potongannya hampir semuanya sekarang: bagian pgbench saya selesai, ekstensi ke buildfarm untuk membuatnya berbicara langsung dengan git sedang bergerak (bukan persyaratan, tetapi tidak ada yang mengerjakan proyek ini yang ingin menggunakan CVS jika kami dapat menghindarinya) , dan hal utama yang hilang pada saat ini adalah seseorang yang meluangkan waktu untuk mengintegrasikan apa yang telah saya lakukan ke dalam klien seperti buildfarm.
Dan sepertinya kami sekarang memiliki sponsor perusahaan yang bersedia membantu dengan bagian pekerjaan itu, yang akan saya beri pujian ketika kami semua selesai, dan itu dijadwalkan akan terjadi musim panas ini. Saya sepenuhnya berharap bahwa pengembangan PostgreSQL 9.1, dan 9.0 backpatching, akan terjadi dengan pertanian kinerja awal di tempat untuk menjaga dari regresi kinerja. Jika kami dapat mem-backport pgbench multi-utas baru ke versi PostgreSQL yang lebih lama, kami mungkin memasukkannya ke dalam campuran juga. Saya sudah memiliki backport dari 8.3 pgbench, yang memiliki banyak peningkatan, saya pertahankan hanya untuk menguji sistem 8.2. Dengan pgbench sebagai modul kontribusi yang cukup mandiri, dimungkinkan untuk membangun yang lebih baru dari sistem lainnya, asalkan tidak mengharapkan fitur database yang lebih baru juga ada.
Jika itu sesuatu yang Anda minati, pembicaraan saya di konferensi akan memetakan fondasi yang saya harapkan untuk dibangun. Terlepas dari itu, harap Anda dapat menghadiri konferensi dan menikmati daftar panjang pembicaraan yang disajikan di sana.
