Developer Menunjukkan Cara Membuat PostgreSQL 42.000x Lebih Lambat Hanya Menggunakan Perubahan Konfigurasi

Seorang developer kreatif telah membalikkan optimasi database dengan secara sistematis menurunkan performa PostgreSQL hanya melalui penyesuaian konfigurasi. Apa yang dimulai sebagai eksperimen programmer pengangguran menjadi eksplorasi menarik tentang bagaimana memahami kegagalan dapat mengarah pada strategi optimasi yang lebih baik.

Belajar Melalui Reverse Engineering

Eksperimen ini sangat beresonansi dengan komunitas developer, yang mengakui nilai edukatif dari pendekatan terbalik ini. Banyak developer mencatat bahwa memahami apa yang membuat sistem gagal sering memberikan wawasan yang lebih dalam daripada sekadar mengikuti panduan optimasi. Teknik pembelajaran negative space ini memiliki preseden historis - teknik ini digunakan selama Perang Dunia II ketika meteorolog mengidentifikasi kondisi cuaca terburuk untuk membantu komandan misi menghindarinya, yang pada akhirnya menyelamatkan nyawa pilot.

Pendekatan ini mencerminkan teknik yang digunakan dalam kelas menulis kreatif, di mana siswa menganalisis tulisan buruk dan dengan sengaja menulis ulang konten yang baik menjadi buruk. Latihan-latihan ini sering terbukti lebih instruktif daripada metode tradisional karena memaksa pembelajar untuk memahami prinsip-prinsip dasar daripada hanya menghafal praktik terbaik.

Proses Penghancuran Sistematis

Metodologi developer ini melibatkan empat area sabotase utama. Pertama, mereka secara drastis mengurangi buffer cache dari 128MB menjadi hanya 8MB, memaksa PostgreSQL untuk terus-menerus membaca dari disk alih-alih menggunakan caching RAM yang efisien. Ini saja menciptakan penurunan performa yang signifikan dengan menghilangkan salah satu keunggulan kecepatan utama database.

Selanjutnya adalah manipulasi background processing yang agresif. Dengan mengonfigurasi autovacuum untuk berjalan terus-menerus - secara harfiah sepuluh kali per detik pada setiap tabel - sistem menjadi kewalahan dengan tugas pemeliharaan yang tidak perlu. Operasi-operasi ini mengonsumsi sumber daya yang besar sambil hampir tidak mencapai apa-apa, karena sangat sedikit data yang berubah di antara proses.

Serangan ketiga menargetkan sistem Write-Ahead Log (WAL). Dengan memaksa checkpoint yang sering dan memaksimalkan verbositas WAL, developer menciptakan skenario di mana PostgreSQL menghabiskan lebih banyak waktu untuk menulis log daripada memproses transaksi aktual. Checkpoint terjadi hanya dengan jarak 0,7 milidetik, jauh lebih sering daripada yang diizinkan konfigurasi wajar mana pun.

Write-Ahead Log (WAL): Sistem di mana PostgreSQL menulis perubahan ke file log sebelum menerapkannya ke database aktual, memastikan integritas data jika terjadi crash.

Perubahan Konfigurasi Utama yang Dilakukan:

• shared_buffers: Dikurangi dari 128MB menjadi 8MB (kemudian menjadi 1MB)
• Pengaturan autovacuum: Memaksimalkan frekuensi dan meminimalkan ambang batas
• Pengaturan WAL: Memaksa checkpoint yang sering dan verbositas maksimum
• Biaya query planner: random_page_cost dan seq_page_cost disesuaikan untuk menonaktifkan penggunaan indeks
• Konfigurasi I/O: io_method = worker dengan io_workers = 1 (fitur PostgreSQL 16)

Pukulan Terakhir: I/O Single-Threaded

Perubahan paling merusak datang melalui opsi konfigurasi I/O baru PostgreSQL 16. Dengan memaksa semua operasi input/output melalui satu worker thread, developer menciptakan bottleneck yang masif. Ini secara efektif mengubah sistem multi-core modern menjadi server database single-threaded, menyebabkan transaksi mengantri dan gagal.

Hasilnya dramatis: dari baseline 7.582 transaksi per detik turun menjadi hampir 0,1 TPS. Dari 100 koneksi yang berjalan selama 120 detik, hanya 11 transaksi yang berhasil diselesaikan. Sisanya gagal karena error out-of-memory atau timeout.

Hasil Degradasi Performa:

• Baseline: 7.582 TPS (transaksi per detik)
• Setelah pengurangan buffer cache: ~1/60 dari kecepatan asli
• Setelah manipulasi autovacuum: 293 TPS (~1/700 dari kecepatan asli)
• Setelah perubahan konfigurasi WAL: TPS dua digit
• Setelah manipulasi biaya indeks: <1 TPS (>7.600x lebih lambat)
• Hasil akhir dengan I/O single-threaded: 0,1 TPS (42.000x lebih lambat)

Respons Komunitas dan Aplikasi Praktis

Komunitas developer merangkul pendekatan pendidikan database yang tidak konvensional ini. Banyak yang mengakui bahwa dengan sengaja merusak sistem memberikan wawasan berharga tentang operasi normal mereka. Beberapa menyarankan ini bisa menjadi metodologi pengajaran, dengan buku-buku yang didedikasikan untuk cara membuat hal-hal menjadi lebih buruk sebagai jalan untuk memahami perbaikan.

Jika Anda akan menguasai optimasi sesuatu, mengapa tidak melakukan kebalikannya terlebih dahulu atau sebagai pembanding?

Eksperimen ini juga menyoroti berapa banyak kerusakan yang dapat dilakukan hanya melalui konfigurasi, tanpa menyentuh indeks, hardware, atau kode aplikasi. Ini berfungsi sebagai peringatan tentang kekuatan konfigurasi database dan panduan untuk apa yang harus dihindari di lingkungan produksi.

Latihan ini menunjukkan bahwa memahami batas sistem dan mode kegagalan dapat sama berharganya dengan mengetahui teknik optimasi. Untuk administrator database dan developer, melihat titik-titik kerusakan PostgreSQL memberikan konteks penting untuk membuat keputusan tuning yang tepat dalam skenario dunia nyata.

Referensi: Making Postgres 42,000x slower because I am unemployed