VPS Sering Mati Gara-Gara AI Agent? Ini Cara Menguncinya dengan systemd cgroup

Awal Mula VPS Baik-Baik Saja, Sampai Windsurf AI Agent Masuk.

Ceritanya sederhana. Ada sebuah VPS Linux yang sudah berjalan cukup lama melayani beberapa aplikasi web dan riset riset kecil.

Ya mulai dari API backend Node.js, aplikasi PHP, database MariaDB, hingga beberapa bot dan service kecil lainnya. Semua berjalan lancar, stabil, dan tidak ada keluhan berarti. RAM terpakai sekitar 1.5–2 GB dari total yang tersedia, masih ada ruang yang cukup nyaman.

Lalu datanglah si AI Agent.

Tools seperti Windsurf, Cursor, dan sejenisnya memungkinkan developer bekerja langsung dari dalam IDE yang terhubung ke server remote via SSH.

Fiturnya luar biasa dimana AI bisa membaca kode, menulis fungsi, men-debug error, bahkan menjalankan perintah terminal langsung.

Produktivitas naik drastis.

Tapi ada yang aneh.

Tidak lama setelah rutin menggunakan AI Agent yang terhubung ke VPS, server mulai aneh tingkahnya.

Kadang response lambat.

Kadang aplikasi web mendadak tidak bisa diakses.

Beberapa kali bahkan harus login ke panel hosting untuk restart VPS karena sudah tidak responsif sama sekali.

Load average melonjak, dan saat berhasil masuk, RAM sudah penuh hampir 100%.

Awalnya dikira ada bug di aplikasi, atau mungkin ada traffic spike yang tidak terduga. Tapi setelah dicek satu per satu, semua aplikasi baik-baik saja.

Yang bermasalah justru sesuatu yang tidak pernah terpikirkan sebelumnya: proses-proses dari AI Agent itu sendiri.

Analisa: Apa yang Sebenarnya Terjadi?

AI Agent modern seperti Windsurf juga Cursor bekerja dengan cara yang cukup kompleks di balik layar.

Saat kamu membuka koneksi remote ke VPS, bukan hanya satu proses yang berjalan melainkan serangkaian proses yang masing-masing punya fungsi sendiri:

• Language Server — proses utama yang menjalankan AI, melakukan indexing kode, dan berkomunikasi dengan server inferensi di cloud. Ini adalah proses paling berat.
• Extension Host — Node.js process yang menjalankan semua ekstensi IDE.
• Server Main — proses server utama yang mengelola koneksi SSH dan komunikasi antara IDE lokal dengan remote server.
• PTY Host — proses yang mengelola terminal session.
• File Watcher — proses yang memantau perubahan file secara real-time.
• Agent Process (Devin/Cascade) — proses agent AI yang menjalankan task-task otomatis.

Semua proses ini berjalan bersamaan selama sesi aktif.

Dan yang lebih mengejutkan, beberapa proses tetap berjalan di background bahkan setelah IDE-nya ditutup, sampai ada timeout atau server di-restart.

Itulah mengapa RAM terus tergerus meski developer sudah tidak aktif bekerja.

Selain itu, AI Agent juga melakukan code indexing — memindai seluruh file dalam workspace untuk membangun konteks AI. Untuk workspace dengan banyak file, proses ini bisa sangat intensif dan memakan RAM dalam jumlah besar dalam waktu singkat.

Data Riil: Seberapa Besar RAM yang Dimakan AI Agent?

Berikut adalah data aktual dari VPS dengan spesifikasi RAM ~3.73 GB yang menjalankan beberapa aplikasi web, diambil saat AI Agent sedang aktif:

Sementara itu, aplikasi-aplikasi yang seharusnya menjadi tujuan utama VPS ini memakan resource sebagai berikut:

Kesimpulannya: AI Agent sendirian memakan sepertiga total RAM VPS, sementara puluhan service dan aplikasi produktif berbagi dua pertiga sisanya.

Tidak heran VPS sering kehabisan nafas.

Solusi: Mengunci RAM AI Agent dengan systemd cgroup

Setelah mengidentifikasi masalahnya, solusi yang paling tepat bukan mematikan AI Agent-nya  karena justru itu tools yang sedang digunakan untuk bekerja.

Solusinya adalah membatasi berapa RAM yang boleh dimakan, sehingga AI Agent tetap bisa jalan tapi tidak bisa mengambil jatah resource milik aplikasi lain.

Di Linux, cara paling robust dan recommended untuk ini adalah menggunakan systemd cgroup (control group).

Ini adalah fitur kernel Linux yang memungkinkan administrator membatasi, memprioritaskan, dan mengontrol penggunaan resource (RAM, CPU, I/O) dari sekelompok proses sekaligus.

Kenapa tidak pakai cara lain seperti ulimit atau nice/renice? Karena:

• ulimit hanya berlaku per shell session, tidak untuk daemon atau proses background
• nice/renice hanya mengatur prioritas CPU, tidak membatasi RAM
• systemd cgroup berlaku untuk semua proses dalam group secara permanen, termasuk child processes yang di-spawn belakangan

Cara Kerja systemd cgroup

systemd mengorganisir semua proses dalam hierarki slice.

Saat AI Agent terhubung ke VPS via remote SSH sebagai user root, semua prosesnya otomatis masuk ke dalam cgroup:

user.slice → user-0.slice → session-XX.scope

Ini bisa diverifikasi dengan melihat cgroup dari salah satu proses Windsurf:

$ cat /proc/[PID]/cgroup
0::/user.slice/user-0.slice/session-34.scope

Dengan membuat drop-in override pada user-0.slice, semua proses yang berjalan sebagai root (termasuk seluruh proses AI Agent) akan terkena batasan RAM yang kita tentukan.

Ada dua parameter kunci:

Kombinasi keduanya memberikan proteksi berlapis: MemoryHigh sebagai “peringatan dini” yang membuat AI Agent secara alami mengurangi penggunaan RAM, dan MemoryMax sebagai “tembok terakhir” jika tetap membandel.

Langkah Implementasi Step by Step

Berikut langkah lengkap yang bisa diikuti.

Semua perintah dijalankan sebagai root.

Langkah 1: Cek kondisi VPS dan proses AI Agent

Lihat berapa RAM yang sedang dipakai proses AI Agent:

ps aux | awk 'NR>1 {
  if ($0 ~ /windsurf-server/ || $0 ~ /language_server/ || $0 ~ /devin/)
    ws += $6
  else
    other += $6
} END {
  print "AI Agent RSS:", ws/1024, "MB"
  print "Other processes RSS:", other/1024, "MB"
}'

Cek kondisi cgroup user-0.slice saat ini:

systemctl show user-0.slice --property=MemoryMax,MemoryHigh,MemoryCurrent

Langkah 2: Buat direktori drop-in

mkdir -p /etc/systemd/system/user-0.slice.d

Langkah 3: Buat file konfigurasi

nano /etc/systemd/system/user-0.slice.d/windsurf-memlimit.conf

Isi file dengan konfigurasi berikut:

[Slice]
MemoryAccounting=yes
MemoryHigh=1G
MemoryMax=1200M

Sesuaikan nilai MemoryHigh dan MemoryMax dengan spesifikasi VPS kamu:

Langkah 4: Reload systemd dan aktifkan

systemctl daemon-reload

Tidak perlu restart VPS maupun restart AI Agent.

systemd akan langsung menerapkan limit pada cgroup yang sedang berjalan.

Kernel akan otomatis melakukan memory reclaim pada proses yang sudah melebihi batas.

Langkah 5: Verifikasi

systemctl show user-0.slice --property=MemoryMax,MemoryHigh,MemoryCurrent,MemoryAccounting

Output yang diharapkan:

MemoryAccounting=yes
MemoryHigh=1073741824    ← 1 GB dalam bytes
MemoryMax=1258291200     ← 1.2 GB dalam bytes
MemoryCurrent=XXX        ← RAM yang sedang dipakai (harus turun)

Before vs After: Perbandingan Nyata

Berikut perbandingan kondisi VPS sebelum dan sesudah penerapan limit:

Yang menarik: RAM AI Agent turun drastis dari 1.26 GB ke ~715 MB secara instan begitu daemon-reload dijalankan  tanpa perlu restart Windsurf atau disconnect session.

Kernel langsung melakukan pressure dan reclaim memory dari proses-proses yang sudah berjalan.

Tips Tambahan dan Penyesuaian

Jika AI Agent Terasa Lambat

Jika setelah penerapan limit AI Agent terasa lambat atau sering lag, kemungkinan limitnya terlalu ketat.

Naikkan nilainya:

nano /etc/systemd/system/user-0.slice.d/windsurf-memlimit.conf

Ubah ke nilai yang lebih tinggi, misalnya MemoryHigh=1200M dan MemoryMax=1500M, lalu:

systemctl daemon-reload

Monitor RAM secara Real-time

Gunakan perintah ini untuk memantau RAM cgroup secara real-time:

watch -n 2 "systemctl show user-0.slice --property=MemoryCurrent | awk -F= '{printf \"%.0f MB\n\", \$2/1024/1024}'"

Tambahkan Limit CPU (Opsional)

Jika ingin juga membatasi CPU, tambahkan baris berikut ke file konfigurasi yang sama:

[Slice]
MemoryAccounting=yes
MemoryHigh=1G
MemoryMax=1200M
CPUAccounting=yes
CPUQuota=80%

CPUQuota=80% artinya maksimal 80% dari 1 core CPU.

Sesuaikan dengan jumlah core VPS kamu.

Pastikan Swap Tersedia

Swap berfungsi sebagai safety net ketika RAM hampir penuh.

Pastikan VPS kamu punya swap yang cukup:

swapon --show

Jika belum ada swap, pertimbangkan untuk membuat swapfile minimal 1–2 GB.

Dengan swap tersedia, proses tidak akan langsung di-kill saat RAM penuh, melainkan akan “spill” ke swap terlebih dahulu.

Konfigurasi Ini Berlaku untuk User Root

Perlu diingat bahwa drop-in pada user-0.slice berlaku untuk semua proses yang berjalan sebagai root.

Jika kamu memiliki service penting lain yang berjalan sebagai root dan membutuhkan RAM besar, pertimbangkan untuk membuat slice terpisah atau menaikkan MemoryMax ke nilai yang lebih aman.

Kesimpulan

AI Agent adalah tools yang luar biasa produktif tapi ia butuh resource yang tidak sedikit, dan jika dibiarkan tanpa batas di VPS production, ia bisa menggerus resource yang seharusnya menjadi milik aplikasi-aplikasi yang melayani user.

Solusinya bukan memilih antara produktivitas atau stabilitas server.

Dengan systemd cgroup melalui drop-in override, keduanya bisa berjalan berdampingan.

AI Agent tetap bisa bekerja dengan baik di dalam batas yang sudah ditentukan, sementara aplikasi-aplikasi di VPS tetap punya jatah resource yang cukup untuk beroperasi normal.

Konfigurasi ini juga memiliki beberapa keunggulan:

• Permanen — aktif otomatis setiap reboot, tidak perlu setup ulang
• Instan — berlaku tanpa perlu restart proses yang sedang berjalan
• Fleksibel — nilai bisa diubah kapan saja dan langsung berlaku
• Native — menggunakan fitur kernel Linux, tidak butuh tools tambahan
• Berlapis — soft limit (MemoryHigh) + hard limit (MemoryMax) memberikan proteksi ganda

Jika kamu menggunakan VPS untuk production dan juga menggunakan AI Agent sebagai coding assistant, teknik ini sangat direkomendasikan.

Sesuaikan nilainya dengan spesifikasi VPS dan kebutuhan kamu , yang jelas tidak ada satu angka yang cocok untuk semua orang.

Semoga bermanfaat. Jika ada pertanyaan atau pengalaman berbeda, silakan diskusi di kolom komentar.

Artikel ini ditulis berdasarkan pengalaman nyata mengelola VPS Linux dengan beberapa aplikasi web dan AI coding assistant. Semua data yang ditampilkan adalah data riil dari pengujian langsung di server.

Anjrah Ari Susanto, S.Psi.