Mengembangkan dan menjalankan aplikasi skala besar seperti Riviera Industrial ERP memerlukan tingkat kestabilan serta efisiensi infrastruktur yang tinggi. Dalam proses pengembangannya, performa basis data sering kali menjadi titik krusial, terutama ketika sistem menangani tugas berat seperti impor data inventaris dalam jumlah besar. Pengalaman teknis yang dibagikan oleh Roberto Luna Osorio, seorang Full Stack Developer dan Project Lead dalam proyek Riviera Industrial ERP di Playa del Carmen, Meksiko, memberikan gambaran nyata mengenai tantangan mengelola alokasi sumber daya pada lingkungan pengujian dan pengembangan.
Pengalaman ini menjadi pelajaran berharga bagi setiap tim pengembang maupun sistem integrator ketika mengevaluasi infrastruktur dari Vendor ERP. Tanpa adanya pembatasan penggunaan memori dan prosesor yang jelas, kontainer basis data dapat menghabiskan seluruh sumber daya komputer induk (host OS) dan menyebabkan gangguan sistem secara menyeluruh.
Masalah Konsumsi Sumber Daya pada Lingkungan ERP
Saat menjalankan Riviera Industrial ERP di lingkungan lokal maupun pada Virtual Machine (VM) pengujian, ditemukan kendala di mana komputer induk menjadi tidak responsif. Masalah ini bermula ketika aplikasi melakukan proses impor data inventaris yang tergolong berat.
Gejala Utama pada Server Pengujian
Gejala yang muncul saat proses impor data berjalan dapat diidentifikasi secara jelas melalui pemantauan sistem:
- Perintah pemantauan sistem (top) menunjukkan bahwa kontainer riviera-db mengambil sumber daya memori lebih dari 2 GB RAM serta mengonsumsi 4 hingga 5 inti CPU secara bersamaan.
- Di sisi lain, layanan aplikasi lainnya berada dalam kondisi idle atau tidak aktif.
- Spesifikasi VM yang digunakan hanya memiliki kapasitas terbatas, yaitu 2 GB RAM dan 2 vCPU.
Kondisi ini membuat kontainer basis data PostgreSQL dengan cepat memicu mekanisme Out Of Memory (OOM) killer dari sistem operasi. Docker mengeluarkan pesan kesalahan teknis yang menyatakan bahwa kontainer riviera-db telah melampaui batas memori 2 GB. Akibatnya, kontainer dihentikan secara paksa oleh sistem, koneksi basis data pada ERP terputus, dan seluruh layanan harus dioperasikan ulang dari awal.
Penyebab Utama dan Percobaan Solusi Awal
Penyebab mendasar dari masalah ini adalah perilaku bawaan Docker Compose. Secara default, Docker Compose memberikan akses tanpa batas kepada kontainer untuk menggunakan seluruh sumber daya fisik yang tersedia pada komputer induk. Meskipun pengaturan default ini cukup memadai untuk tahap pengembangan awal, skenario tersebut sangat berisiko jika diterapkan pada lingkungan bersama (shared environment) atau staging.
1. Pengaturan pada Tingkat Aplikasi
Pendekatan pertama yang dicoba adalah mengendalikan beban kerja langsung dari sisi kode aplikasi. Langkah yang dilakukan meliputi:
- Menambahkan klausul LIMIT pada kueri pemrosesan impor data.
- Membatasi laju kerja dari proses latar belakang (background workers).
Meskipun perubahan kode ini sangat mudah diterapkan, hasilnya belum menyelesaikan masalah utama. Proses impor tetap memakan waktu sekitar 30 menit, dan penggunaan memori PostgreSQL tetap bertahan di atas 1,5 GB. Kendala utama bukan sekadar volume kueri, melainkan alokasi memori internal PostgreSQL—seperti buffer dan proses autovacuum—yang terus berjalan tanpa pembatasan.
2. Pengaturan Global pada Docker Daemon
Pendekatan kedua adalah mencoba menerapkan pembatasan global pada Docker Daemon menggunakan bendera –default-runtime dengan harapan dapat membatasi seluruh kontainer. Namun, metode ini membutuhkan penyuntingan berkas layanan Docker dan proses penuangan ulang (reboot) pada komputer induk. Cara ini dinilai terlalu berat dan tidak portabel untuk diterapkan di berbagai perangkat komputer milik tim pengembang lain.
Solusi Efektif: Pembatasan Per-Kontainer di Docker Compose
Solusi paling bersih dan terstruktur adalah menetapkan batasan sumber daya secara eksplisit untuk setiap layanan langsung di dalam berkas docker-compose.yml. Versi Docker Compose v3+ telah mendukung konfigurasi pembatasan memori (mem_limit atau mem_reservation) dan CPU (cpus) yang dieksekusi oleh Docker Engine saat runtime.
Konfigurasi pada Docker Compose
Dalam kasus Riviera Industrial ERP, pembatasan diterapkan secara khusus pada layanan basis data PostgreSQL dengan menambahkan parameter pembatasan sumber daya:
- mem_limit: 512m untuk membatasi penggunaan RAM maksimal sebesar 512 Megabita.
- cpus: “1” untuk membatasi penggunaan prosesor maksimal sebesar 1 inti CPU.
Setelah konfigurasi tersebut diterapkan dan diperiksa menggunakan perintah docker stats riviera-db, hasilnya mengonfirmasi bahwa kontainer berjalan sesuai dengan batas yang telah ditentukan, yaitu penggunaan memori stabil pada kisaran 210 MiB dari batas maksimal 512 MiB.
Penyesuaian Parameter Internal PostgreSQL
Meskipun Docker telah membatasi ruang lingkup memori melalui cgroups, PostgreSQL tetap berusaha mengalokasikan memori untuk parameter internalnya seperti work_mem dan maintenance_work_mem. Untuk mencegah terjadinya OOM di dalam kontainer itu sendiri, konfigurasi lingkungan (environment block) disesuaikan:
- Pengaturan argumen inisialisasi basis data menggunakan lokasi en_US.UTF-8.
- Penerapan opsi tambahan melalui POSTGRES_EXTRA_OPTS dengan nilai -c work_mem=4MB dan -c maintenance_work_mem=64MB.
Opsi ini diteruskan ke proses utama PostgreSQL saat mulai berjalan, sehingga alokasi buffer internal basis data dapat menyatu secara harmonis dengan batasan memori kontainer Docker.
Hasil dan Manfaat Penerapan Batasan Sumber Daya
Setelah seluruh pembatasan sumber daya diterapkan dan tes impor data inventaris dijalankan ulang, hasilnya menunjukkan peningkatan stabilitas yang signifikan:
- Penggunaan memori kontainer basis data tetap terjaga di bawah batas 512 MiB.
- Komputer induk tidak pernah lagi mengalami kondisi Out Of Memory (OOM).
- Waktu pemrosesan impor data mengalami sedikit peningkatan menjadi sekitar 42 menit, namun seluruh sistem tetap responsif dan dapat digunakan selama proses berlangsung.
Penerapan batasan sumber daya per-kontainer di Docker Compose memberikan kontrol yang terprediksi dan portabel atas konsumsi CPU dan RAM. Cara ini jauh lebih mudah dipelihara dibandingkan pemangkasan beban di tingkat aplikasi secara acak atau perubahan global pada daemon. Dengan membukukan batasan ini dalam berkas konfigurasi, tumpukan teknologi ERP dapat menjaga kestabilan performa saat bertransisi dari lingkungan pengembangan ke staging hingga ke lingkungan produksi.
