Server Solusi – Ketika sebuah VPS tiba-tiba mengalami penurunan performa, website sulit diakses, atau service berhenti tanpa alasan yang jelas, penggunaan RAM menjadi salah satu hal yang perlu diperiksa.

Masalahnya tidak selalu terlihat dari kapasitas disk maupun status CPU. Sebuah VPS bisa memiliki CPU yang masih longgar, kapasitas penyimpanan yang cukup, tetapi tetap mengalami gangguan karena memori tidak lagi mencukupi kebutuhan proses yang berjalan.

Pada Linux, kondisi ini dikenal sebagai Out of Memory (OOM). Ketika sistem tidak dapat memenuhi kebutuhan alokasi memori, kernel dapat menjalankan mekanisme bernama OOM Killer untuk menghentikan proses tertentu agar sistem tetap memiliki kesempatan untuk berjalan.

Dalam lingkungan hosting, dampaknya bisa cukup serius. PHP-FPM dapat berhenti, database mengalami restart, aplikasi Node.js mengalami crash, atau website menampilkan HTTP 502 dan 503.

Hal yang perlu dipahami adalah OOM bukan selalu disebabkan oleh satu aplikasi yang mengalami memory leak. Bisa juga terjadi karena terlalu banyak proses berjalan bersamaan, konfigurasi service terlalu agresif, batas memori container terlalu kecil, atau kapasitas RAM VPS memang tidak sesuai dengan beban kerja.

Saya menyarankan agar kamu tidak langsung menambah RAM atau membuat swap sebelum mengetahui proses mana yang sebenarnya menggunakan memori. Diagnosis yang tepat akan membantu menentukan apakah masalah berasal dari aplikasi, konfigurasi, atau keterbatasan resource VPS.

Mengapa Linux VPS Mengalami Out of Memory?

Linux VPS mengalami Out of Memory ketika sistem atau kelompok proses tertentu tidak lagi memiliki memori yang cukup untuk memenuhi kebutuhan alokasi RAM.

Penyebabnya dapat berupa penggunaan RAM berlebihan, memory leak, terlalu banyak worker aplikasi, database yang membutuhkan memori besar, swap yang tidak tersedia atau sudah penuh, serta pembatasan memori pada cgroup atau container.

Untuk pemeriksaan awal, jalankan:

free -h

Kemudian periksa proses yang menggunakan RAM terbesar:

ps aux --sort=-%mem | head -15

Terakhir, periksa apakah kernel pernah menjalankan OOM Killer:

sudo journalctl -k | grep -iE 'out of memory|oom-kill|killed process'

Jika ditemukan pesan seperti Killed process, kamu perlu mengidentifikasi proses yang dihentikan dan melihat kondisi memori pada waktu kejadian.

Baca JugaCara Mengatasi SSH Connection Refused di VPS: Diagnosis dan Solusi

Solusinya bergantung pada hasil diagnosis. Kamu mungkin perlu mengurangi jumlah worker, memperbaiki aplikasi yang mengalami memory leak, menyesuaikan memory limit service, menambahkan swap, atau meningkatkan kapasitas RAM VPS.

Mengenal Out of Memory dan OOM Killer pada Linux

Sebelum memperbaiki masalah, ada baiknya memahami dua istilah yang sering muncul ketika Linux mengalami kekurangan memori.

Apa itu Out of Memory?

Out of Memory adalah kondisi ketika kernel tidak dapat memenuhi kebutuhan alokasi memori dari proses yang berjalan.

Memori yang dimaksud tidak hanya RAM yang terlihat pada spesifikasi VPS. Linux juga mengelola berbagai jenis penggunaan memori, termasuk:

• Anonymous memory, yaitu memori yang digunakan aplikasi untuk data proses.
• Page cache, yaitu memori untuk menyimpan cache data filesystem.
• Kernel memory, yaitu memori yang digunakan kernel.
• Shared memory, yaitu memori yang dapat digunakan bersama oleh beberapa proses.
• Swap, yaitu area penyimpanan yang digunakan sebagai backing store untuk halaman memori tertentu.

Karena itu, pemeriksaan RAM tidak cukup hanya melihat angka used pada satu perintah.

Apa itu OOM Killer?

OOM Killer merupakan mekanisme kernel Linux untuk memilih proses yang akan dihentikan ketika kondisi kekurangan memori tidak dapat diselesaikan melalui mekanisme reclaim.

Tujuannya adalah membebaskan memori agar sistem masih dapat melanjutkan aktivitasnya.

Namun, proses yang dihentikan tidak selalu merupakan aplikasi yang paling penting bagi website.

Sebagai contoh, jika sebuah VPS menjalankan:

• Nginx.
• PHP-FPM.
• MariaDB.
• Redis.
• Beberapa aplikasi Node.js.

Maka proses yang terkena OOM Killer bergantung pada kondisi memori, konfigurasi, dan pertimbangan pemilihan korban oleh kernel.

Artinya, jangan langsung menganggap database sebagai penyebab hanya karena service database berhenti. Bisa saja database merupakan korban dari kondisi kekurangan memori yang dipicu proses lain.

Gejala Linux VPS Mengalami Out of Memory

Ada beberapa gejala yang dapat membantu mengenali masalah ini.

Website tiba-tiba menampilkan HTTP 502 atau 503

Jika PHP-FPM atau backend aplikasi dihentikan oleh OOM Killer, web server mungkin tidak dapat meneruskan request ke backend.

Baca JugaCara Mengatasi Permission Denied Saat SSH di Linux

Akibatnya, website bisa menampilkan:

502 Bad Gateway

atau:

503 Service Unavailable

Namun, kedua status HTTP tersebut tidak secara khusus menunjukkan masalah RAM. Koneksi upstream, konfigurasi web server, dan service yang gagal juga dapat menjadi penyebabnya.

Service database mengalami restart

MariaDB, MySQL, dan PostgreSQL membutuhkan memori untuk buffer, koneksi, query, dan berbagai aktivitas internal.

Jika konsumsi memori meningkat melebihi kemampuan server, proses database bisa terkena OOM Killer.

Gejala yang mungkin ditemukan antara lain koneksi database terputus dan service kembali berjalan setelah restart.

SSH terasa lambat atau tidak responsif

Ketika sistem mengalami tekanan memori yang berat, aktivitas reclaim dan penggunaan swap dapat meningkatkan latensi.

Dampaknya, login SSH, menjalankan perintah, dan aktivitas administratif lainnya terasa sangat lambat.

Proses aplikasi tiba-tiba berhenti

Aplikasi berbasis PHP, Python, Java, dan Node.js dapat mengalami penghentian proses ketika kernel atau pengelola memori lain mengambil tindakan akibat kekurangan memori.

Pada beberapa kasus, aplikasi mungkin hanya menampilkan pesan:

Killed

Pesan tersebut belum cukup untuk memastikan penyebabnya adalah OOM. Log kernel tetap perlu diperiksa.

VPS mengalami restart atau tidak dapat diakses

Dalam kondisi yang lebih berat, kekurangan memori dapat menyebabkan layanan penting berhenti atau sistem menjadi tidak responsif.

Jika VPS mengalami reboot, periksa apakah ada bukti kernel panic, watchdog, tindakan dari provider, atau penyebab lain. Jangan langsung menyimpulkan bahwa semua restart disebabkan OOM.

Penyebab Out of Memory pada Linux VPS

Sebelum melakukan perubahan konfigurasi, identifikasi sumber konsumsi memori.

RAM VPS tidak mencukupi

Penyebab paling sederhana adalah kapasitas RAM lebih kecil dibandingkan kebutuhan seluruh aplikasi yang berjalan.

Misalnya, VPS menjalankan web server, PHP-FPM, database, Redis, dan beberapa cron job secara bersamaan.

Masing-masing service menggunakan memori. Ketika jumlah request meningkat, kebutuhan RAM juga bisa meningkat.

Jika kapasitas VPS terlalu kecil, sistem dapat mengalami memory pressure meskipun konfigurasi aplikasinya sudah benar.

Memory leak pada aplikasi

Memory leak terjadi ketika aplikasi terus mempertahankan alokasi memori yang seharusnya sudah tidak dibutuhkan.

Baca JugaCara Mencari Penyebab systemctl service failed di Linux

Akibatnya, penggunaan RAM dapat meningkat seiring waktu.

Contohnya adalah aplikasi yang terus menyimpan data ke dalam array, cache internal, atau objek tanpa mekanisme pelepasan memori yang tepat.

Jika penggunaan RAM sebuah proses terus meningkat meskipun trafik relatif stabil, memory leak layak diperiksa.

Terlalu banyak PHP-FPM workers

PHP-FPM menggunakan worker untuk menangani request PHP.

Jika jumlah worker terlalu banyak, total konsumsi memori dapat melampaui kapasitas RAM VPS.

Sebagai ilustrasi, jika satu worker menggunakan rata-rata 80 MB dan server menjalankan 20 worker secara bersamaan, kebutuhan memori worker saja dapat mencapai sekitar 1,6 GB.

Angka tersebut hanya ilustrasi. Penggunaan aktual perlu diukur pada aplikasi yang berjalan.

Konfigurasi pm.max_children menjadi salah satu parameter penting yang perlu diperiksa.

Konfigurasi database terlalu besar

Database dapat menggunakan memori cukup besar untuk buffer pool, cache, koneksi, dan operasi query.

Pada MariaDB atau MySQL, konfigurasi seperti innodb_buffer_pool_size dan jumlah koneksi perlu disesuaikan dengan kapasitas server serta beban aplikasi.

Konfigurasi database yang cocok untuk server dengan RAM 16 GB belum tentu sesuai untuk VPS dengan RAM 2 GB.

Swap tidak tersedia atau terlalu kecil

Swap dapat memberikan ruang tambahan untuk halaman memori yang tidak sedang aktif digunakan.

Jika RAM penuh dan swap tidak tersedia, kernel memiliki lebih sedikit ruang untuk menangani tekanan memori.

Namun, swap bukan pengganti RAM. Penggunaan swap yang terlalu tinggi dapat menyebabkan performa server menurun karena aktivitas baca-tulis disk.

Memory limit pada Docker atau cgroup

Tidak semua kasus OOM terjadi karena RAM seluruh VPS habis.

Docker, systemd, dan mekanisme cgroup Linux dapat membatasi penggunaan memori untuk kelompok proses tertentu.

Sebagai contoh, VPS masih memiliki RAM tersedia, tetapi container memiliki batas memori 512 MB. Ketika container melewati batas tersebut dan tidak dapat melakukan reclaim, proses di dalamnya dapat terkena OOM.

Karena itu, pemeriksaan cgroup perlu dilakukan jika masalah hanya terjadi pada service atau container tertentu.

Cara Mendiagnosis Out of Memory di Linux VPS

Bagian ini menggunakan contoh perintah yang umumnya tersedia pada distribusi Linux modern seperti Ubuntu dan Debian.

Baca JugaCara Mengatasi Disk Full di Ubuntu Server Tanpa Menghapus Data Penting

Beberapa perintah membutuhkan paket tambahan. Jika VPS menggunakan distribusi lain, sesuaikan package manager dan lokasi log yang digunakan.

Langkah 1: Periksa penggunaan RAM secara keseluruhan

Jalankan:

free -h

Perintah ini menampilkan penggunaan RAM dan swap dalam format yang mudah dibaca.

Contoh ilustrasi:

               total        used        freeMem:           3.8Gi       3.1Gi       120MiSwap:          2.0Gi       1.4Gi       600Mi

Kolom yang perlu diperhatikan:

• total: total memori yang tersedia.
• used: memori yang sedang digunakan.
• free: memori yang benar-benar tidak digunakan.
• available: perkiraan memori yang masih dapat digunakan aplikasi tanpa harus melakukan swapping secara berlebihan.
• buff/cache: memori yang digunakan untuk buffer dan cache.

Jangan langsung menganggap RAM penuh hanya karena nilai free kecil.

Linux menggunakan RAM yang tidak sedang dibutuhkan aplikasi untuk cache agar akses data lebih efisien. Nilai available biasanya lebih membantu untuk memperkirakan ruang memori yang masih dapat digunakan.

Jika available terus rendah dan swap semakin terpakai, periksa proses yang menggunakan RAM terbesar.

Langkah 2: Cari proses dengan penggunaan RAM terbesar

Gunakan:

ps aux --sort=-%mem | head -15

Perintah ini menampilkan 15 proses teratas berdasarkan persentase penggunaan memori.

Perhatikan beberapa kolom:

• USER: pengguna yang menjalankan proses.
• PID: identitas proses.
• %MEM: persentase penggunaan memori.
• RSS: jumlah resident memory dalam kilobyte.
• COMMAND: perintah atau aplikasi yang dijalankan.

Jika ingin melihat penggunaan RAM dalam format yang lebih mudah dibaca, gunakan:

ps -eo pid,ppid,user,%mem,rss,comm --sort=-rss | head -15

Nilai RSS menunjukkan ukuran memori fisik yang sedang berada di RAM untuk proses tersebut.

Perlu diperhatikan bahwa RSS antarproses dapat menghitung halaman shared berulang kali. Karena itu, jangan menjumlahkannya begitu saja untuk mendapatkan total konsumsi RAM server.

Jika beberapa proses PHP-FPM terlihat mendominasi penggunaan memori, lanjutkan dengan memeriksa jumlah worker dan konfigurasi PHP-FPM.

Langkah 3: Periksa penggunaan swap

Jalankan:

swapon --show

Perintah ini menampilkan perangkat atau file yang digunakan sebagai swap.

Untuk pemeriksaan ringkas, gunakan:

free -h

Perhatikan nilai swap yang digunakan dan kapasitas yang tersisa.

Jika swap hampir penuh, sistem mungkin mengalami tekanan memori yang cukup berat.

Namun, swap yang terpakai tidak selalu menunjukkan kondisi darurat. Linux dapat mempertahankan halaman memori di swap meskipun tekanan memori saat ini sudah berkurang.

Agar lebih mudah mengamati aktivitas memori, jalankan:

vmstat 1 5

Perintah tersebut menampilkan statistik sistem setiap satu detik sebanyak lima kali.

Perhatikan kolom:

• si: jumlah data yang dibaca dari swap.
• so: jumlah data yang ditulis ke swap.
• free: jumlah memori bebas.
• r: jumlah proses dalam run queue.

Jika nilai si dan so terus meningkat selama pengamatan, ada kemungkinan sistem sedang melakukan aktivitas swapping secara aktif.

Langkah 4: Periksa log OOM Killer

Pemeriksaan ini penting untuk mengetahui apakah kernel benar-benar menghentikan sebuah proses karena kekurangan memori.

Jalankan:

sudo journalctl -k | grep -iE 'out of memory|oom-kill|killed process'

Jika ingin memeriksa kejadian terbaru:

sudo journalctl -k -b -p warning

Kamu mungkin menemukan pesan seperti:

Out of memory: Killed process 1234 (example-process)

Pesan tersebut merupakan ilustrasi format log, bukan hasil pengujian dari VPS tertentu.

Jika ditemukan pesan serupa, perhatikan:

• Nama proses yang dihentikan.
• PID proses.
• Informasi memori ketika kejadian berlangsung.
• Apakah terdapat pesan oom_memcg.
• Apakah proses dihentikan oleh OOM global atau OOM pada memory cgroup.

Jika menggunakan sistem yang tidak menyimpan log kernel melalui journal, kamu dapat mencoba:

sudo dmesg -T | grep -iE 'out of memory|oom-kill|killed process'

Jika tidak ditemukan log, bukan berarti OOM tidak pernah terjadi. Log mungkin sudah tidak tersedia, dibatasi oleh provider, atau kejadian berasal dari mekanisme lain seperti systemd-oomd.

Langkah 5: Periksa apakah service memiliki memory limit

Jika OOM hanya terjadi pada satu service, periksa batas resource yang diterapkan systemd.

Misalnya, untuk PHP-FPM:

systemctl show php8.2-fpm \-p MemoryCurrent \-p MemoryMax \-p MemoryHigh \-p ControlGroup

Ganti nama service sesuai versi PHP-FPM yang digunakan.

Parameter tersebut membantu melihat penggunaan memori dan batas yang diterapkan pada unit systemd.

Jika MemoryMax menunjukkan nilai tertentu, service mungkin memiliki batas memori sendiri.

Untuk melihat proses yang berjalan berdasarkan unit:

systemd-cgtop

Perintah ini menampilkan penggunaan resource pada kelompok control group.

Jika menggunakan Docker, periksa:

docker stats

Perintah tersebut membantu melihat penggunaan memori container yang sedang berjalan.

Jika container memiliki batas memori, periksa konfigurasi container dan nilai memory limit-nya sebelum menyimpulkan bahwa RAM VPS secara keseluruhan habis.

Langkah 6: Periksa informasi memori dari kernel

Linux menyediakan informasi memori melalui /proc/meminfo.

Jalankan:

cat /proc/meminfo

Beberapa parameter yang berguna:

• MemTotal: total RAM yang dikenali kernel.
• MemAvailable: perkiraan memori yang tersedia.
• SwapTotal: total kapasitas swap.
• SwapFree: kapasitas swap yang masih bebas.
• Cached: memori cache.
• Slab: memori yang digunakan untuk struktur data kernel.

Jika ingin memeriksa informasi overcommit memory, jalankan:

cat /proc/sys/vm/overcommit_memory

Nilainya dapat berupa:

Pengaturan ini berkaitan dengan kebijakan alokasi memori virtual. Jangan mengubah nilainya secara sembarangan hanya karena VPS mengalami OOM.

Langkah 7: Periksa apakah systemd-oomd ikut menghentikan proses

Pada beberapa distribusi Linux modern, systemd-oomd dapat digunakan untuk memantau tekanan memori dan mengambil tindakan sebelum kernel mengalami OOM.

Periksa statusnya:

systemctl status systemd-oomd

Kemudian periksa log:

sudo journalctl -u systemd-oomd --since "24 hours ago"

Jika terdapat catatan bahwa systemd-oomd menghentikan sebuah control group, masalahnya tidak selalu berasal dari OOM Killer kernel.

Keduanya merupakan mekanisme berbeda. systemd-oomd bekerja di userspace menggunakan informasi cgroup dan tekanan memori, sedangkan OOM Killer merupakan mekanisme pada kernel.

Cara Mengatasi Out of Memory di Linux VPS

Setelah sumber masalah diketahui, pilih tindakan berdasarkan proses atau service yang terdampak.

Saya menyarankan untuk memulai dari penyesuaian aplikasi dan konfigurasi sebelum melakukan perubahan pada sistem secara keseluruhan.

Solusi 1: Hentikan proses yang tidak diperlukan

Jika ditemukan proses yang menggunakan RAM besar dan memang tidak diperlukan, identifikasi terlebih dahulu fungsi proses tersebut.

Periksa detail proses:

ps -fp PID

Ganti PID dengan identitas proses yang ingin diperiksa.

Jika proses merupakan service systemd, periksa statusnya:

systemctl status nama-service

Jika memang aman untuk dihentikan, gunakan:

sudo systemctl stop nama-service

Perintah ini menghentikan service secara normal melalui systemd.

Jangan langsung menggunakan kill -9 atau menghentikan proses database dan aplikasi produksi tanpa mengetahui dampaknya.

Jika proses merupakan aplikasi penting, lebih baik cari penyebab penggunaan memorinya sebelum menghentikannya.

Solusi 2: Optimalkan jumlah PHP-FPM workers

Pada VPS yang menjalankan banyak website PHP, PHP-FPM dapat menjadi salah satu sumber konsumsi RAM terbesar.

Periksa konfigurasi pool PHP-FPM. Lokasinya bergantung pada distribusi dan versi PHP, tetapi pada Debian atau Ubuntu biasanya berada di:

/etc/php/8.2/fpm/pool.d/

Cari konfigurasi:

pm = dynamicpm.max_children = 50pm.start_servers = 5pm.min_spare_servers = 5pm.max_spare_servers = 10

Nilai di atas hanya contoh, bukan rekomendasi universal.

Parameter yang perlu diperhatikan adalah pm.max_children.

Parameter ini menentukan jumlah maksimum child process yang dapat berjalan bersamaan untuk pool tersebut.

Jika setiap worker menggunakan sekitar 100 MB dan jumlah maksimum worker adalah 50, kebutuhan memori secara teoritis dapat mencapai 5 GB, belum termasuk service lain.

Untuk VPS dengan RAM terbatas, jumlah worker perlu dihitung berdasarkan penggunaan memori aktual.

Setelah mengubah konfigurasi, validasi terlebih dahulu:

sudo php-fpm8.2 -t

Jika binary tersebut tidak tersedia, gunakan binary PHP-FPM sesuai instalasi VPS.

Setelah konfigurasi dinyatakan valid, lakukan reload secara terencana:

sudo systemctl reload php8.2-fpm

Periksa status:

sudo systemctl status php8.2-fpm

Perlu diperhatikan bahwa menurunkan jumlah worker dapat mengurangi konsumsi RAM, tetapi juga membatasi jumlah request PHP yang bisa diproses secara bersamaan.

Jika terlalu rendah, request dapat menumpuk dan waktu respons meningkat.

Solusi 3: Optimalkan penggunaan memori database

Jika MariaDB atau MySQL menggunakan sebagian besar RAM, periksa konfigurasi database sebelum mengubahnya.

Beberapa parameter yang perlu diperhatikan adalah:

innodb_buffer_pool_sizemax_connectionstmp_table_sizemax_heap_table_size

innodb_buffer_pool_size mengatur ukuran buffer pool InnoDB.

Sementara itu, max_connections menentukan jumlah maksimum koneksi klien yang diizinkan.

Jangan langsung menetapkan buffer pool sebesar persentase tertentu dari RAM tanpa memperhitungkan kebutuhan PHP-FPM, web server, sistem operasi, dan service lainnya.

Untuk memeriksa status database, gunakan:

sudo systemctl status mariadb

Jika menggunakan MySQL:

sudo systemctl status mysql

Periksa juga log database untuk menemukan error yang berkaitan dengan alokasi memori atau proses yang berhenti.

Solusi 4: Perbaiki aplikasi yang mengalami memory leak

Jika penggunaan RAM satu proses terus meningkat seiring waktu, periksa kemungkinan memory leak.

Langkah yang dapat dilakukan:

1. Identifikasi proses yang penggunaan memorinya terus meningkat.
2. Periksa log aplikasi.
3. Evaluasi penggunaan cache dan penyimpanan data di memori.
4. Periksa proses background yang tidak pernah selesai.
5. Gunakan profiler atau alat debugging sesuai bahasa pemrograman.
6. Perbaiki bagian aplikasi yang menyebabkan alokasi memori terus bertambah.

Untuk aplikasi Node.js, misalnya, kamu dapat memeriksa penggunaan heap melalui fasilitas monitoring dan profiler bawaan Node.js.

Jangan menjadikan restart service secara berkala sebagai satu-satunya solusi.

Restart memang dapat membebaskan memori yang digunakan proses, tetapi tidak memperbaiki sumber memory leak.

Solusi 5: Tambahkan swap pada VPS

Jika VPS memiliki RAM terbatas, swap dapat menjadi lapisan tambahan untuk membantu menangani tekanan memori.

Swap bukan pengganti RAM, tetapi dapat memberikan ruang bagi kernel untuk memindahkan halaman memori yang tidak sedang aktif digunakan.

Sebelum membuat swap baru, periksa terlebih dahulu:

swapon --show

Jika belum ada swap dan provider VPS mengizinkan penggunaan swap file, kamu dapat membuat swap file.

Contoh berikut membuat swap sebesar 2 GB.

Langkah 1: Buat file swap

sudo fallocate -l 2G /swapfile

Jika fallocate tidak didukung oleh filesystem, alternatifnya:

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

Langkah 2: Atur permission

sudo chmod 600 /swapfile

Permission ini penting agar swap file tidak dapat diakses oleh pengguna lain.

Langkah 3: Format menjadi swap

sudo mkswap /swapfile

Langkah 4: Aktifkan swap

sudo swapon /swapfile

Langkah 5: Periksa hasilnya

free -h

atau:

swapon --show

Jika swap berhasil diaktifkan, kapasitasnya akan terlihat pada hasil pemeriksaan.

Langkah 6: Buat swap aktif kembali setelah reboot

Tambahkan baris berikut ke /etc/fstab:

/swapfile none swap sw 0 0

Sebelum mengedit, backup konfigurasi:

sudo cp -a /etc/fstab /etc/fstab.bak

Pastikan hanya ada satu entri yang benar untuk swap file tersebut.

Setelah itu, validasi konfigurasi:

sudo findmnt --verify --verbose

Jangan menjalankan swapon -a sebelum memastikan konfigurasi sudah benar, terutama jika server memiliki beberapa konfigurasi swap.

Hal yang perlu diperhatikan:

• Swap file membutuhkan ruang disk.
• VPS harus mengizinkan penggunaan swap.
• Performa swap lebih lambat dibandingkan RAM.
• Swap yang terus-menerus aktif dapat menurunkan respons aplikasi.
• Penggunaan swap yang tinggi tetap perlu ditelusuri penyebabnya.

Solusi 6: Sesuaikan memory limit pada Docker atau systemd

Jika OOM hanya terjadi pada container atau service tertentu, periksa batas memorinya.

Untuk Docker, tampilkan informasi container:

docker inspect nama-container

Perhatikan konfigurasi memory limit.

Jika container memang memiliki batas yang terlalu rendah, sesuaikan resource berdasarkan kebutuhan aplikasi dan kapasitas RAM VPS.

Untuk service systemd, konfigurasi resource dapat menggunakan direktif seperti:

[Service]MemoryHigh=1GMemoryMax=1500M

Contoh tersebut hanya ilustrasi.

MemoryHigh merupakan batas tekanan yang digunakan untuk mendorong reclaim dan throttling, sedangkan MemoryMax merupakan batas keras penggunaan memori pada cgroup.

Jangan menyalin angka tersebut tanpa menghitung kebutuhan service.

Setelah mengubah konfigurasi unit systemd, jalankan:

sudo systemctl daemon-reload

Kemudian restart service hanya jika memang diperlukan oleh perubahan konfigurasi.

Periksa kembali:

systemctl show nama-service -p MemoryHigh -p MemoryMax

Perlu dipahami bahwa menaikkan MemoryMax hanya memindahkan batas konsumsi memori. Jika RAM VPS tidak mencukupi, perubahan tersebut dapat membuat tekanan memori sistem semakin berat.

Solusi 7: Tingkatkan kapasitas RAM VPS

Jika hasil diagnosis menunjukkan seluruh service menggunakan memori secara wajar, tetapi total kebutuhan tetap melebihi kapasitas VPS, peningkatan RAM dapat menjadi solusi yang tepat.

Pertimbangkan upgrade ketika:

• MemAvailable sering berada pada level rendah.
• Swap terus mengalami aktivitas tinggi.
• Beban aplikasi meningkat secara konsisten.
• Jumlah worker sudah dioptimalkan.
• Tidak ditemukan memory leak yang belum ditangani.
• Kebutuhan database dan aplikasi memang melampaui spesifikasi VPS.

Sebelum upgrade, evaluasi penggunaan memori pada jam sibuk, bukan hanya saat server sedang sepi.

Dengan begitu, kapasitas baru dapat disesuaikan dengan kebutuhan aktual dan perkiraan pertumbuhan beban aplikasi.

Cara Memverifikasi Setelah Perbaikan

Setelah menerapkan solusi, lakukan pemeriksaan untuk memastikan kondisi memori sudah lebih stabil.

Periksa RAM dan swap

free -h

Bandingkan nilai available, used, dan penggunaan swap sebelum dan sesudah perubahan.

Jangan hanya melihat persentase RAM. Perhatikan juga apakah penggunaan swap terus bertambah.

Pantau proses secara langsung

top

Jika ingin menggunakan tampilan yang lebih interaktif, kamu dapat memasang htop sesuai package manager distribusi Linux.

Perhatikan apakah proses yang sebelumnya menggunakan RAM besar sudah berada pada kondisi yang lebih terkendali.

Periksa log kernel terbaru

sudo journalctl -k --since "30 minutes ago"

Cari pesan terkait OOM, memory allocation failure, dan penghentian proses.

Tidak adanya pesan OOM baru merupakan indikasi yang baik, tetapi belum membuktikan bahwa aplikasi bebas dari masalah memori.

Periksa status service

Contohnya:

sudo systemctl status nginxsudo systemctl status php8.2-fpmsudo systemctl status mariadb

Sesuaikan nama service dengan konfigurasi server.

Pastikan service berjalan normal dan tidak mengalami restart berulang.

Uji website dari sisi HTTP

Gunakan:

curl -I https://example.com

Ganti alamat dengan domain website yang sedang diperiksa.

Perhatikan status HTTP yang diterima.

Jika sebelumnya website mengalami HTTP 502 atau 503, pastikan request sudah dapat diteruskan ke backend dengan benar.

Lakukan juga pengujian dari browser untuk memastikan halaman dan fungsi utama website berjalan normal.

Pantau kondisi saat beban meningkat

Jangan hanya menguji server dalam keadaan sepi.

Jika memungkinkan, lakukan pengamatan ketika website menerima trafik normal atau beban kerja yang representatif.

Tujuannya memastikan konfigurasi baru tidak sekadar menurunkan penggunaan RAM, tetapi juga masih mampu menangani request dengan baik.

Cara Mencegah Out of Memory Terulang

Memperbaiki OOM tanpa memantau penggunaan memori dapat membuat masalah yang sama kembali terjadi.

Ada beberapa langkah yang sebaiknya diterapkan.

Pantau penggunaan RAM dan swap

Gunakan sistem monitoring untuk mengamati:

• Total RAM.
• Memori available.
• Penggunaan swap.
• Memory pressure.
• Konsumsi RAM setiap service.
• Frekuensi restart aplikasi.

Jangan hanya membuat alert berdasarkan persentase RAM terpakai. Perhatikan juga memory pressure dan tren penggunaan swap.

Atur batas worker sesuai kapasitas VPS

Jumlah PHP-FPM workers, database connections, dan proses background perlu disesuaikan dengan kapasitas memori.

Jangan menggunakan konfigurasi yang sama untuk semua VPS.

Setiap server memiliki karakteristik aplikasi, beban, dan kebutuhan memori yang berbeda.

Terapkan monitoring memory leak

Jika menjalankan aplikasi sendiri, pantau konsumsi memori proses dalam jangka waktu tertentu.

Peningkatan memori yang konsisten tanpa alasan yang jelas perlu ditelusuri sebelum menyebabkan gangguan.

Evaluasi cron job dan background process

Cron job yang berjalan bersamaan dapat meningkatkan kebutuhan memori secara tiba-tiba.

Jika terdapat beberapa proses backup, import data, optimasi gambar, atau laporan yang berjalan pada waktu yang sama, pertimbangkan penjadwalan ulang.

Tujuannya menghindari lonjakan penggunaan RAM yang tidak diperlukan.

Sesuaikan kapasitas VPS dengan pertumbuhan aplikasi

Ketika jumlah website, trafik, koneksi database, dan background process meningkat, kebutuhan RAM juga dapat berubah.

Evaluasi spesifikasi VPS secara berkala agar kapasitas memori tidak tertinggal dari perkembangan aplikasi.

Simpan dan evaluasi log OOM

Pastikan log kernel dan service penting tersedia untuk membantu analisis ketika masalah muncul kembali.

Log merupakan sumber informasi penting untuk membedakan proses penyebab tekanan memori dan proses yang hanya menjadi korban OOM Killer.

FAQs

1. Apa penyebab utama Out of Memory pada Linux VPS?

Penyebabnya adalah kebutuhan alokasi memori melebihi kemampuan yang tersedia pada sistem atau batas memori kelompok proses tertentu. Faktor pemicunya bisa berupa RAM kecil, memory leak, terlalu banyak PHP-FPM workers, konfigurasi database, atau memory limit container.

2. Bagaimana cara mengetahui proses yang menyebabkan RAM VPS penuh?

Gunakan:

ps aux --sort=-%mem | head -15

Perintah tersebut menampilkan proses dengan persentase penggunaan RAM terbesar. Untuk memastikan proses yang dihentikan oleh kernel, periksa juga log menggunakan journalctl -k.

3. Apakah menambahkan swap bisa mengatasi Out of Memory?

Swap dapat membantu mengurangi tekanan memori pada kondisi tertentu, terutama ketika terdapat halaman memori yang tidak aktif digunakan. Namun, swap tidak menggantikan RAM dan tidak memperbaiki memory leak atau konsumsi memori aplikasi yang berlebihan.

4. Mengapa VPS mengalami OOM padahal RAM masih tersedia?

Salah satu kemungkinan adalah proses berada di dalam cgroup atau container dengan batas memori tersendiri. Proses juga bisa terkena tindakan systemd-oomd akibat memory pressure. Periksa MemoryMax, konfigurasi container, dan log OOM untuk mengetahui penyebab sebenarnya.

5. Apakah OOM Killer bisa menyebabkan website down?

Bisa. Jika proses PHP-FPM, database, atau backend aplikasi dihentikan, website dapat mengalami HTTP 502, HTTP 503, koneksi database terputus, atau kegagalan memproses request. Dampaknya bergantung pada service yang terkena penghentian.

Penutup

Cara mengatasi Out of Memory di Linux VPS sebaiknya dimulai dengan mencari sumber konsumsi memori, bukan langsung menambahkan swap atau melakukan restart seluruh service.

Gunakan free -h untuk melihat kondisi RAM, ps untuk mengidentifikasi proses dengan penggunaan memori terbesar, dan journalctl -k untuk menemukan bukti apakah kernel pernah menjalankan OOM Killer.

Jika masalah berasal dari PHP-FPM, optimalkan jumlah worker. Jika database terlalu banyak menggunakan memori, evaluasi konfigurasi buffer dan koneksi. Jika terjadi pada container, periksa batas cgroup. Sementara itu, swap dapat digunakan sebagai lapisan tambahan apabila sesuai dengan karakteristik VPS.

Jika seluruh konfigurasi sudah dioptimalkan tetapi kebutuhan memori tetap melebihi kapasitas server, peningkatan RAM merupakan langkah yang lebih masuk akal.

Dengan diagnosis yang sistematis dan pemantauan yang konsisten, kamu dapat mengurangi risiko OOM berulang sekaligus menjaga website dan layanan VPS tetap stabil.