Pembangun Menunjukkan Cara Membuat PostgreSQL 42,000x Lebih Perlahan Hanya Menggunakan Perubahan Konfigurasi

Seorang pembangun yang kreatif telah membalikkan pengoptimuman pangkalan data dengan secara sistematik merendahkan prestasi PostgreSQL melalui pengubahsuaian konfigurasi sahaja. Apa yang bermula sebagai eksperimen seorang pengaturcara yang menganggur menjadi penerokaan yang menarik tentang bagaimana memahami kegagalan boleh membawa kepada strategi pengoptimuman yang lebih baik.

Pembelajaran Melalui Kejuruteraan Terbalik

Eksperimen ini mendapat sambutan yang kuat daripada komuniti pembangun, yang mengiktiraf nilai pendidikan pendekatan terbalik ini. Ramai pembangun menyatakan bahawa memahami apa yang menyebabkan sistem gagal sering memberikan wawasan yang lebih mendalam berbanding hanya mengikuti panduan pengoptimuman. Teknik pembelajaran ruang negatif ini mempunyai preseden sejarah - ia digunakan semasa Perang Dunia Kedua apabila ahli meteorologi mengenal pasti keadaan cuaca yang paling buruk untuk membantu komander misi mengelakkannya, akhirnya menyelamatkan nyawa juruterbang.

Pendekatan ini mencerminkan teknik yang digunakan dalam kelas penulisan kreatif, di mana pelajar menganalisis penulisan yang buruk dan sengaja menulis semula kandungan yang baik dengan teruk. Latihan ini sering terbukti lebih memberi pengajaran daripada kaedah tradisional kerana ia memaksa pelajar memahami prinsip asas dan bukannya hanya menghafal amalan terbaik.

Proses Pemusnahan Sistematik

Metodologi pembangun ini melibatkan empat bidang utama sabotaj. Pertama, mereka mengurangkan cache buffer secara drastik daripada 128MB kepada hanya 8MB, memaksa PostgreSQL membaca daripada cakera secara berterusan dan bukannya menggunakan caching RAM yang cekap. Ini sahaja mencipta kesan prestasi yang ketara dengan menghapuskan salah satu kelebihan kelajuan utama pangkalan data.

Seterusnya datang manipulasi pemprosesan latar belakang yang agresif. Dengan mengkonfigurasi autovacuum untuk berjalan secara berterusan - secara literal sepuluh kali sesaat pada setiap jadual - sistem menjadi terharu dengan tugas penyelenggaraan yang tidak perlu. Operasi ini memakan sumber yang besar sambil mencapai hampir tiada apa-apa, kerana sangat sedikit data yang berubah antara operasi.

Serangan ketiga menyasarkan sistem Write-Ahead Log ( WAL ). Dengan memaksa checkpoint yang kerap dan memaksimumkan verbositi WAL , pembangun mencipta senario di mana PostgreSQL menghabiskan lebih banyak masa menulis log daripada memproses transaksi sebenar. Checkpoint berlaku hanya 0.7 milisaat antara satu sama lain, jauh lebih kerap daripada mana-mana konfigurasi yang munasabah.

Write-Ahead Log (WAL): Sistem di mana PostgreSQL menulis perubahan kepada fail log sebelum mengaplikasikannya kepada pangkalan data sebenar, memastikan integriti data sekiranya berlaku kerosakan.

Perubahan Konfigurasi Utama Yang Dibuat:

• shared_buffers: Dikurangkan daripada 128MB kepada 8MB (kemudiannya 1MB)
• Tetapan autovacuum: Memaksimumkan kekerapan dan meminimumkan ambang
• Tetapan WAL: Memaksa checkpoint yang kerap dan verbosity maksimum
• Kos perancang pertanyaan: random_page_cost dan seq_page_cost diselaraskan untuk melumpuhkan penggunaan indeks
• Konfigurasi I/O: io_method = worker dengan io_workers = 1 (ciri PostgreSQL 16)

Pukulan Terakhir: I/O Benang Tunggal

Perubahan yang paling memusnah datang melalui pilihan konfigurasi I/O baharu PostgreSQL 16 . Dengan memaksa semua operasi input/output melalui benang pekerja tunggal, pembangun mencipta kesesakan yang besar. Ini secara berkesan mengubah sistem berbilang teras moden menjadi pelayan pangkalan data benang tunggal, menyebabkan transaksi beratur dan gagal.

Hasilnya dramatik: daripada garis dasar 7,582 transaksi sesaat turun kepada hampir 0.1 TPS. Daripada 100 sambungan yang berjalan selama 120 saat, hanya 11 transaksi berjaya diselesaikan. Yang lain gagal disebabkan ralat kehabisan memori atau timeout.

Keputusan Kemerosotan Prestasi:

• Garis dasar: 7,582 TPS (transaksi sesaat)
• Selepas pengurangan cache buffer: ~1/60 kelajuan asal
• Selepas manipulasi autovacuum: 293 TPS (~1/700 kelajuan asal)
• Selepas perubahan konfigurasi WAL: TPS digit berganda
• Selepas manipulasi kos indeks: <1 TPS (>7,600x lebih perlahan)
• Keputusan akhir dengan I/O benang tunggal: 0.1 TPS (42,000x lebih perlahan)

Sambutan Komuniti dan Aplikasi Praktikal

Komuniti pembangun menerima pendekatan tidak konvensional ini terhadap pendidikan pangkalan data. Ramai yang mengiktiraf bahawa sengaja merosakkan sistem memberikan wawasan berharga tentang operasi normal mereka. Ada yang mencadangkan ini boleh menjadi metodologi pengajaran, dengan buku yang didedikasikan untuk cara memburukkan keadaan sebagai laluan untuk memahami penambahbaikan.

Jika anda akan menguasai pengoptimuman sesuatu, mengapa tidak lakukan yang sebaliknya dahulu atau sebagai kontras?

Eksperimen ini juga menyerlahkan berapa banyak kerosakan yang boleh dilakukan melalui konfigurasi sahaja, tanpa menyentuh indeks, perkakasan, atau kod aplikasi. Ini berfungsi sebagai amaran tentang kuasa konfigurasi pangkalan data dan panduan untuk apa yang perlu dielakkan dalam persekitaran pengeluaran.

Latihan ini menunjukkan bahawa memahami sempadan sistem dan mod kegagalan boleh menjadi sama berharga dengan mengetahui teknik pengoptimuman. Untuk pentadbir pangkalan data dan pembangun, melihat titik pecah PostgreSQL memberikan konteks penting untuk membuat keputusan penalaan yang bermaklumat dalam senario dunia sebenar.

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