Nginx : fastcgi_buffer & proxy_buffer — Silent Killer RAM

Nginx : fastcgi_buffer & proxy_buffer — Silent Killer RAM

Di banyak kasus server “tiba-tiba” kehabisan RAM, penyebabnya bukan memory leak aplikasi, bukan juga traffic spike ekstrem, melainkan buffer Nginx yang dikonfigurasi sembarangan.

Dua tersangka paling sering:

  • fastcgi_buffer*
  • proxy_buffer*

Masalahnya?
Mereka tidak terlihat, tidak error, dan tidak muncul di log — tapi pelan-pelan menghabiskan RAM.

1. Apa Itu Buffer di Nginx?

Secara sederhana:

  • Buffer = memori sementara untuk menampung response backend
  • Backend bisa:
    • PHP-FPM (fastcgi)
    • Upstream HTTP (proxy_pass)

Nginx bukan streaming by default.
Ia suka:

menerima response backend → simpan di buffer → kirim ke client

Ini efisien kalau dikontrol. Berbahaya kalau tidak.

2. Dua Jenis Buffer Utama

1️⃣ fastcgi_buffer*

Digunakan saat:

  • PHP-FPM
  • CGI / FastCGI backend

2️⃣ proxy_buffer*

Digunakan saat:

  • proxy_pass
  • API
  • microservice
  • upstream HTTP

Keduanya mengonsumsi RAM per request aktif.

3. Salah Kaprah #1: “Buffer Lebih Besar = Lebih Cepat”

❌ Ini mitos.

Contoh konfigurasi yang sering ditemukan:

fastcgi_buffers 16 512k;
fastcgi_buffer_size 512k;

Hitungannya:

  • 16 × 512 KB = 8 MB
  • Per request PHP aktif

100 request bersamaan = 800 MB RAM
Tanpa error. Tanpa warning.

4. Kenapa Disebut Silent Killer?

Karena:

  • Tidak ada error di log
  • Tidak crash langsung
  • RAM naik perlahan
  • Server mati karena OOM killer

Biasanya diagnosisnya salah:

“PHP boros memori”

Padahal:

Nginx yang menimbun response

5. Cara Kerja Buffer yang Jarang Dipahami

Default behavior:

  1. Nginx baca response backend
  2. Simpan di buffer RAM
  3. Jika buffer penuh → spill ke disk (/var/lib/nginx/tmp)
  4. Kirim ke client

⚠️ Jika buffer terlalu besar, Nginx tidak pernah spill ke disk → RAM habis duluan.

6. fastcgi_buffer_size vs fastcgi_buffers

fastcgi_buffer_size

  • Buffer pertama
  • Menampung header + awal body

fastcgi_buffers

  • Buffer tambahan
  • Digunakan jika response lebih besar

Contoh:

fastcgi_buffer_size 16k;
fastcgi_buffers 8 16k;

Total maksimal:

  • 16k + (8 × 16k) = 144 KB per request

Ini jauh lebih masuk akal untuk kebanyakan aplikasi PHP.

7. Kesalahan Fatal: Menyamakan Dev & Production

Di dev:

  • 5 request bersamaan → aman

Di production:

  • 500 request bersamaan → RAM habis

Buffer harus dihitung berdasarkan concurrency, bukan ukuran response terbesar.

8. Proxy Buffer Lebih Berbahaya dari FastCGI

Kenapa?

  • API response bisa besar (JSON, export)
  • Banyak client lambat (mobile, poor network)

Contoh berbahaya:

proxy_buffers 32 256k;

Per request:

  • 8 MB

Jika:

  • 200 client mobile lambat
  • RAM = 💀

9. Kapan Buffer Perlu Besar?

Hanya jika:

  • Backend cepat
  • Client lambat
  • Response besar
  • RAM sangat cukup

Dan tetap harus:

  • Dihitung
  • Dibatasi
  • Dimonitor

10. Kapan Buffer Sebaiknya DIMATIKAN?

Untuk streaming / API besar:

proxy_buffering off;

Atau:

fastcgi_buffering off;

Efek:

  • Response langsung ke client
  • RAM jauh lebih stabil
  • Backend sedikit lebih sibuk

Trade-off ini sering lebih aman.

11. Konfigurasi Aman (Mayoritas Kasus)

PHP / FastCGI

fastcgi_buffer_size 16k;
fastcgi_buffers 8 16k;
fastcgi_busy_buffers_size 32k;

Proxy / API

proxy_buffer_size 16k;
proxy_buffers 8 16k;
proxy_busy_buffers_size 32k;

Ini cukup untuk:

  • 90% aplikasi web
  • Traffic menengah
  • RAM terbatas

12. Disk Buffer ≠ Musuh

Banyak orang takut spill ke disk.

Padahal:

  • Disk jauh lebih murah dari RAM
  • SSD modern sangat cepat
  • Lebih baik lambat sedikit daripada server mati

Pastikan:

proxy_temp_path /var/lib/nginx/tmp;

Disk penuh = masalah lain. Tapi RAM habis = mati sekarang.

13. Cara Audit Buffer di Server Lama

Checklist cepat:

  1. Hitung buffer × concurrency
  2. Cari angka > 1MB per request → waspada
  3. Cek /var/lib/nginx/tmp
  4. Cek htop saat traffic tinggi
  5. Jangan percaya config copy-paste

14. Kesimpulan

fastcgi_buffer dan proxy_buffer itu bukan optimasi default.
Mereka adalah pisau bermata dua.

Server jarang mati karena satu request besar
Server sering mati karena 100 request “sedikit besar”

Jika ingat satu hal saja:

RAM = concurrency × buffer

Related Posts