Diagnostik Socket Exhaustion dan Alokasi Memori TCP Kernel Saat Traffic Peak Mobile Banking

Setiap tanggal 25 menjelang jam istirahat siang, tim infrastruktur perbankan digital biasanya bersiap di depan dasbor metrik. Lonjakan jutaan pengguna yang mengakses aplikasi secara bersamaan—fenomena traffic peak yang rutin dihadapi aplikasi mobile banking berskala raksasa seperti yang kerap dijumpai pada sistem transaksi perbankan nasional seperti BRImo—bukan sekadar menguji kapasitas database back-end. Sering kali, titik rapuh pertama justru muncul di layer paling depan: edge load balancer dan reverse proxy. Gejalanya klasik dan membingungkan jika hanya melihat utilisasi CPU: load rata-rata mesin hanya berkisar 40%, namun latency p99 melonjak dari 60 ms menjadi di atas 4.000 ms, diiringi ribuan pengguna mengeluhkan pesan "Koneksi Terputus, Silakan Coba Beberapa Saat Lagi". Ketika dmesg pada edge node dibuka, sering kali muncul pesan singkat yang mematikan: TCP: out of memory -- consider tuning tcp_mem atau log hening di mana kernel Linux mulai menjatuhkan paket SYN masuk secara sepihak. Masalah ini bukan semata-mata kekurangan RAM fisik, melainkan kegagalan mengelola alokasi memori subsistem jaringan Linux kernel ketika ratusan ribu socket TCP dan handshake TLS 1.3 terbentuk dalam hitungan detik.

Anatomi Alokasi Memori Socket di Balik Layer TCP

Banyak engineer berasumsi bahwa sebuah koneksi TCP hanya mengonsumsi satu file descriptor. Namun di level kernel, setiap koneksi jaringan memetakan struktur data yang kompleks: struct sock, antrean buffer penerima (sk_receive_queue), antrean pengirim (sk_write_queue), serta berbagai metadata kontrol aliran jaringan. Memori ini dialokasikan dari kernel slab allocator (sock_inode_cache dan TCP slab) serta kernel page allocator untuk sk_buff (skb). Linux mengontrol penggunaan memori subsistem TCP melalui sysctl parameter net.ipv4.tcp_mem. Parameter ini terdiri dari tiga nilai integer yang sering disalahpahami karena satuannya bukan bytes, melainkan page (biasanya 4096 bytes pada arsitektur x86_64):

BASH

# Format: net.ipv4.tcp_mem = min pressure max (dalam 4KB pages)
sysctl -w net.ipv4.tcp_mem='262144 524288 1048576'

Ketika total alokasi halaman memori yang dikonsumsi seluruh socket TCP melampaui batas kedua (pressure threshold), kernel langsung mengaktifkan mode darurat: TCP memory pressure. Pada fase ini, kernel menghentikan pertumbuhan socket buffer otomatis (TCP autotuning), memangkas window size, dan menolak alokasi buffer baru untuk socket yang ada. Jika beban terus naik hingga menyentuh batas ketiga (max), kernel menolak koneksi baru dan membuang paket masuk. Jika node edge memiliki RAM 128 GB namun parameter tcp_mem default dari distro Linux dihitung secara konservatif berdasarkan profil boot awal, edge proxy bisa mengalami memory pressure padahal puluhan gigabyte RAM fisik masih menganggur.

Perangkap Autotuning dan Mitologi Buffer Besar

Salah satu kesalahan fatal yang sering ditemukan pada konfigurasi server performa tinggi hasil salin-tempel dari internet adalah mendongkrak buffer socket setinggi mungkin:

BASH

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Angka 16 MB (16777216 bytes) untuk buffer maksimal memang ideal untuk transfer file bervolume besar pada koneksi high-bandwidth delay product (BDP) seperti sinkronisasi replikasi antar-datacenter. Namun, di layer reverse proxy mobile banking, sebagian besar payload berupa panggilan REST JSON atau gRPC berukuran kecil (kurang dari 8 KB) yang dikirimkan oleh ratusan ribu perangkat ponsel di jaringan seluler 4G/5G dengan latensi fluktuatif. Ketika puluhan ribu koneksi seluler lambat mengalami packet loss, mekanisme autotuning kernel akan mencoba memperbesar buffer penerima dan pengirim untuk menampung window data yang belum di-ACK. Jika 300.000 socket masing-masing mengembang hingga hanya 512 KB saja karena retensi antrean buffer, memori kernel yang tersedot mencapai lebih dari 150 GB—jauh melampaui kapasitas subsistem TCP. Akibatnya, alokasi memori jaringan menyentuh batas tcp_mem pressure, memicu degradasi performa p99 ke seluruh koneksi aktif lainnya, termasuk koneksi klien yang jaringannya normal. Untuk server edge dengan konkurensi masif, batas atas buffer harus dibatasi secara disiplin. Nilai max sebesar 2 MB atau bahkan 1 MB untuk tcp_rmem dan tcp_wmem sudah lebih dari cukup untuk menampung traffic mobile banking modern tanpa memberi ruang bagi koneksi lambat untuk memangsa kernel memory pool secara ugal-ugalan.

Beban User-Space: Dilema TLS Session Resumption

Bottleneck memori di level kernel ini diperparah oleh konsumsi memori di user-space pada reverse proxy seperti HAProxy atau Nginx, terutama terkait terminasi TLS. Dalam arsitektur mobile banking, setiap screen switch atau interaksi API sering kali membuka koneksi baru jika fitur HTTP keep-alive di sisi aplikasi seluler tidak diimplementasikan secara optimal. Untuk memangkas round-trip time (RTT) dan beban kriptografi CPU, engineer mengaktifkan TLS session resumption. Di sini muncul trade-off arsitektural yang kritis:

Stateful Session Cache (SSL_CTX_sess_set_cache_size): Menyimpan state sesi TLS di memori RAM reverse proxy. Untuk 2 juta pengguna aktif dalam jendela 30 menit, penyimpanan cache sesi TLS ini dapat menelan belasan gigabyte RAM user-space. Jika alokasi user-space ini bersaing ketat dengan slab allocator kernel di host yang dibatasi memori oleh cgroups, proses reverse proxy berisiko dieksekusi oleh OOM Killer. Detail penataan batas cgroups ini serupa dengan dinamika alokasi resource yang pernah kita bahas pada panduan konfigurasi cgroups v2.
Stateless Session Tickets (RFC 5077 / TLS 1.3 PSK): Menyerahkan penyimpanan state ke sisi klien dalam bentuk tiket terenkripsi. Pendekatan ini memangkas konsumsi RAM server menjadi nol untuk session tracking. Namun, risikonya berpindah ke distribusi kunci enkripsi tiket (ticket rotation keys) yang harus disinkronisasi ke seluruh armada load balancer secara konsisten agar klien tidak terpaksa melakukan full TLS handshake saat berpindah node edge.

Memilih stateless TLS tickets dengan mekanisme rotasi kunci via memory store terdistribusi adalah satu-satunya cara rasional untuk mempertahankan latensi p99 rendah di edge layer saat traffic peak tanpa membakar RAM server untuk session cache.

Observabilitas Real-Time: Mendeteksi Starvation Sebelum Drop

Mengandalkan monitoring server standar seperti node-exporter sering kali terlambat mendeteksi socket exhaustion karena metrik rata-rata per 15 detik atau 1 menit menyamarkan micro-burst. Tim SRE membutuhkan visibilitas instan ke level antrean socket. Utilitas ss (Socket Statistics) menyediakan telemetri mendalam yang membaca metadata kernel tanpa overhead berat seperti netstat lama:

BASH

# Memeriksa ringkasan memori socket global secara instan
ss -s

# Memantau socket yang memakan alokasi buffer write/read terbesar
ss -ntio 'sport = :443' | head -n 20

Perhatikan metrik skmem pada output ss -i. Jika flag rb (receive buffer) atau tb (transmit buffer) mendekati nilai alokasi maksimum, atau jika field kernel drop counter pada /proc/net/netstat menunjukkan kenaikan angka TCPMemoryPressures dan TCPReqQFullDrop, sistem berada di ambang socket exhaustion. Langkah hardening yang wajib diambil pada node edge edge-facing adalah: pertama, sesuaikan tcp_mem secara proporsional dengan alokasi RAM fisik server (misalnya mengalokasikan 30% hingga 50% RAM khusus untuk TCP pages jika server adalah dedicated load balancer). Kedua, aktifkan net.ipv4.tcp_moderate_rcvbuf = 1 agar kernel secara cerdas mereklamasi memori buffer dari socket yang idle. Ketiga, pastikan net.core.somaxconn dan net.ipv4.tcp_max_syn_backlog dinaikkan ke level rasional (misalnya 16384 atau 32768) untuk mencegah SYN drop saat puluhan ribu handshake masuk bersamaan di awal jam puncak.