4. Vacuum Autotuning: Seni Membersihkan Sampah Dead Tuples

Arsitektur Basis Data

Ilustrasi Arsitektur Basis Data Tingkat Enterprise

Paradoks Mutasi: Menghapus Artinya Menambah

Prinsip MVCC di Odoo menghadirkan kondisi unik yang tidak dipahami developer MySQL konvensional. Di PostgreSQL, tindakan Update status pesanan dari "Draft" menjadi "Confirmed" itu sesungguhnya tidak menimpa letak fisik kalimat Draft di memory byte. Yang terjadi: mesin menambah baris Confirmed baru, lalu menandai baris Draft lama dengan cap tengkorak mati (Dead Tuples).

Akumulasi cap tengkorak inilah yang dijuluki "Table Bloat". Jika barisan berlabel tengkorak menumpuk, proses Scan akan tergopoh-gopoh harus membaca lalu memilah mana data yang masih hidup dan mana hantu yang sudah usang.

Pembangkitan Siluman Pembersih (Autovacuum)

Proses Autovacuum hidup di balik tirai hitam bertugas menangkapi dead tuples dan menyucikan memori (space reclamation). Tapi tahukah Anda, setelan default Autovacuum terlalu santai bersandar! Ia baru bangun bergerak ketika persentase autovacuum_vacuum_scale_factor melebihi bongkahan 20% total data.

Pada tabel yang berisi 500.000 pesanan, 20% berarti 100.000 mutasi harus diubah agar ia menyala. Angka raksasa ini kelewat lama; menumpuk kekotoran parah sebelum sapuan perdana pun tiba. Solusi ahli Odoo selalu memaksa angka scale_factor ditekan menjadi di kisaran 0.05 hingga 0.02 pada tabel log krusial.

sql
-- Agresivitas Pembersihan pada Tabel Berat
ALTER class="text-pink-400 font-bold">TABLE stock_quant class="text-pink-400 font-bold">SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_vacuum_cost_limit = 2000
);

Penutup dan Observasi Lanjut

Aturlah Vacuum Anda layaknya koki teliti dengan autovacuum_vacuum_cost_delay agar ia tak mencicipi teramat lahap CPU pada business hours. Kebersihan disk menjaga laju operasional E-Commerce Engine Anda tetap giring gemilang.