Saya mengelola sejumlah proyek yang tujuan hidupnya adalah untuk membuat bagian pengujian PostgreSQL lebih mudah. Semua ini mendapat peningkatan yang layak selama minggu lalu.
penskalaan aliran menguji bagaimana kecepatan memori meningkat di server karena lebih banyak inti yang digunakan. Ini adalah data yang menarik, cukup untuk mulai melihat beberapa tren nyata. Sekarang bekerja dengan benar pada sistem dengan sejumlah besar cache CPU, karena mereka memiliki banyak inti. Sebelumnya dimungkinkan untuk menjadi sangat agresif dengan mengukur set pengujian untuk menghindari dampak cache sehingga menggunakan lebih banyak memori daripada yang dapat dialokasikan dengan desain kode aliran saat ini. Itu telah diperkecil. Jika Anda memiliki server 48 inti atau lebih besar, saya dapat menggunakan lebih banyak pengujian kode baru ini untuk melihat apakah cara baru saya menangani ini masuk akal.
peg adalah skrip yang saya tulis untuk memudahkan membangun PostgreSQL dari sumber, biasanya untuk pekerjaan pengembang atau untuk sementara mencoba versi yang lebih baru pada sistem produksi. Sangat mudah untuk menjadi bingung dengan peralihan antara proyek dan cabang git terkait sebelumnya; dokumentasi di area ini jauh lebih baik.
pgbench-tools adalah workhouse pengujian kinerja saya, memungkinkan Anda untuk mengantri tanda benchmark senilai hari dan kemudian memiliki cukup alat analisis yang tersedia untuk memahaminya. Program sekarang melacak parameter pg_stat_bgwriter.buffers_backend_fsync yang baru saja diperkenalkan jika Anda memiliki versi yang mendukungnya (saat ini hanya versi soure terbaru–yang membawa kita kembali ke mengapa pasak berguna). Anda juga dapat memerintahkannya untuk menjalankan setiap pengujian selama jangka waktu tertentu, yang membuat pengujian pada nilai klien/ukuran yang sangat bervariasi jauh lebih mudah.
Sejauh apa yang dapat Anda lakukan dengan pgbench-tools… mulai hari ini saya sekarang membagikan tes benchmark yang saya lakukan di PostgreSQL 9.1 di server paling kuat yang saya gunakan tanpa batas. 8 core, 16GB RAM, 3 disk drive database RAID-0, 1 volume WAL disk, cache yang didukung Baterai Areca. Anda dapat melihat hasilnya. Proses diatur ke dalam set pengujian, yang masing-masing mewakili semacam perubahan pada konfigurasi. Misalnya, #1 dalam data ini hanya menjalankan SELECT, #2 menjalankan seperti TPC-B tetapi dengan RAM 8GB dan kode sebelumnya, sedangkan yang paling populer adalah #3, menjalankan TPC-B dengan RAM 16GB dan kode itu melacak buffers_backend_fsyncs.
Ada beberapa tambalan dalam antrian PostgreSQL 9.1 yang terkait dengan kinerja di area yang disorot oleh hasil ini–bahwa Linux dapat memiliki latensi terburuk yang sangat tinggi pada beban basis data yang banyak menulis. Contoh rata-rata yang baik adalah pengujian 215: skala 1000, 32 klien, 365 TPS., Namun latensi terburuk adalah 43 detik, dan Anda dapat melihat titik mati di grafik TPS. Itu mengerikan, dan ada beberapa konsep yang beredar tentang bagaimana melakukan hal itu.
Jika siapa pun yang membaca ini memiliki server yang kuat yang tersedia selama beberapa minggu untuk menjalankan tes seperti ini, saya akan dengan senang hati membantu Anda mereplikasi lingkungan ini dan melihat hasil seperti apa yang Anda lihat. Satu-satunya keajaiban yang saya miliki adalah beberapa latihan tentang cara mengatur penskalaan dan beban klien sehingga Anda tidak kehilangan banyak waktu untuk pengujian yang tidak produktif. Sisa proses saya semuanya gratis dan didokumentasikan.
