Dua kerentanan keamanan yang serius (kode bernama Meltdown dan Spectre) terungkap beberapa minggu yang lalu. Pengujian awal menunjukkan bahwa dampak kinerja dari mitigasi (ditambahkan dalam kernel) mungkin mencapai ~30% untuk beberapa beban kerja, tergantung pada tingkat syscall.
Perkiraan awal itu harus dilakukan dengan cepat, dan berdasarkan jumlah pengujian yang terbatas. Selanjutnya, perbaikan dalam kernel berkembang dan ditingkatkan dari waktu ke waktu, dan kami sekarang juga mendapatkan retpoline yang seharusnya membahas Spectre v2. Postingan ini menyajikan data dari pengujian yang lebih menyeluruh, semoga memberikan perkiraan yang lebih andal untuk beban kerja PostgreSQL biasa.
Dibandingkan dengan penilaian awal perbaikan Meltdown yang Simon posting kembali pada 10 Januari, data yang disajikan dalam posting ini lebih rinci tetapi secara umum temuan pertandingan disajikan dalam posting itu.
Postingan ini berfokus pada beban kerja PostgreSQL, dan meskipun mungkin berguna untuk sistem lain dengan tingkat peralihan syscall/konteks yang tinggi, postingan ini tentu saja tidak dapat diterapkan secara universal. Jika Anda tertarik dengan penjelasan yang lebih umum tentang kerentanan dan penilaian dampak, Brendan Gregg menerbitkan artikel Regresi Kinerja Awal Meltdown KPTI/KAISER yang sangat baik beberapa hari yang lalu. Sebenarnya, mungkin ada gunanya membacanya terlebih dahulu dan kemudian melanjutkan dengan posting ini.
Catatan: Posting ini tidak dimaksudkan untuk mencegah Anda menginstal perbaikan, tetapi untuk memberi Anda gambaran tentang apa dampak kinerjanya. Anda harus menginstal semua perbaikan sehingga lingkungan Anda aman, dan gunakan postingan ini untuk memutuskan apakah Anda mungkin perlu meningkatkan perangkat keras, dll.
Tes apa yang akan kita lakukan?
Kita akan melihat dua jenis beban kerja dasar yang biasa – OLTP (transaksi kecil sederhana) dan OLAP (query kompleks yang memproses data dalam jumlah besar). Sebagian besar sistem PostgreSQL dapat dimodelkan sebagai campuran dari dua jenis beban kerja ini.
Untuk OLTP kami menggunakan pgbench, alat pembandingan terkenal yang disediakan dengan PostgreSQL. Kami menguji keduanya dalam read-only (-S ) dan baca-tulis (-N ) mode, dengan tiga skala berbeda – sesuai dengan shared_buffers, ke dalam RAM, dan lebih besar dari RAM.
Untuk kasus OLAP, kami menggunakan benchmark dbt-3, yang cukup dekat dengan TPC-H, dengan dua ukuran data yang berbeda – 10GB yang sesuai dengan RAM, dan 50GB yang lebih besar dari RAM (mempertimbangkan indeks, dll.).
Semua nomor yang disajikan berasal dari server dengan 2x Xeon E5-2620v4, 64GB RAM dan Intel SSD 750 (400GB). Sistem menjalankan Gentoo dengan kernel 4.15.3, dikompilasi dengan GCC 7.3 (diperlukan untuk mengaktifkan retpoline lengkap memperbaiki). Pengujian yang sama juga dilakukan pada sistem yang lebih lama/lebih kecil dengan CPU i5-2500k, RAM 8GB, dan SSD Intel S3700 6x (dalam RAID-0). Tapi perilaku dan kesimpulannya hampir sama, jadi kami tidak akan menyajikan datanya di sini.
Seperti biasa, skrip/hasil lengkap untuk kedua sistem tersedia di github.
Posting ini adalah tentang dampak kinerja mitigasi, jadi jangan fokus pada angka absolut dan alih-alih melihat kinerja relatif terhadap sistem yang tidak ditambal (tanpa mitigasi kernel). Semua grafik di bagian OLTP menunjukkan
(throughput with patches) / (throughput without patches)
Kami memperkirakan angka antara 0% dan 100%, dengan nilai yang lebih tinggi menjadi lebih baik (dampak mitigasi lebih rendah), 100% berarti “tidak ada dampak”.
Catatan: Sumbu y dimulai dari 75%, untuk membuat perbedaan lebih terlihat.
OLTP / hanya-baca
Pertama, mari kita lihat hasil untuk pgbench read-only, yang dijalankan dengan perintah ini
pgbench -n -c 16 -j 16 -S -T 1800 test
dan diilustrasikan oleh grafik berikut:
Seperti yang Anda lihat, dampak kinerja pti untuk skala yang sesuai dengan memori kira-kira 10-12% dan hampir tidak dapat diukur saat beban kerja menjadi terikat I/O. Selanjutnya, regresi berkurang secara signifikan (atau hilang seluruhnya) ketika pcid diaktifkan. Ini konsisten dengan klaim bahwa PCID sekarang menjadi fitur kinerja/keamanan yang penting di x86. Dampak retpoline jauh lebih kecil – kurang dari 4% dalam kasus terburuk, yang dapat dengan mudah disebabkan oleh kebisingan.
OLTP / baca-tulis
Tes baca-tulis dilakukan oleh pgbench perintah yang mirip dengan yang ini:
pgbench -n -c 16 -j 16 -N -T 3600 test
Durasinya cukup lama untuk mencakup beberapa pos pemeriksaan, dan -N digunakan untuk menghilangkan pertentangan kunci pada baris di tabel cabang (kecil). Kinerja relatif diilustrasikan oleh bagan ini:
Regresi sedikit lebih kecil daripada kasus hanya-baca – kurang dari 8% tanpa pcid dan kurang dari 3% dengan pcid diaktifkan. Ini adalah konsekuensi alami dari menghabiskan lebih banyak waktu melakukan I/O saat menulis data ke WAL, membilas buffer yang dimodifikasi selama pos pemeriksaan, dll.
Namun, ada dua bagian yang aneh. Pertama, dampak retpoline tiba-tiba besar (mendekati 20%) untuk skala 100, dan hal yang sama terjadi untuk retpoline+pti pada skala 1000. Alasannya tidak begitu jelas dan akan membutuhkan penyelidikan tambahan.
OLAP
Beban kerja analitik dimodelkan oleh benchmark dbt-3. Pertama, mari kita lihat hasil skala 10GB, yang sepenuhnya cocok dengan RAM (termasuk semua indeks, dll.). Sama halnya dengan OLTP, kami tidak terlalu tertarik dengan angka absolut, yang dalam hal ini adalah durasi untuk kueri individual. Sebagai gantinya kita akan melihat perlambatan dibandingkan dengan nopti/noretpoline , yaitu:
(duration without patches) / (duration with patches)
Dengan asumsi mitigasi menghasilkan perlambatan, kami akan mendapatkan nilai antara 0% dan 100% di mana 100% berarti "tidak ada dampak". Hasilnya terlihat seperti ini:
Artinya, tanpa pcid regresi umumnya dalam kisaran 10-20%, tergantung pada kueri. Dan dengan pcid regresi turun menjadi kurang dari 5% (dan umumnya mendekati 0%). Sekali lagi, ini menegaskan pentingnya pcid fitur.
Untuk kumpulan data 50GB (yaitu sekitar 120GB dengan semua indeks, dll.) dampaknya terlihat seperti ini:
Jadi seperti dalam kasus 10GB, regresinya di bawah 20% dan pcid menguranginya secara signifikan – hampir 0% dalam banyak kasus.
Bagan sebelumnya agak berantakan – ada 22 kueri dan 5 seri data, yang terlalu banyak untuk satu bagan. Jadi di sini adalah bagan yang menunjukkan dampak hanya untuk ketiga fitur (pti , pcid dan retpoline ), untuk kedua ukuran kumpulan data.
Kesimpulan
Untuk meringkas hasil secara singkat:
retpolinememiliki dampak kinerja yang sangat kecil- OLTP – regresinya kira-kira 10-15% tanpa
pcid, dan sekitar 1-5% denganpcid. - OLAP – regresi hingga 20% tanpa
pcid, dan sekitar 1-5% denganpcid. - Untuk beban kerja terikat I/O (misalnya OLTP dengan kumpulan data terbesar), Meltdown memiliki dampak yang dapat diabaikan.
Dampaknya tampaknya jauh lebih rendah daripada perkiraan awal (30%), setidaknya untuk beban kerja yang diuji. Banyak sistem yang beroperasi pada 70-80% CPU pada periode puncak, dan 30% akan sepenuhnya memenuhi kapasitas CPU. Namun dalam praktiknya, dampaknya tampaknya di bawah 5%, setidaknya saat pcid opsi digunakan.
Jangan salah paham, penurunan 5% masih merupakan regresi yang serius. Ini tentu saja adalah sesuatu yang akan kami pedulikan selama pengembangan PostgreSQL, mis. saat mengevaluasi dampak dari patch yang diusulkan. Tapi itu adalah sesuatu yang harus ditangani oleh sistem yang ada dengan baik – jika peningkatan 5% dalam pemanfaatan CPU membuat sistem Anda melampaui batas, Anda memiliki masalah bahkan tanpa Meltdown/Spectre.
Jelas, ini bukan akhir dari perbaikan Meltdown/Spectre. Pengembang kernel masih bekerja untuk meningkatkan perlindungan dan menambahkan yang baru, dan Intel serta produsen CPU lainnya sedang mengerjakan pembaruan mikrokode. Dan sepertinya kita tidak mengetahui semua kemungkinan varian kerentanan, karena para peneliti berhasil menemukan varian baru dari serangan tersebut.
Jadi, masih ada lagi yang akan datang dan akan menarik untuk melihat apa dampaknya terhadap kinerja.
