Salah satu bagian dari
dokumentasi PostgreSQL yang pernah saya kerjakan adalah Tuning Your PostgreSQL
Server. Ketika itu ditulis pada musim panas 2008, beberapa bulan setelah
rilis PostgreSQL 8.3, sulit untuk menemukan panduan serupa yang
baik (relatif) ringkas dan terkini. Sejak itu, saya dan
banyak kontributor PostgreSQL lainnya telah membantu menjaga dokumen itu tetap up-to-date saat perubahan pada PostgreSQL dibuat.
Tren yang menarik dan bermanfaat
selama periode itu adalah parameter yang terus menghilang dari set
yang perlu Anda khawatirkan. Di PostgreSQL 8.2, ada
daftar panjang parameter yang mungkin perlu Anda sesuaikan untuk kinerja yang baik
di server PostgreSQL:shared_buffers, effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers, dan (jika menggunakan
partitioning) constraint_exclusion.
8.3 menjadikan autovacuum default untuk
diaktifkan dengan perilaku yang wajar, bersama dengan menghapus beberapa
parameter penulis latar belakang yang hanya menyebabkan masalah (mereka
tidak pernah berhasil masuk daftar). 8.4 menghilangkan kebutuhan untuk dua
max_fsm_* parameter, meningkatkan default_statistics_target ke nilai awal yang jauh
lebih baik, dan membuat pengaturan constraint_exclusion
tidak diperlukan dalam kasus yang paling umum. Kurang enam parameter
yang mungkin perlu Anda sesuaikan.
Sayangnya versi 9.0 hanya membuat
konfigurasi server menjadi lebih rumit. Dan kernel Linux yang lebih baru bahkan
mendorong perilaku default ke belakang. Dimulai dengan kernel Linux
2.6.33, nilai default yang dipilih untuk wal_sync_method diubah menjadi
open_datasync. Hal ini ternyata memiliki implikasi buruk
kinerja untuk PostgreSQL, terutama bila dikombinasikan dengan
setelan default rendah untuk wal_buffers di server.
Tetapi langkah menuju default yang lebih baik
perilaku baru-baru ini dilanjutkan untuk apa yang akhirnya direncanakan
PostgreSQL 9.1. Selama CommitFest terakhir, tambalan berasal dari Marti
Raudsepp untuk memperbaiki masalah wal_sync_method dilakukan
setelah beberapa argumen berat tentang bentuk apa yang harus dilakukan perubahan itu.
Menemukan bahwa perubahan perilaku ini merusak PostgreSQL sama sekali
saat menjalankan ext4 dengan opsi “data=journal” membantu
menyelesaikan hal yang benar untuk dilakukan di sini secara default.
Dua parameter yang tidak saya sarankan
sentuh dalam banyak kasus adalah commit_siblings dan commit_delay,
artefak dari upaya lama untuk meningkatkan kinerja pada sistem dengan
waktu komit yang lambat (yang mencakup sebagian besar sistem yang tidak memiliki
tembolok tulis yang didukung baterai untuk mempercepat area tersebut). Saat ini
mematikan parameter synchronous_commit yang diperkenalkan pada 8.3
jauh lebih mungkin untuk membantu di sini. Meskipun ini tidak mungkin meningkatkan
kinerja, orang yang mencoba mengaturnya telah menderita lebih dari
yang diperlukan karena kerugian dari keputusan itu. Kasus
perilaku terburuk di sini telah ditingkatkan secara signifikan dalam tambalan yang saya tulis untuk mengoptimalkan cara logika yang dijalankan oleh kontrol parameter tersebut.
Dan minggu ini parameter terbaru untuk
dihilangkan secara efektif dalam banyak kasus adalah wal_buffers. Perubahan yang saya
sarankan dilakukan untuk menyetel ini secara otomatis sebagai persentase ukuran (sekitar 3%)
dialokasikan ke parameter shared_buffers yang biasanya jauh lebih besar.
Ini menetapkan nilai wal_buffers ke batas atas normal
rentang efektifnya, 16MB, setelah Anda mengalokasikan setidaknya 512MB ke
shared_buffers. Dan jika Anda telah meningkatkan shared_buffers dari
defaultnya yang kecil sama sekali, Anda akan mendapatkan peningkatan yang sesuai dalam
parameter kinerja commit penting ini. Anda harus keluar dari
cara Anda untuk memecahkan setelan parameter ini untuk mencapai
situasi buruk yang mungkin terjadi di versi sebelumnya.
Memiliki jumlah konfigurasi yang Anda
perlu lakukan ke server secara default menjadi lebih mudah selalu
bermanfaat, dan melihat parameter menghilang dari daftar kritis adalah
perubahan yang disambut baik. Apa berikutnya? Masalah inti dengan mengalokasikan
memori bersama pada sistem operasi turunan UNIX, khususnya Linux,
membuat sangat sulit untuk menghilangkan shared_buffers. Dan kekhawatiran
atas server yang mengambil alih sistem sama sekali membatasi kemampuan
untuk secara otomatis menyetel parameter seperti work_mem ke kisaran yang tepat.
Beberapa proposal untuk mengelola kumpulan memori kerja yang lebih baik telah
disarankan, sehingga orang mungkin melihat beberapa perbaikan.
Parameter berikutnya yang saya perhatikan adalah
checkpoint_segments. Setelah menambahkan logging ekstra di area ini di
commitFest terakhir, ada beberapa peningkatan di area ini mendekati
komit sekarang untuk benar-benar meningkatkan perilaku pos pemeriksaan. Saya berharap untuk
akhirnya mengalihkan penyetelan pos pemeriksaan untuk dikontrol secara ketat
melalui parameter berorientasi waktu, daripada mengharuskan pengguna untuk
memahami mekanisme cara kerja log tulis di depan untuk menyetel
br />sistem. Masih terlalu banyak situasi buruk yang mungkin terjadi di sini
yang pada waktunya untuk 9.1, tetapi menyetel jumlah segmen secara otomatis
layak untuk ditargetkan pada 9.2.
