UNDER PRESSURE

Level 0 · Membaca Tekanan

Sesi 5: Yang Sebenarnya Habis

Sesi 5 / 343 menit baca

1. Bayangkan jika

Bayangkan kamu memiliki sebuah lemari kerja dengan enam laci berbeda. - Laci 1: Kertas formulir (CPU) - Laci 2: Meja tulis (RAM) - Laci 3: Lemari arsip (Disk I/O) - Laci 4: Saluran telepon keluar (Jaringan) - Laci 5: Kunci pintu ruangan (File Descriptor / Socket) - Laci 6: Jumlah kursi petugas (Thread Pool / DB Connection)

Aturan operasionalnya kejam: Kantor dinyatakan lumpuh total begitu SATU laci kosong melompong, meskipun lima laci lainnya masih terisi 90%.

Inilah mimpi buruk para insinyur sistem: memantau dashboard CPU yang adem ayem di angka 15%, sementara pelanggan di luar berteriak karena transaksi mereka mengalami timeout massal.

2. Apa yang sebenarnya terjadi

Sebagian besar tim pemula hanya memantau dua grafik utama: CPU Usage dan RAM Usage. Jika keduanya masih hijau, mereka berasumsi server dalam kondisi sehat.

Padahal di dalam sistem operasi Linux/Unix, server melayani ribuan koneksi menggunakan berbagai abstraksi sumber daya:

  1. File Descriptor (FD): Setiap koneksi TCP/HTTP yang masuk, file log yang dibuka, dan soket database dihitung sebagai 1 File Descriptor. Batas default OS sering kali hanya 1.024. Begitu menyentuh batas: error Too many open files muncul seketika.
  2. Database Connection Pool: Aplikasi Java/Node/Go membatasi koneksi aktif ke DB (misal 50 koneksi). Jika ada 51 request membutuhkan query 2 detik, request ke-51 masuk antrean tunggu pool.
  3. Thread Pool: Jumlah worker thread di server web (misal Tomcat/Puma). Saat semua thread tersumbat menunggu respons eksternal, request baru tertahan di soket kernel.
  4. Disk I/O & IOPS: CPU cepat, RAM lega, tapi antrean penulisan log transaksi membuat disk antre panjang (I/O wait tinggi).
  5. Garbage Collection (GC) Pause: Di runtime seperti Java JVM, saat memori penuh, GC melakukan Stop-the-World pause. CPU melonjak 100% bukan untuk melayani user, melainkan untuk membersihkan sampah memori.

3. Bagaimana jika kita coba cari laci yang bocor?

Misal pada sebuah uji beban API Gateway: - Trafik: 3.000 RPS. - CPU: 22% (Sangat aman). - RAM: 4.2 GB / 16 GB (Lega). - Response Time: Melonjak dari 20 ms \rightarrow 15.000 ms (Timeout).

Setelah diinspeksi ke level kernel: Ternyata File Descriptor limit aplikasi diset di 1024. Pada 3.000 RPS, koneksi masuk langsung ditolak di pintu masuk socket. CPU tetap dingin karena instruksi kodenya bahkan belum sempat dieksekusi.

4. Nama resminya

Istilah Definisi
Resource Saturation Kondisi di mana satu sumber daya tertentu telah mencapai 100% kapasitasnya dan mulai mengantrekan pekerjaan.
Thread Pool Exhaustion Seluruh thread pekerja sedang sibuk; request baru tertahan di antrean internal aplikasi.
Connection Pool Saturation Seluruh koneksi database aktif terpakai; query baru menunggu koneksi dilepaskan.
File Descriptor (FD) Limit Batas maksimal berkas/soket jaringan terbuka per proses (ulimit -n).
I/O Wait (%iowait) Persentase waktu CPU menganggur karena menunggu transfer data dari/ke disk selesai.
GC Pause (Stop-The-World) Jeda runtime di mana seluruh eksekusi aplikasi dihentikan sementara untuk pembersihan memori.

5. Di dunia kita (Sistem Produksi)

Dalam arsitektur microservices modern, saturasi laci sering kali berpindah secara sembunyi-sembunyi:

  1. Kasus Ephemeral Port Exhaustion:
    Microservice A memanggil Microservice B ribuan kali per detik tanpa HTTP Keep-Alive. Port lokal (range 32768–60999) habis karena tersangkut status TIME_WAIT. Layanan gagal menyambung ke upstream.
  2. Kasus Connection Pool Leaks:
    Kode lupa menutup koneksi database di blok finally. Dalam 10 menit, 100 koneksi habis terpakai dan server terkunci permanen.

6. Lensa Performance Tester

  1. Pantau 6 Laci Sekaligus: Jangan pernah menguji beban hanya dengan melihat CPU/RAM. Pantau FD count, Thread count, DB Active Connections, Network PPS, dan Disk IOPS.
  2. Periksa File Descriptor Limit: Pastikan ulimit -n pada OS dan container sudah dinaikkan (misal ke 65535 atau 1048576) sebelum pengujian dimulai.
  3. Waspadai %iowait: Jika CPU tampak 100% tapi mayoritasnya adalah iowait, jangan tambah CPU; ganti storage ke SSD/NVMe atau matikan penulisan log berlebih.
  4. Analisis GC Log: Catat durasi pause JVM. Jika pause GC > 500 ms di p99, itu sumber latency spike utamamu.

7. Pertanyaan untuk ronde berikutnya

Sesi 6: "Hukum yang Membatasi Segalanya"
Bagaimana jika kita mencoba menggandakan server dari 10 menjadi 20 mesin, tapi kapasitasnya hanya naik 40%?
Dan kenapa saat ditambah jadi 40 mesin, kapasitas sistemnya justru anjlok turun?
Jawabannya ada pada Amdahl's Law & Universal Scalability Law (USL).