Kemarin restore database yang ukurannya lumayan besar, puluhan gigabyte. Tiga kali total, dua kali di PostgreSQL yang jalan di Colima (Docker di Mac), satu kali lagi di PostgreSQL native. Hasilnya beda jauh, dan itu yang bikin saya gali lebih dalam kenapa.
Setup Docker saya sendiri bukan Docker Desktop, tapi Colima plus lazydocker buat monitoring container dari terminal. Jadi nggak ada GUI, semua kelihatan lewat lazydocker pas restore jalan.
Dua kali gagal di Colima, padahal storage Mac masih longgar.
Di Colima, saya coba restore ini dua kali, dan dua kali juga gagal karena storage penuh. Yang bikin bingung, pas saya cek storage Mac waktu itu masih longgar, kira kira 3x lipat dari ukuran database yang mau direstore.
Ternyata itu dua hal yang beda. Colima bikin VM Linux sendiri buat jalanin Docker-nya, dan disk virtualnya punya ukuran sendiri, ditentukan pas pertama kali colima start (default atau lewat flag --disk). Jadi storage Mac yang masih lega itu storage di sisi host, bukan storage di dalam VM Colima. Kalau disk virtual VM-nya kekecilan buat nampung restore, VM-nya bisa kehabisan space duluan meski Mac-nya sendiri masih longgar. Dua hal ini jalan sendiri-sendiri, cek storage host nggak nunjukin storage yang sebenarnya dipakai PostgreSQL di dalam Colima.
Memory VM-nya sama ceritanya, punya alokasi sendiri terpisah dari RAM Mac. Punya saya awalnya di-set 2GB, jauh di bawah RAM Mac saya sendiri. Di percobaan kedua saya naikin jatah memory itu, kegagalannya tetap sama (storage penuh seperti di atas), dan restore-nya tetap lambat. Jadi nambah memory doang nggak nolong, karena bukan itu yang jadi penghambat utama. Device-nya sendiri (MacBook Pro M1 Pro, 16GB RAM) bukan yang jadi kendala, CPU dan RAM fisiknya lebih dari cukup buat kerjaan ini, cuma jatah yang dikasih ke VM Colima aja yang kecil, dan itu nggak ikut gede sendiri sesuai kapasitas Mac, harus diatur manual.
Colima lebih lambat, dan ini bukan kebetulan.
Colima jalanin Linux VM di balik layar buat Docker-nya. Jadi tiap I/O PostgreSQL di dalam container nembus layer virtualisasi dulu sebelum sampai ke disk fisik Mac. Kalau data directory-nya di-bind-mount dari macOS ke VM, makin parah, lewat virtiofs yang memang bukan dirancang buat I/O berat kayak restore database besar.
PostgreSQL native di Mac langsung baca-tulis ke disk, tanpa lapisan itu. Buat database kecil bedanya nggak kerasa. Buat database seukuran ini, dengan ribuan write acak (index build, WAL, COPY data), bedanya signifikan.
Soal “reserve storage” waktu restore paralel, ternyata bukan itu masalahnya.
Awalnya saya kira pg_restore -j (paralel) itu semacam nge-reserve alokasi storage di depan. Setelah dicek ulang, nggak tepat gitu. pg_restore nggak pernah pre-allocate space kayak fallocate.
Yang kejadian sebenarnya gabungan tiga hal:
- Build index paralel butuh temp file buat sorting kalau
maintenance_work_memnggak cukup besar. Space ini numpuk sementara pas restore jalan, baru dilepas setelah index-nya selesai dibangun. - Restore paralel bikin banyak table di-COPY dan banyak relation file di-extend hampir bersamaan, jadi disk usage kelihatan naik cepat, padahal itu cuma alokasi bertahap yang kebetulan serentak karena paralel.
- Yang paling nempel buat kasus Colima spesifik: disk image VM-nya (qcow2/raw) itu thin-provisioned. Dia tumbuh pas butuh, tapi nggak otomatis ngecil lagi walau data di dalamnya udah dihapus atau di-vacuum. Space yang kelihatan “nggak balik” itu bukan ulah PostgreSQL atau
pg_restore, itu disk image Colima yang nggak otomatis nyusut balik ke host macOS.
Jadi kalau cuma lihat dari luar, “disk makin penuh pas restore paralel” dan “disk nggak balik kosong setelah selesai” itu kelihatan kayak satu fenomena. Padahal dua hal yang beda, satu soal gimana PostgreSQL kerja pas restore paralel, yang sifatnya sementara, satu soal disk image virtual yang nggak ngecil lagi sampai di-trim sendiri.
Pelajaran yang saya pegang sekarang: kalau mau restore database besar, native lebih aman soal waktu. Kalau tetap mau pakai Colima, cek dulu apakah data directory-nya named volume di dalam VM atau bind mount dari host, soalnya beda jauh performanya.