Saya telah menerbitkan beberapa tolok ukur yang membandingkan versi PostgreSQL yang berbeda, seperti misalnya pembicaraan arkeologi kinerja (mengevaluasi PostgreSQL 7.4 hingga 9.4), dan semua tolok ukur tersebut mengasumsikan lingkungan tetap (perangkat keras, kernel, ...). Yang baik-baik saja dalam banyak kasus (misalnya ketika mengevaluasi dampak kinerja patch), tetapi pada produksi hal-hal itu berubah dari waktu ke waktu – Anda mendapatkan upgrade perangkat keras dan dari waktu ke waktu Anda mendapatkan update dengan versi kernel baru.
Untuk peningkatan perangkat keras (penyimpanan yang lebih baik, lebih banyak RAM, CPU yang lebih cepat, ...), dampaknya biasanya cukup mudah diprediksi, dan terlebih lagi orang umumnya menyadari bahwa mereka perlu menilai dampaknya dengan menganalisis kemacetan pada produksi dan bahkan mungkin menguji perangkat keras baru terlebih dahulu. .
Tetapi bagaimana dengan pembaruan kernel? Sayangnya kami biasanya tidak melakukan banyak benchmarking di area ini. Asumsinya sebagian besar adalah bahwa kernel baru lebih baik daripada yang lebih lama (lebih cepat, lebih efisien, skala ke lebih banyak inti CPU). Tapi apakah itu benar? Dan seberapa besar perbedaannya? Misalnya bagaimana jika Anda mengupgrade kernel dari 3.0 ke 4.7 – apakah itu akan mempengaruhi kinerja, dan jika ya, apakah kinerja akan meningkat atau tidak?
Dari waktu ke waktu kami mendapatkan laporan tentang regresi serius dengan versi kernel tertentu, atau peningkatan mendadak di antara versi kernel. Jelas sekali, versi kernel dapat mempengaruhi kinerja.
Saya mengetahui satu tolok ukur PostgreSQL yang membandingkan versi kernel yang berbeda, dibuat pada tahun 2014 oleh Sergey Konoplev sebagai tanggapan atas rekomendasi untuk menghindari kernel 3.0 – 3.8. Tetapi tolok ukur itu sudah cukup lama (versi kernel terakhir yang tersedia ~18 bulan yang lalu adalah 3.13, sementara saat ini kami memiliki 3.19 dan 4.6), jadi saya memutuskan untuk menjalankan beberapa tolok ukur dengan kernel saat ini (dan PostgreSQL 9.6beta1).
Versi PostgreSQL vs. kernel
Tapi pertama-tama, izinkan saya membahas beberapa perbedaan signifikan antara kebijakan yang mengatur komitmen di kedua proyek. Di PostgreSQL kami memiliki konsep versi mayor dan minor – versi mayor (misalnya 9.5) dirilis kira-kira setahun sekali, dan menyertakan berbagai fitur baru. Versi minor (mis. 9.5.2) hanya menyertakan perbaikan bug, dan dirilis setiap tiga bulan (atau lebih sering, ketika bug serius ditemukan). Jadi seharusnya tidak ada perubahan kinerja atau perilaku utama di antara versi minor, yang membuatnya cukup aman untuk menerapkan versi minor tanpa pengujian ekstensif.
Dengan versi kernel, situasinya jauh lebih tidak jelas. Kernel Linux juga memiliki cabang (misalnya 2.6, 3.0 atau 4.7), itu tidak berarti sama dengan "versi utama" dari PostgreSQL, karena mereka terus menerima fitur baru dan bukan hanya perbaikan bug. Saya tidak mengklaim bahwa kebijakan pembuatan versi PostgreSQL entah bagaimana secara otomatis lebih unggul, tetapi konsekuensinya adalah bahwa pembaruan antara versi kernel kecil dapat dengan mudah mempengaruhi kinerja secara signifikan atau bahkan memperkenalkan bug (mis. 3.18.37 mengalami masalah OOM karena perbaikan non-bug tersebut komit).
Tentu saja, distribusi menyadari risiko ini, dan sering kali mengunci versi kernel dan melakukan pengujian lebih lanjut untuk menyingkirkan bug baru. Namun posting ini menggunakan kernel vanilla longterm, seperti yang tersedia di www.kernel.org.
Tolok ukur
Ada banyak tolok ukur yang mungkin kita gunakan – posting ini menyajikan serangkaian tes pgbench, yaitu tolok ukur OLTP (seperti TPC-B) yang cukup sederhana. Saya berencana untuk melakukan tes tambahan dengan tipe benchmark lainnya (terutama yang berorientasi DWH/DSS), dan saya akan menyajikannya di blog ini di masa mendatang.
Sekarang, kembali ke pgbench – ketika saya mengatakan “kumpulan tes” yang saya maksud adalah kombinasi dari
- hanya baca vs. baca-tulis
- ukuran kumpulan data – kumpulan aktif (tidak) cocok dengan buffer / RAM bersama
- jumlah klien – satu klien vs. banyak klien (penguncian/penjadwalan)
Nilainya jelas bergantung pada perangkat keras yang digunakan, jadi mari kita lihat perangkat keras apa yang digunakan dalam putaran tolok ukur ini:
- CPU:Intel i5-2500k @ 3,3 GHz (3,7 GHz turbo)
- RAM:8GB (DDR3 @ 1333 MHz)
- penyimpanan:6x Intel SSD DC S3700 di RAID-10 (Linux sw raid)
- sistem file:ext4 dengan penjadwal I/O default (cfq)
Jadi ini adalah mesin yang sama yang saya gunakan untuk sejumlah benchmark sebelumnya – mesin yang cukup kecil, bukan CPU terbaru, dll. tapi saya yakin ini masih merupakan sistem “kecil” yang masuk akal.
Parameter tolok ukurnya adalah:
- skala kumpulan data:30, 300, dan 1500 (jadi kira-kira 450MB, 4,5GB, dan 22,5GB)
- jumlah klien:1, 4, 16 (mesin memiliki 4 inti)
Untuk setiap kombinasi ada 3 proses baca-saja (masing-masing 15 menit) dan 3 proses baca-tulis (masing-masing 30 menit). Skrip aktual yang mendorong tolok ukur tersedia di sini (bersama dengan hasil dan data berguna lainnya).
Catatan :Jika Anda memiliki perangkat keras yang sangat berbeda (mis. drive rotasi), Anda mungkin melihat hasil yang sangat berbeda. Jika Anda memiliki sistem yang ingin Anda uji, beri tahu saya dan saya akan membantu Anda melakukannya (dengan asumsi saya akan diizinkan untuk memublikasikan hasilnya).
Versi kernel
Mengenai versi kernel, saya telah menguji versi terbaru di semua cabang jangka panjang sejak 2.6.x (2.6.39, 3.0.101, 3.2.81, 3.4.112, 3.10.102, 3.12.61, 3.14.73, 3.16. 36, 3.18.38, 4.1.29, 4.4.16, 4.6.5 dan 4.7). Masih banyak sistem yang berjalan pada kernel 2.6.x, jadi penting untuk mengetahui berapa banyak kinerja yang mungkin Anda peroleh (atau hilang) dengan memutakhirkan ke kernel yang lebih baru. Tapi saya telah mengkompilasi semua kernel sendiri (yaitu menggunakan kernel vanilla, tidak ada patch khusus distribusi), dan file konfigurasi ada di repositori git.
Hasil
Seperti biasa, semua data tersedia di bitbucket, termasuk
- file .config kernel
- skrip tolok ukur (run-pgbench.sh)
- Konfigurasi PostgreSQL (dengan beberapa penyetelan dasar untuk perangkat keras)
- Log PostgreSQL
- berbagai log sistem (dmesg, sysctl, mount, …)
Bagan berikut menunjukkan tps rata-rata untuk setiap kasus yang dijadikan tolok ukur – hasil untuk tiga putaran cukup konsisten, dengan ~2% perbedaan antara min dan maks dalam kebanyakan kasus.
hanya baca
Untuk kumpulan data terkecil, ada penurunan kinerja yang jelas antara 3,4 dan 3,10 untuk semua jumlah klien. Hasil untuk 16 klien (4x jumlah core) namun lebih dari pemulihan di 3.12.
Untuk kumpulan data menengah (sesuai dengan RAM tetapi tidak ke dalam buffer bersama), kita dapat melihat penurunan yang sama antara 3.4 dan 3.10 tetapi tidak pemulihan di 3.12.
Untuk kumpulan data besar (melebihi RAM, sangat terikat dengan I/O), hasilnya sangat berbeda – saya tidak yakin apa yang terjadi antara 3.10 dan 3.12, tetapi peningkatan kinerja (terutama untuk jumlah klien yang lebih tinggi) cukup mencengangkan.
baca-tulis
Untuk beban kerja baca-tulis, hasilnya cukup mirip. Untuk kumpulan data kecil dan menengah, kami dapat mengamati penurunan ~10% yang sama antara 3,4 dan 3,10, tetapi sayangnya tidak ada pemulihan di 3,12.
Untuk kumpulan data besar (sekali lagi, secara signifikan terikat I/O) kami dapat melihat peningkatan serupa di 3.12 (tidak signifikan seperti untuk beban kerja hanya-baca, tetapi masih signifikan):
Ringkasan
Saya tidak berani menarik kesimpulan dari satu tolok ukur pada satu mesin, tapi saya rasa aman untuk mengatakan:
- Kinerja keseluruhan cukup stabil, tetapi kita dapat melihat beberapa perubahan kinerja yang signifikan (di kedua arah).
- Dengan kumpulan data yang sesuai dengan memori (baik ke dalam shared_buffers atau setidaknya ke dalam RAM), kami melihat penurunan kinerja yang terukur antara 3,4 dan 3,10. Pada pengujian hanya-baca, ini sebagian pulih dalam 3.12 (tetapi hanya untuk banyak klien).
- Dengan kumpulan data yang melebihi memori, dan dengan demikian terutama terikat pada I/O, kami tidak melihat penurunan kinerja tersebut, melainkan peningkatan yang signifikan pada 3.12.
Adapun alasan mengapa perubahan mendadak itu terjadi, saya tidak yakin. Ada banyak komit yang mungkin relevan di antara versi, tetapi saya tidak yakin bagaimana mengidentifikasi yang benar tanpa pengujian ekstensif (dan memakan waktu). Jika Anda memiliki ide lain (misalnya mengetahui komitmen semacam itu), beri tahu saya.
