Menindaklanjuti Tuning Linux untuk Latensi PostgreSQL rendah bulan lalu, sekarang ada tumpukan besar pengujian yang dilakukan pada dua sistem file, tiga tambalan, dan dua set parameter penyetelan kernel yang dijalankan. Hasilnya sejauh ini adalah beberapa data baru yang menarik, dan satu lagi perbaikan yang dilakukan di area ini yang ada di PostgreSQL 9.1 sekarang (menjadi total tiga, dua lainnya memantau patch). Saya akan berbicara tentang latihan yang direkomendasikan bulan depan selama salah satu pembicaraan saya di PostgreSQL East, dan saya telah mengirimkan sesuatu di area ini untuk PGCon bulan Mei juga. Di sini saya akan berbicara lebih banyak tentang jalan buntu juga, sementara kenangan itu masih segar.
Masalah mendasar di sini adalah cara PostgreSQL menggunakan cache sistem operasi saat menulis memungkinkan sejumlah besar data terakumulasi. Hasilnya ketika pos pemeriksaan basis data selesai dapat berupa penundaan yang lama saat menunggu data tersebut ditulis. Ternyata program pgbench yang disertakan dengan PostgreSQL sangat bagus dalam membuat masalah ini, jadi itulah yang saya gunakan untuk semua pengujian. Cara pertanyaan yang ingin saya jawab adalah:
- Apakah perubahan dari sistem file ext3 lama benar-benar menunjukkan peningkatan kinerja pada tugas database? Saya menulis sesuatu tentang Kembalinya XFS di Linux tahun lalu yang menunjukkan peningkatan yang bagus pada tolok ukur sederhana. Itu tidak selalu berarti peningkatan basis data.
- Apakah tunables dirty_bytes dan dirty_background_bytes Linux terbaru benar-benar meningkatkan latensi kasus terburuk?
- Manakah dari perubahan basis data yang disarankan untuk meningkatkan perilaku di sini yang benar-benar berfungsi?
Anda dapat melihat semua hasil tes jika Anda ingin memeriksa data mentah. Apa yang diubah untuk setiap set pengujian didokumentasikan, dan jika Anda menelusuri pengujian individual, Anda dapat melihat parameter database yang digunakan dan beberapa informasi OS dasar lainnya. Halaman web itu adalah apa yang keluar dari program pengujian pgbench-tools saya, jika Anda ingin mencoba hal semacam ini sendiri.
Hasilnya tidak terlalu mengejutkan, tetapi menarik. Semua tes di sini dilakukan dengan dua ukuran database. Pada ukuran basis data yang lebih kecil (skala=500, sekitar basis data 8GB yang dengan mudah masuk ke dalam RAM 16GB server), ext3 mengelola 690 transaksi/detik, sedangkan pada ukuran dua kali itu (skala=1000, sekitar basis data 16GB) itu jauh lebih mencari terikat dan hanya mengelola 349 TPS. XFS meningkatkan kedua angka tersebut menjadi 1757 TPS dan 417 TPS – masing-masing naik 255% dan 19%. Lebih baik lagi, latensi terburuk untuk satu transaksi turun dari rentang 34 menjadi 56 detik (!) ke rentang 2 hingga 5 detik. Meskipun 5 detik tidak terlalu bagus, ini adalah beban kerja sintetis yang dirancang untuk membuat masalah ini menjadi sangat buruk. Angka ext3 sangat buruk sehingga Anda masih sangat mungkin mengalami masalah buruk di sini, meskipun saya sebenarnya melihat perilaku yang lebih baik pada sistem file itu daripada yang saya lihat di kernel sebelumnya (ini dilakukan dengan 2.6.32).
Putaran 1: XFS menang telak. Saya tidak dapat merekomendasikan ext3 sebagai sistem file yang layak pada sistem Linux dengan banyak memori jika Anda berencana untuk menulis banyak; itu tidak bekerja dalam konteks itu. Server ini hanya memiliki RAM 16GB, jadi bisa dibayangkan betapa buruknya masalah ini pada server produksi yang serius di sini pada tahun 2011.
Selanjutnya, tunable dirty_bytes dan dirty_background_bytes. Kedua latensi ini sedikit meningkat pada ext3, dengan mengorbankan beberapa pelambatan. Yang terburuk dari itu, waktu perawatan yang lambat menjalankan VACUUM, Anda tidak melihat hasil tes itu sendiri; Saya sudah membahasnya di entri blog saya sebelumnya. Pada XFS, menyetel parameter ini ke bawah adalah bencana kinerja. Pada skala basis data yang lebih kecil, kinerja TPS turun 46%, dan di atas semua itu latensi justru semakin buruk.
Putaran 2: Jangan mengharapkan keajaiban apa pun dari dirty_bytes atau dirty_background_bytes. Mereka tampaknya memiliki beberapa efek positif dalam beberapa keadaan, tetapi potensi penurunannya juga besar. Pastikan untuk menguji dengan hati-hati, dan sertakan VAKUM dalam pengujian Anda, sebelum menyesuaikan keduanya ke bawah.
Selanjutnya, saya akhirnya mengevaluasi tiga ide patch ke PostgreSQL sebagai bagian dari CommitFest terakhir ini:
- Menyebarkan panggilan checkpoint sync ke disk (fsync) dari waktu ke waktu. Kami telah melihat beberapa keberhasilan dengan itu di server klien yang sibuk ketika dikombinasikan dengan beberapa peningkatan penanganan tentang bagaimana operasi sinkronisasi lainnya di-cache oleh database
- Permintaan fsync ringkas. Ide ini terlepas dari yang pertama dan berubah menjadi tambalan yang ditulis oleh Robert Haas. Idenya adalah bahwa klien yang mencoba menyinkronkan data ke disk dapat bersaing dengan penulisan pos pemeriksaan. Apa yang dilakukan patch ini adalah memungkinkan klien untuk membersihkan antrean permintaan fsync jika mereka merasa sudah penuh.
- Urutkan pos pemeriksaan. Konsepnya adalah jika Anda menulis sesuatu dalam urutan yang diyakini database disimpan di disk, OS mungkin menulis lebih efisien. Tambalan ini muncul beberapa tahun yang lalu dengan beberapa hasil benchmark yang menunjukkan bahwa itu berhasil, tetapi pada saat itu tidak ada yang bisa mereplikasi peningkatannya. Idenya cocok dengan sisa pekerjaan dengan cukup baik sehingga saya mengevaluasinya lagi.
Putaran 3: Setelah berminggu-minggu mencoba semua ini, satu-satunya pendekatan dari rangkaian ini yang menunjukkan peningkatan di hampir semua ukuran beban kerja adalah yang pemadatan fsync. Kode sinkronisasi pos pemeriksaan penyebaran asli membantu di area ini, tetapi implementasi spesifik yang sekarang berkomitmen untuk 9.1 bekerja lebih baik. Itu adalah kenaikan 10% hampir di seluruh papan pada sebagian besar tes tulis-berat yang saya jalankan. Itu adalah peningkatan besar untuk PostgreSQL 9.1, dan itu akan benar-benar menghilangkan masalah yang telah kita lihat menyebabkan pelambatan yang jauh lebih besar pada sistem produksi di sini.
Ide-ide lainnya di sini tidak mendapatkan evaluasi positif setelah berat benchmarking, jadi untuk saat ini mereka kembali ke rak. Saya akan terus mengumpulkan data di sini–beberapa tes ext4 adalah hal logis berikutnya untuk dicoba–dan kemudian kembali ke pengembangan lagi. Mendapatkan keuntungan 10% pada beberapa beban kerja yang sulit tentu bagus, tetapi masih terlalu banyak perilaku terburuk di sini untuk mempertimbangkan masalah sinkronisasi pos pemeriksaan sebagai subjek tertutup.
