Wawancara Linux: Mengapa RSS Tetap Tinggi Setelah Memori Dibebaskan?

Konteks dan Skenario yang Berlaku

Sebuah layanan Linux dengan 64 thread yang menggunakan glibc malloc dimulai pada 800 MiB RSS. Suatu proses batch berkala mendorong RSS hingga 6 GiB. Dua puluh menit setelah batch selesai, heap profiler aplikasi melaporkan 1,1 GiB alokasi aktif, tetapi RSS tetap berada di 5,2 GiB. Proses tersebut berjalan di bawah batas cgroup 8 GiB dan memiliki SLO latensi p99 sebesar 120 ms. Jelaskan mengapa free() tidak menjamin penurunan RSS, buktikan apakah selisih tersebut merupakan kebocoran (leak), retensi alokator, fragmentasi, atau pemetaan lain, serta pilih remediasi yang aman.

Jumlah thread, nilai memori, interval idle, batas, dan SLO adalah asumsi latihan. Asumsikan proses native, glibc malloc, cgroup v2, tanpa child process, dan batch yang dapat diulang. Runtime terkelola (managed runtime) akan menambahkan heap, garbage collector, dan lapisan alokasi native-nya sendiri. Pertanyaan ini termasuk dalam general karena keahlian utamanya adalah akuntansi proses Linux dan perilaku alokator, bukan sintaksis bahasa aplikasi.

Materi wawancara saat ini secara eksplisit memperlakukan free list, size class, alokasi thread-local, dan fragmentasi sebagai poin diskusi wawancara sistem. Dokumentasi produksi Redis menjelaskan gejala teramati yang sama: menghapus data logis dapat membiarkan RSS mendekati puncak sebelumnya karena chunk bebas tetap tersedia bagi alokator atau halaman masih berisi objek aktif. Dokumentasi Linux dan glibc kemudian menyediakan metrik pengukuran dan kontrol yang diperlukan untuk jawaban berbasis bukti. Sumber-sumber ini menetapkan relevansi dan mekanismenya; sumber tersebut tidak membuktikan bahwa perusahaan tertentu menggunakan pertanyaan persis ini atau bahwa pertanyaan ini ditanyakan pada frekuensi tertentu.

Apa yang Dievaluasi oleh Pewawancara

Sinyal pertama adalah apakah Anda memisahkan kepemilikan (ownership) dari residensi (residency). Setelah free(p), pemanggil tidak lagi memiliki alokasi tersebut dan alokator dapat menggunakan kembali blok tersebut. Kontrak alokasi C tidak menjanjikan munmap, RSS yang lebih rendah, atau reklamasi halaman fisik secara langsung. Mengatakan "free selalu mengembalikan memori" atau "free tidak pernah mengembalikan memori" mengabaikan alur spesifik dari alokator.

Sinyal kedua adalah apakah Anda memisahkan empat lapisan pengukuran:

• alokasi aktif (live allocations) aplikasi;
• byte yang sedang digunakan, bebas, terpetakan, dan dapat dilepaskan pada alokator;
• pemetaan proses dan halaman residen;
• beban (charge) dan tekanan di seluruh cgroup.

RSS bukanlah penghitung heap aktif. Linux mendefinisikan VmRSS sebagai RssAnon + RssFile + RssShmem. Pemetaan file, memori bersama (shared memory), stack, metadata alokator, dan library native semuanya dapat memperlebar selisih tersebut. Oleh karena itu, profil heap dan satu pembacaan top tidak dapat membuktikan atau menyangkal adanya kebocoran.

Sinyal ketiga adalah kemampuan diskriminasi diagnostik. Kebocoran membuat alokasi tetap dapat dijangkau (reachable) atau tetap aktif. Retensi berarti memori bebas tetap dipetakan untuk penggunaan kembali yang efisien. Fragmentasi berarti alokator memiliki byte bebas tetapi tidak dapat membentuk wilayah seukuran halaman yang dapat dilepaskan, sering kali karena beberapa objek aktif menahan (pin) halaman atau ruang bebas terbagi di antara arena dan size class. Kondisi-kondisi ini dapat terjadi bersamaan, sehingga kandidat memerlukan observasi yang terkontrol daripada sekadar label yang disimpulkan dari satu rasio.

Terakhir, pewawancara menginginkan keputusan tingkat produksi. Mengurangi jumlah arena, memangkas secara agresif, atau mengganti alokator dapat mengurangi memori residen tetapi menambah lock, page fault, system call, atau beban CPU. Jawaban yang kuat melindungi batas 8 GiB dan SLO p99 120 ms dengan deployment canary, pemutaran ulang beban kerja (workload replay), ambang penerimaan, dan rollback.

Pertanyaan Klarifikasi Sebelum Menjawab

• Alokator dan versi mana yang aktif? glibc tunables dan malloc_trim tidak menjelaskan jemalloc, tcmalloc, mimalloc, alokator runtime bahasa, atau pengganti yang ditautkan secara statis. Konfirmasikan alokator yang dimuat dan image deployment sebelum menggunakan penghitungnya.
• Apa sebenarnya yang melaporkan 1,1 GiB? Profil heap berbasis sampel, penghitung alokator yang tepat, heap runtime terkelola, dan metrik cache bisnis mencakup byte yang berbeda. Konfirmasikan apakah library native, stack, pemetaan langsung, dan metadata alokator disertakan.
• Komponen RSS mana yang tetap tinggi? RssAnon mengarah ke heap, stack, dan pemetaan anonim; RssFile mengarah ke pemetaan berbasis file; RssShmem mengarah ke memori bersama. Jika peningkatan tersebut bukan anonim, penyesuaian alokator adalah langkah awal yang salah.
• Apakah plateau berulang atau terus naik setelah setiap batch yang identik? Plateau batas atas yang stabil dan melayani batch berikutnya tanpa kenaikan 5 GiB lainnya mengindikasikan adanya penggunaan kembali (reuse). Kenaikan bertingkat (staircase) pada alokasi aktif atau RSS memerlukan penjelasan berupa kebocoran, beban kerja, atau pemetaan.
• Apakah jumlah thread, ukuran alokasi, atau masa hidup objek berubah? Banyaknya thread dan pembebasan lintas thread dapat menyebarkan blok ke seluruh arena atau cache. Campuran objek berumur pendek dan panjang dapat menyisakan satu objek yang bertahan pada banyak halaman yang sebenarnya sebagian besar kosong.
• Apakah cgroup benar-benar mengalami tekanan? Bandingkan memory.current, memory.events, PSI, swap, dan proses di sekitarnya. RSS yang tinggi dengan ruang kosong (headroom) yang cukup mungkin hanya masalah efisiensi; kejadian memory.high yang berulang atau kedekatan dengan batas 8 GiB membuat perilaku pelepasan memori menjadi mendesak secara operasional.
• Kapan batch berikutnya akan berjalan? Menyimpan 4 GiB agar dapat digunakan kembali selama lima menit mungkin rasional. Menyimpannya selama dua belas jam kondisi idle di bawah batas yang ketat dapat membenarkan pembersihan (purge) pasca-batch atau pola alokasi yang berbeda.
• Berapa batas regresi yang dapat diterima? Solusinya berubah jika layanan dapat menggunakan 2% lebih banyak CPU tetapi tidak boleh menambah 5 ms pada p99, atau jika biaya memori lebih penting daripada latensi alokasi dingin (cold-allocation).

Kerangka Jawaban 30 Detik

"free() mengembalikan blok ke alokator; fungsi ini tidak menjamin pembatalan pemetaan (unmap) halamannya, sehingga RSS dapat tetap tinggi tanpa adanya kebocoran. Saya akan menyelaraskan linimasa satu batch dan membandingkan profil alokasi aktif, byte yang digunakan dan bebas pada alokator, RssAnon, smaps per pemetaan, dan penggunaan cgroup. Kemudian saya akan mengulang batch tiga kali. Byte aktif yang bertambah mengindikasikan kebocoran; byte aktif yang stabil ditambah RSS datar yang digunakan kembali oleh batch berikutnya mengindikasikan retensi; byte bebas alokator yang melimpah dengan sedikit memori yang dapat dilepaskan dan halaman yang tertahan oleh objek yang bertahan mengindikasikan fragmentasi. Saya akan menggunakan malloc_trim(0) hanya sebagai eksperimen canary glibc, bukan perbaikan menyeluruh. Solusi akhirnya dapat berupa perbaikan kepemilikan, pemisahan masa hidup objek, pemangkasan terbatas pasca-batch, penyesuaian arena yang teruji, atau penggantian alokator, yang hanya diterima jika replay beban kerja produksi tetap berada di bawah target memori tanpa melanggar p99 120 ms."

Pembahasan Mendalam Langkah-demi-Langkah

Langkah 1: Bangun Satu Linimasa Memori

Catat versi deployment, PID, path cgroup, jumlah thread, volume permintaan dan batch, distribusi laju alokasi, byte aktif, komponen RSS, memory.current, memory.peak, tekanan (pressure), dan kejadian OOM. Ambil sampel sebelum batch, pada puncak 6 GiB, segera setelah dealokasi, dan sepanjang jendela idle 20 menit. PID, cgroup, atau beban kerja yang berbeda akan membuat perbandingan tidak valid.

Pertanyaan pertama bersifat operasional: apakah RSS hanya sekadar tinggi, atau layanan mendekati batas dan melakukan reklamasi di bawah tekanan? Pada 5,2 GiB di dalam batas 8 GiB, ruang kosong yang tampak adalah 2,8 GiB sebelum beban cgroup lainnya diperhitungkan. Pengurangan tersebut hanyalah pemeriksaan skala karena cgroup juga memperhitungkan memori di luar RSS anonim proses ini. Gunakan memory.current dan memory.stat untuk domain yang sebenarnya.

Langkah 2: Jelaskan Batas Antara Alokator dan Kernel

Alokator meminta wilayah yang lebih besar dari sistem operasi dan membaginya menjadi beberapa chunk. glibc dapat memperluas arena biasa dan dapat membuat pemetaan anonim terpisah untuk alokasi yang cukup besar. Ketika aplikasi membebaskan sebuah chunk, alokator pertama-tama membuat chunk tersebut dapat digunakan kembali. Alokator dapat menggabungkan (coalesce) chunk bebas yang berdekatan, menempatkannya di bin atau cache, menahannya untuk menghindari system call di masa mendatang, atau melepaskan halaman yang sesuai.

Chunk besar yang dipetakan secara independen sering kali dapat langsung di-unmap saat dibebaskan. Memori heap biasa lebih sulit. Blok bebas di tengah suatu wilayah tidak dapat menyusutkan ujung heap, dan halaman yang berisi satu saja objek pointer mentah aktif tidak dapat di-unmap tanpa memindahkan objek tersebut. Alokator C dan C++ umumnya tidak dapat memadatkan (compact) sembarang objek aktif karena pointer aplikasi akan menjadi tidak valid.

Hal ini menghasilkan tiga jenis overhead yang berbeda:

• Fragmentasi internal: permintaan 20 byte dapat mengonsumsi blok perataan (aligned) atau size-class yang lebih besar.
• Fragmentasi eksternal atau tingkat halaman: ruang bebas ada, tetapi terpecah atau tertahan sehingga seluruh halaman tidak dapat dilepaskan.
• Retensi yang disengaja: seluruh atau sebagian halaman tetap dipetakan karena alokator mengantisipasi penggunaan kembali dan proses pelepasan/akuisisi ulang memiliki beban biaya.

Label-label ini menggambarkan mekanisme, bukan kesimpulan dari satu rasio RSS / live_bytes saja.

Langkah 3: Rekonsiliasi Empat Lapisan Pengukuran

Mulailah dengan akuntansi proses Linux:

VmRSS = RssAnon + RssFile + RssShmem

Baca /proc/PID/status untuk pembagian secara garis besar dan /proc/PID/smaps_rollup untuk informasi agregat RSS, PSS, anonim, file, shared, dan lazy-free. Gunakan /proc/PID/smaps hanya ketika Anda perlu mengidentifikasi pemetaan anonim atau berbasis file tertentu yang mengalami peningkatan. Total pmap atau RSS satu kali kurang informatif dibandingkan delta yang disinkronkan.

Kemudian tambahkan statistik alokator. Di glibc, mallinfo2 dapat menampilkan byte yang diperoleh melalui sbrk, byte dalam chunk yang dipetakan, byte yang diserahkan ke pemanggil, byte bebas, dan chunk teratas yang dapat dilepaskan. Field-field ini tidak mencakup setiap sumber alokasi dan harus diambil sampelnya secara konsisten, tetapi membantu menjawab apakah alokator memiliki sebagian besar dari selisih anonim tersebut. Utamakan profiling bawaan alokator aplikasi jika menyediakan data pemetaan, aktif, residen, retensi, dan per-size-class yang lebih lengkap.

Terakhir, lakukan rekonsiliasi dengan cgroup v2. cgroup mencakup semua memori yang dibebankan dalam hierarkinya, sehingga dapat melebihi RSS satu proses atau berubah karena alasan lain. Bandingkan memory.current dan memory.stat dengan bukti dari proses alih-alih memaksanya harus sama.

Langkah 4: Gunakan Eksperimen Penggunaan Kembali Tiga Siklus

Jalankan batch yang sama sebanyak tiga kali pada lingkungan canary yang menyerupai produksi dengan konkurensi 64 thread dan distribusi ukuran input yang sama. Setelah setiap batch, tunggu selama 20 menit yang sama dan catat penghitung yang sama.

Interpretasikan polanya:

Plateau tidak otomatis berarti tidak berbahaya. Jika batch berikutnya memuncak di atas 8 GiB karena halaman lama yang ditahan tidak dapat melayani distribusi ukuran barunya, layanan masih dapat gagal meskipun data logis stabil. Sebaliknya, plateau tinggi yang secara efisien melayani beban kerja yang sama mungkin lebih disukai daripada pelepasan paksa dan page fault yang berulang.

Langkah 5: Gunakan Trim sebagai Diagnostik Terbatas

Pada canary glibc, panggil malloc_trim(0) satu kali pada batas pasca-batch dan catat nilai kembaliannya, komponen RSS, byte aktif alokator, page fault, CPU, dan latensi permintaan berikutnya. Antarmuka GNU mencoba melepaskan memori heap bebas dan dapat menggunakan sbrk atau madvise; fungsi ini tidak menjanjikan pengurangan RSS dalam jumlah tertentu.

Jika RssAnon turun secara signifikan sementara alokasi aktif tetap pada 1,1 GiB, berarti beberapa halaman milik alokator dapat dilepaskan. Hal itu mempersempit diagnosis, tetapi tidak membuktikan bahwa memanggil trim di lingkungan produksi adalah kebijakan terbaik. Jika RSS hampir tidak berubah, seluruh halaman bebas mungkin tidak tersedia, peningkatan mungkin berada di luar glibc, atau metrik mencakup pemetaan yang berbeda. Kegagalan fungsi trim tidak membuktikan adanya kebocoran.

Jangan pernah menempatkan trim pada setiap permintaan. Melepaskan halaman dapat menukar memori residen dengan system call, minor fault, pengisian nol (zero filling), hilangnya cache, dan latensi ekor saat batch berikutnya tiba. Batas fase alami dengan jendela idle yang panjang adalah kandidat yang lebih masuk akal, dan itu pun masih memerlukan uji canary.

Langkah 6: Sesuaikan Remediasi dengan Penyebab yang Terbukti

• Kebocoran: perbaiki referensi kepemilikan, batas cache, free yang terlewat, atau siklus hidup library. Pemangkasan (trimming) tidak membuat memori aktif menjadi dapat dilepaskan.
• Retensi yang disengaja dengan penggunaan kembali jangka pendek: pertahankan, alokasikan kapasitas untuk puncak yang terukur, dan pasang peringatan (alert) pada pola kenaikan bertingkat yang berulang daripada memaksa RSS agar cocok dengan byte aktif.
• Fragmentasi akibat masa hidup objek: pisahkan objek batch berumur pendek dari state layanan berumur panjang, gunakan arena atau region batch yang dapat dilepaskan sebagai satu kesatuan, dan hindari menyisipkan satu objek berumur panjang di banyak halaman yang bersifat sementara.
• Dispersi arena atau thread-cache: uji jumlah arena yang lebih sedikit, kurangi konkurensi pada titik panas alokasi, atau gunakan pola kepemilikan yang berbeda. Arena yang lebih sedikit dapat menghemat memori tetapi meningkatkan pertikaian (contention).
• Fase idle panjang di bawah batas ketat: uji satu kali trim eksplisit pasca-batch atau pembersihan khusus alokator dengan pembatasan laju (rate limit) dan flag rollback.
• Ketidakcocokan alokator: bandingkan glibc dengan alternatif yang sesuai di bawah trace beban kerja yang identik. Desain mimalloc dari Microsoft Research menggambarkan pertukaran intinya: halaman thread-local meningkatkan skalabilitas dan lokalitas, sementara kepemilikan yang terisolasi dapat menahan memori yang tidak dapat langsung digunakan kembali oleh thread lain.

arena_max, trim_threshold, dan mmap_threshold pada glibc adalah bahan eksperimen, bukan konstanta ajaib. Mengaturnya membuat perilaku lebih statis dan dapat mengubah contention, jumlah pemetaan, frekuensi pelepasan, dan biaya syscall. Ubah satu faktor pada satu waktu dan pertahankan image asli sebagai langkah rollback.

Langkah 7: Validasi Memori dan Latensi Secara Bersamaan

Putar ulang 30 siklus identik pada perangkat keras yang menyerupai produksi. Angka 30 adalah jendela pengujian latihan, bukan persyaratan universal. Lacak alokasi aktif, byte terpetakan/bebas/dapat dilepaskan pada alokator, RssAnon, total RSS, memory.current, tekanan, page fault, latensi alokasi, CPU, throughput, dan latensi permintaan p50/p99.

Contoh kriteria penerimaan untuk skenario ini dapat berupa: RssAnon pasca-idle berada pada atau di bawah 2,2 GiB dalam 20 menit, tidak ada kenaikan bertingkat selama 30 siklus, tidak ada OOM atau tekanan berkelanjutan, p99 berada pada atau di bawah 120 ms, dan regresi CPU tidak lebih dari 3%. Ambang batas ini adalah asumsi latihan yang harus diganti dengan anggaran riil dari layanan tersebut. Remediasi yang mencapai 2,2 GiB tetapi mendorong p99 ke 145 ms dianggap gagal; remediasi yang mempertahankan latensi tetapi tetap mendekati batas 8 GiB di bawah komposisi ukuran valid berikutnya juga dianggap gagal.

Contoh Jawaban Berkualitas Tinggi

"Saya tidak akan langsung menyebut ini sebagai kebocoran hanya dari metrik RSS. free() mengakhiri kepemilikan aplikasi atas suatu blok, tetapi glibc dapat menyimpan blok tersebut di arena untuk digunakan kembali, dan beberapa objek aktif dapat membuat halaman yang sebenarnya bebas tetap berstatus residen. Pertama-tama saya akan memverifikasi bahwa angka 1,1 GiB mencakup alokasi aktif native, kemudian menyelaraskannya dengan pemetaan RssAnon, RssFile, RssShmem, smaps, statistik alokator, dan beban cgroup sepanjang satu siklus batch penuh.

Saya akan memutar ulang batch yang sama sebanyak tiga kali. Jika alokasi aktif meningkat setelah setiap periode idle 20 menit, saya akan membandingkan profil objek aktif dan memperbaiki alur kepemilikannya. Jika byte aktif tetap di 1,1 GiB, RSS tetap mendekati 5,2 GiB, dan batch berikutnya menggunakan kembali ruang tersebut tanpa lonjakan lain, maka retensi adalah penjelasan yang lebih kuat. Jika byte bebas alokator tinggi tetapi halaman yang dapat dilepaskan tetap rendah dan plateau berubah sesuai masa hidup objek atau konkurensi 64 thread, saya akan menyelidiki fragmentasi dan dispersi arena.

Sebagai diagnostik khusus glibc, saya akan memanggil malloc_trim(0) satu kali pada canary setelah batch selesai. RssAnon yang lebih rendah dengan byte aktif yang tidak berubah menunjukkan bahwa beberapa halaman alokator memang dapat dilepaskan; hal ini tidak membenarkan pemangkasan pada setiap permintaan. Saya kemudian akan memilih perubahan terkecil yang sesuai dengan penyebabnya: memperbaiki kebocoran, memisahkan masa hidup batch ke dalam region yang dapat dilepaskan, atau menguji canary untuk pemangkasan pasca-batch yang terbatas atau konfigurasi arena. Saya akan memutar ulang 30 siklus dan menerima perubahan tersebut hanya jika memori pasca-idle memenuhi target yang disepakati, RSS tidak naik bertingkat, cgroup tetap aman, dan p99 tetap berada di dalam batas 120 ms."

Kesalahan Umum

• Menyebut selisih 4,1 GiB sebagai kebocoran → RSS mencakup halaman bebas alokator dan pemetaan non-heap → buktikan pertumbuhan dalam alokasi aktif atau kepemilikan yang tertahan dengan profil yang disinkronkan.
• Mengklaim free() selalu menurunkan RSS → chunk yang dibebaskan dapat tetap berada di arena atau berbagi halaman dengan chunk aktif → jelaskan penggunaan kembali, pelepasan halaman utuh, dan alokasi yang dipetakan secara independen.
• Mengklaim free() tidak pernah mengembalikan memori → alokator dapat membatalkan pemetaan besar, memangkas top chunk, atau menghapus halaman bebas secara utuh dengan advise → nyatakan bahwa pelepasan bergantung pada alokator, tata letak, dan kebijakan.
• Menggunakan satu rasio fragmentasi sebagai bukti → lonjakan beban baru-baru ini, pemetaan file, cache, atau retensi yang disengaja dapat meningkatkannya → bandingkan byte aktif, bebas, terpetakan, residen, dan yang dapat dilepaskan melalui siklus berulang.
• Memanggil malloc_trim(0) pada setiap permintaan → pelepasan paksa dapat menambah syscall, fault, dan latensi ekor → uji satu kali pada batas idle alami dan ukur lonjakan alokasi berikutnya.
• Mengatur arena_max ke satu karena ada 64 thread → memori mungkin turun sementara lock contention meningkat → uji rentang nilai kandidat di bawah konkurensi yang sama dan lindungi p99.
• Mengganti alokator hanya berdasarkan headline benchmark → ukuran alokasi, masa hidup, dan pola pembebasan lintas thread menentukan hasil → lakukan uji A/B pada trace yang tepat dengan opsi rollback serta kriteria memori dan latensi.
• Mengabaikan akuntansi cgroup → RSS dari satu proses bukanlah keseluruhan domain memori → rekonsiliasi memory.current, memory.stat, proses turunan (descendant), dan tekanan dengan metrik proses.

Pertanyaan Lanjutan dan Tanggapan

Jika malloc_trim(0) menurunkan RSS dari 5,2 GiB ke 1,8 GiB, apa yang telah Anda buktikan?

Anda telah menunjukkan bahwa glibc memiliki sejumlah besar memori yang dapat dilepaskan pada tingkat halaman pada saat itu dan bahwa RSS yang tinggi bukan seluruhnya data aplikasi aktif. Anda belum membuktikan tidak adanya kebocoran yang lebih kecil, penyebab retensi, atau keamanan pemangkasan yang sering. Jalankan kembali beban kerja dan ukur page fault, CPU, latensi alokasi, dan p99 sebelum memilih kebijakan.

Jika fungsi trim mengembalikan nol dan RSS tidak bergerak, apakah itu kebocoran?

Tidak. Ruang bebas mungkin tersebar di seluruh halaman yang masih berisi chunk aktif, memori mungkin ditahan di alokator atau pemetaan lain, atau tidak ada halaman glibc yang dapat dilepaskan. Bandingkan profil aktif, byte bebas dan yang dapat dilepaskan pada alokator, serta kepemilikan smaps. Kebocoran membutuhkan bukti bertumbuhnya alokasi aktif atau tertahan, bukan sekadar pemangkasan yang tidak berhasil.

Bagaimana jika RSS tetap datar tetapi memory.current terus bertambah?

Selidiki delta cgroup alih-alih heap. memory.stat dapat mengungkap file cache, shmem, socket, atau memori kernel, dan cgroup tersebut mungkin mencakup proses lain atau turunannya. Konfirmasikan hierarki dan kepemilikan pemetaan. Menyesuaikan glibc hanya karena RSS satu proses datar akan menargetkan lapisan yang salah.

Mengapa tidak memaksa glibc untuk menggunakan satu arena saja?

Satu arena dapat mengurangi dispersi tetapi membuat lebih banyak pekerjaan alokasi berjalan secara serial. Dengan 64 thread, hal itu dapat menukar memori residen dengan pertikaian lock (lock contention) dan regresi p99. Uji beberapa jumlah arena terbatas di bawah trace alokasi riil, catat contention dan latensi alokator, lalu pilih jumlah terkecil yang memenuhi kedua target anggaran.

Kapan arena batch atau alokator wilayah (region allocator) lebih baik digunakan?

Pendekatan ini menarik ketika sebagian besar objek berbagi satu masa hidup yang jelas: alokasikan objek dari satu region selama proses batch dan lepaskan region tersebut secara bersamaan setelahnya. Hal ini tidak aman jika referensi lolos ke dalam state layanan berumur panjang, destruktor atau pembersihan per objek diperlukan, atau satu batch berisi banyak masa hidup yang tidak terkait. Tegakkan batasan kepemilikan sebelum mengandalkan pelepasan massal.

Bagaimana Anda mengevaluasi alokator pengganti?

Gunakan build yang sama kecuali penautan alokatornya, trace input yang sama, jumlah thread, penempatan CPU, warm-up, dan jendela 30 siklus. Bandingkan RSS puncak dan pasca-idle, selisih alokasi aktif terhadap residen, throughput alokasi, CPU, page fault, p50/p99, dan perilaku kegagalan mendekati batas 8 GiB. Uji canary pada kandidat terbaik di balik mekanisme rollback deployment; rata-rata RSS yang lebih rendah saja tidak cukup.