Pod Python Kamu Kena OOM Kill Padahal RAM Masih Sisa? Jangan Salahkan GC, Salahkan JIT

Kamu deploy FastAPI ke Kubernetes. Request masih sepi. Resource limit udah kamu set 512Mi. Tiga hari kemudian pod kamu di-terminate sama kubelet. Log cuma nulis: OOMKilled. Kamu cek Grafana, RAM usage emang nge spike di atas 600MB padahal workload belum berubah. Kamu mulai curiga memory leak di kode. Kamu profiling GC. Ternyata bukan GC pelakunya. Pelakunya JIT compiler.

⚡ Jawaban Singkat / Key Takeaways

JIT compiler seperti PyPy, Python 3.13 copy-and-patch JIT, atau Numba menyimpan compiled code di memori proses yang bersifat permanen. Di container, overhead ini tidak terlihat di development local, tapi langsung membengkak di production karena compiled code cache tidak pernah dibersihkan. Solusinya bukan mematikan JIT, tapi membatasi cache size, mengatur tier-up threshold, dan menyesuaikan resource limit container secara presisi.

Kenapa JIT Compiler Jadi Rakus RAM di Container

JIT (Just-In-Time) compiler bekerja dengan menerjemahkan bytecode atau IR menjadi machine code native saat runtime. Kode hasil kompilasi ini disimpan di memory region khusus yang disebut code cache. Di proses native biasa, ini bukan masalah besar. Di container dengan cgroups v2 dan memory limit ketat, code cache ini sering jadi pembunuh diam-diam.

Ada tiga mekanisme utama yang bikin JIT makan RAM lebih banyak di container:

• Code cache allocation: Setiap fungsi yang di-JIT dikompilasi dan hasilnya disimpan permanen. PyPy bisa menyimpan puluhan MB compiled code bahkan untuk aplikasi sederhana.
• Tiered compilation buffer: Python 3.13 copy-and-patch JIT menyimpan stencil template dan patch buffer di memori. Ukurannya bisa 15-40 MB tergantung workload.
• Profiling metadata: JIT mengumpulkan profiling counters untuk menentukan fungsi mana yang layak dikompilasi. Data profiling ini juga tinggal di heap.

Di bare-metal server dengan RAM 64GB, overhead 200 MB tidak kelihatan. Di pod Kubernetes dengan limit 512 MiB, itu 40% dari total budget memori kamu hilang sebelum aplikasi mulai kerja.

Copy-and-Patch JIT Python 3.13: Efisien CPU tapi Rakus RAM

Python 3.13 memperkenalkan copy-and-patch JIT, pendekatan eksperimental yang berbeda dari JIT tradisional. Teknik ini menyalin template assembly (stencil) yang sudah disiapkan saat build, lalu menambal (patch) bagian yang perlu disesuaikan. Proses kompilasi super cepat. Tapi konsekuensinya: stencil template harus selalu tersedia di memori.

Di container, setiap worker process Uvicorn atau Gunicorn menyimpan salinan stencil sendiri. Kalau kamu pakai --workers 4 di container, overhead stencil dikali empat. Skenario ini hampir tidak pernah diperhitungkan saat capacity planning.

Baca lebih dalam soal mekanisme copy-and-patch JIT Python 3.13 di artikel sebelumnya: Python 3.13 JIT: Gimana Copy-and-Patch Bikin Kode Kamu Ngebut Tanpa Ribet.

PyPy dan JIT Meta-Tracing: Overhead Memori yang Sering Diremehkan

PyPy pakai pendekatan meta-tracing JIT yang melacak loop panas lalu mengkompilasi trace menjadi machine code. Hebat untuk aplikasi web long-running. Tapi PyPy punya trade-off besar: alokasi memori awal 2x-5x lebih tinggi dibanding CPython.

Kenapa? Karena PyPy mengalokasikan ruang besar di awal untuk:

• JIT trace storage (menyimpan jejak eksekusi sebelum kompilasi)
• Compiled code cache (hasil akhir kompilasi per trace)
• Garbage collector generational yang berbeda dari CPython

Di container Docker standar, aplikasi Flask sederhana yang makan 80 MB di CPython bisa melonjak ke 200-350 MB di PyPy. Tanpa tuning, pod langsung ke-trigger OOM kill begitu traffic naik.

Untuk perbandingan lengkap PyPy vs tools akselerasi Python lainnya, cek: Numba vs Cython vs PyPy vs Python 3.13 JIT: Kamu Selama Ini Salah Pilih Tools Cepat Python-mu?

Strategi Membatasi Overhead Memori JIT di Docker dan Kubernetes

Berikut langkah konkret yang bisa kamu terapkan untuk mengurangi memori yang dimakan JIT compiler di container:

1. Batasi JIT Code Cache dengan Environment Variable

PyPy menyediakan opsi untuk membatasi ukuran code cache lewat environment variable PYPY_GC_MAX dan flag JIT-specific. Python 3.13 JIT saat ini masih eksperimental dan dikontrol lewat PYTHON_JIT=1. Flag tambahan untuk cache limit masih dalam pengembangan, jadi pantau terus changelog resmi Python 3.13.

2. Hitung Ulang Resource Limit Container Berdasarkan Jumlah Worker

Rumus praktis: memory_limit = (base_memory + jit_overhead) × worker_count + buffer. Jangan cuma mengandalkan angka dari development local. Profile container kamu dengan docker stats dan kubectl top pod di staging environment yang menyerupai production. Catat peak RSS, bukan cuma usage rata-rata.

3. Gunakan Single Worker per Pod untuk Beban JIT Tinggi

Ini terdengar kontra-intuitif buat engineer yang terbiasa memaksimalkan CPU. Tapi untuk workload yang diakselerasi JIT, satu worker per pod menghilangkan multiplier efek code cache. Scale secara horizontal dengan menambah pod, bukan menambah worker di dalam pod. Kube-scheduler bisa menyebar beban, tapi code cache tidak bisa di-share antar worker.

4. Pantau Memory Growth Rate, Bukan Cuma Absolute Value

JIT code cache tumbuh secara non-linear di menit-menit pertama setelah pod start. Gunakan Prometheus dengan container_memory_working_set_bytes untuk melihat kurva pertumbuhan. Kalau memori terus naik tanpa plateau setelah 10-15 menit, JIT cache-mu kemungkinan tidak punya upper bound yang benar.

Pendekatan Alternatif: Disable JIT di Container, Enable di Bare-Metal

Kalau aplikasi kamu tidak terlalu bergantung pada throughput CPU-bound, mematikan JIT di container justru bisa lebih stabil. Untuk PyPy, gunakan pypy --jit off. Untuk Python 3.13, cukup tidak set PYTHON_JIT=1. Untuk Numba, gunakan NUMBA_DISABLE_JIT=1.

Namun perlu diingat: beberapa library seperti Numba mengandalkan JIT untuk operasi numerik. Mematikannya bisa bikin kode 10x-100x lebih lambat. Profiling selalu jadi langkah pertama sebelum memutuskan.

Jangan Anggap Remeh Request & Limits di Kubernetes

Kesalahan paling umum adalah menyamakan nilai requests dan limits. Ini berbahaya untuk workload dengan JIT. Pod yang baru start akan consume memori di bawah request. Begitu JIT mulai mengkompilasi hot paths, usage melonjak di atas request tapi masih di bawah limit. Kube-scheduler tidak tahu ini terjadi karena pod tidak di-evict. Tapi node bisa overcommit dan tetangga pod-mu kena dampaknya.

Rekomendasi: set requests di 60-70% dari limits untuk workload JIT. Beri ruang napas buat code cache tumbuh tanpa bikin scheduler salah hitung kapasitas node.

Referensi lebih lanjut: dokumentasi resmi Kubernetes tentang resource management.

Cek Dulu Sebelum Scale: Checklist Pra-Deploy JIT di Container

• Profile RSS peak dengan docker run --memory=512m di staging
• Monitor code cache growth 15 menit pertama setelah pod start
• Hitung multiplier worker: kalau pakai 4 worker, pastikan limit bisa nampung 4x overhead JIT
• Set requests != limits, beri gap 30-40% untuk mengakomodasi JIT cache
• Uji graceful shutdown: pastikan pod tidak kena OOM sebelum graceful termination selesai
• Enable profiling via PYTHONMALLOC=malloc atau tracemalloc untuk validasi sumber alokasi

Kalau kamu sudah deploy JIT di production, baca juga checklist tuning lengkapnya di: Nyalain JIT di Production Itu Kayak Judi Kalau Gak Baca Flags Ini: Tuning Anti Ambyar Buat DevOps.

FAQ: JIT Memory Overhead di Container Python

Kenapa pod Python saya kena OOMKill padahal traffic masih rendah?

Kemungkinan besar JIT compiler mengalokasikan code cache dan profiling metadata. Overhead ini muncul di menit-menit awal setelah pod start, bahkan sebelum traffic tinggi masuk. Cek RSS container kamu dan bandingkan dengan aplikasi yang sama tanpa JIT.

Apa perbedaan overhead memori PyPy vs CPython di container?

PyPy bisa memakan 2x sampai 5x lebih banyak RAM dibanding CPython untuk workload yang sama. Ini karena JIT trace storage, compiled code cache, dan GC generational yang berbeda. Di container dengan limit ketat, overhead ini sering memicu OOM kill.

Apakah Python 3.13 JIT bisa dimatikan kalau tidak dibutuhkan?

Bisa. Python 3.13 JIT bersifat opt-in lewat environment variable PYTHON_JIT=1 atau flag build. Kalau kamu tidak mengaktifkannya, JIT tidak akan berjalan dan tidak ada overhead tambahan. JIT ini masih eksperimental di 3.13, jadi default-nya mati.

Berapa overhead memori rata-rata JIT compiler Python?

Estimasi kasar: PyPy overhead 50-250 MB, Python 3.13 copy-and-patch JIT overhead 15-40 MB, Numba overhead bervariasi tergantung jumlah fungsi yang di-JIT. Overhead ini per proses, jadi dikali jumlah worker kalau kamu pakai multiple worker dalam satu pod.

Kesimpulan

JIT compiler bukan musuh. Tapi di lingkungan containerized, dia adalah tamu yang tidak diundang yang diam-diam mengambil 30-40% budget RAM kamu. Platform engineer dan cloud architect perlu memperhitungkan overhead ini dalam capacity planning, bukan cuma setelah OOM kill pertama terjadi. Batasi code cache, hitung ulang resource limit, dan pertimbangkan single-worker-per-pod untuk workload JIT-intensif.

Dapatkan insight performa dan infrastruktur langsung di inbox kamu. Subscribe newsletter di bawah.