Temu Duga Linux: Mengapakah RSS Kekal Tinggi Selepas Memori Dibebaskan?

Prompt dan Senario Berkenaan

Perkhidmatan Linux 64 bebenang yang menggunakan glibc malloc bermula pada 800 MiB RSS. Suatu kelompok berkala memacu RSS sehingga 6 GiB. Dua puluh minit selepas kelompok selesai, pemprofil timbunan (heap profiler) aplikasi melaporkan 1.1 GiB peruntukan langsung, tetapi RSS kekal pada 5.2 GiB. Proses tersebut berjalan di bawah had cgroup 8 GiB dan mempunyai SLO latensi p99 120 ms. Terangkan mengapa free() tidak menjamin penurunan RSS, buktikan sama ada jurang tersebut merupakan kebocoran, pengekalan penguntuk, pemecahan, atau pemetaan lain, dan pilih kaedah pemulihan yang selamat.

Bilangan bebenang, nilai memori, selang melahu, had, dan SLO ialah andaian latihan. Andaikan proses asli, glibc malloc, cgroup v2, tiada proses anak, dan kelompok yang boleh diulang. Masa jalan terurus (managed runtime) akan menambah lapisan timbunan, pemungut sampah, dan peruntukan aslinya yang tersendiri. Soalan ini tergolong dalam general kerana kemahiran utamanya ialah perakaunan proses Linux dan tingkah laku penguntuk, bukan sintaks bahasa aplikasi.

Bahan temu duga semasa secara eksplisit menganggap senarai bebas, kelas saiz, peruntukan setempat bebenang, dan pemecahan sebagai titik perbincangan temu duga sistem. Dokumentasi pengeluaran Redis menerangkan simptom boleh diperhati yang sama: memadam data logik mungkin membiarkan RSS berhampiran puncak terdahulunya kerana ketulan bebas kekal tersedia untuk penguntuk atau halaman masih mengandungi objek langsung. Dokumentasi Linux dan glibc kemudiannya menyediakan permukaan pengukuran dan kawalan yang diperlukan untuk jawapan berasaskan bukti. Sumber-sumber ini menetapkan perkaitan dan mekanik; ia tidak membuktikan bahawa syarikat tertentu menggunakan prompt tepat ini atau ia ditanya pada kekerapan tertentu.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada anda memisahkan pemilikan daripada pemastautan (ownership from residency). Selepas free(p), pemanggil tidak lagi memiliki peruntukan tersebut dan penguntuk boleh menggunakan semula blok itu. Kontrak peruntukan C tidak menjanjikan munmap, RSS yang lebih rendah, atau penambakan halaman fizikal serta-merta. Menyatakan sama ada "free sentiasa mengembalikan memori" atau "free tidak pernah mengembalikan memori" terlepas laluan khusus penguntuk.

Isyarat kedua ialah sama ada anda memisahkan empat lapisan pengukuran:

• peruntukan langsung aplikasi;
• bait penguntuk yang sedang digunakan, bebas, dipetakan, dan boleh dilepaskan;
• pemetaan proses dan halaman pemastautin;
• caj dan tekanan seluruh cgroup.

RSS bukan pembilang timbunan langsung. Linux mentakrifkan VmRSS sebagai RssAnon + RssFile + RssShmem. Pemetaan fail, memori dikongsi, tindanan (stacks), metadata penguntuk, dan pustaka asli semuanya boleh meluaskan jurang tersebut. Profil timbunan dan satu bacaan top oleh itu tidak dapat membuktikan atau menyangkal kebocoran.

Isyarat ketiga ialah diskriminasi diagnostik. Kebocoran membiarkan peruntukan boleh dicapai atau kekal langsung. Pengekalan bermaksud memori bebas kekal dipetakan untuk guna semula yang cekap. Pemecahan bermaksud penguntuk mempunyai bait bebas tetapi tidak dapat membentuk kawasan saiz halaman yang boleh dilepaskan, selalunya kerana beberapa objek langsung memancang (pin) halaman atau ruang bebas terbahagi antara arena dan kelas saiz. Keadaan-keadaan ini boleh wujud bersama, jadi calon memerlukan pemerhatian terkawal dan bukannya label yang disimpulkan daripada satu nisbah.

Akhir sekali, penemu duga mahukan keputusan peringkat pengeluaran. Menurunkan kiraan arena, memangkas secara agresif, atau menggantikan penguntuk boleh mengurangkan memori pemastautin sambil menambah kunci (locks), ralat halaman (page faults), panggilan sistem, atau bebanan CPU. Jawapan yang kukuh melindungi kedua-dua had 8 GiB dan SLO p99 120 ms dengan kenari (canary), main semula beban kerja, ambang penerimaan, dan undur balik (rollback).

Soalan untuk Dijelaskan Sebelum Menjawab

• Penguntuk dan versi manakah yang aktif? glibc tunables dan malloc_trim tidak menerangkan jemalloc, tcmalloc, mimalloc, penguntuk masa jalan bahasa, atau penggantian yang dipautkan secara statik. Sahkan penguntuk yang dimuatkan dan imej penggunaan sebelum menggunakan pembilangnya.
• Apakah sebenarnya yang melaporkan 1.1 GiB? Profil timbunan persampelan, pembilang penguntuk tepat, timbunan masa jalan terurus, dan metrik cache perniagaan meliputi bait yang berbeza. Sahkan sama ada pustaka asli, tindanan, pemetaan langsung, dan metadata penguntuk disertakan.
• Komponen RSS manakah yang kekal tinggi? RssAnon merujuk kepada timbunan, tindanan, dan pemetaan tanpa nama; RssFile kepada pemetaan bersandarkan fail; RssShmem kepada memori dikongsi. Jika peningkatan bukan tanpa nama, penalaan penguntuk ialah langkah pertama yang salah.
• Adakah dataran tinggi (plateau) tersebut berulang atau meningkat selepas setiap kelompok yang serupa? Dataran tinggi paras air tinggi yang stabil yang memenuhi kelompok seterusnya tanpa kenaikan 5 GiB lagi mencadangkan penggunaan semula. Bentuk tangga (staircase) dalam peruntukan langsung atau RSS memerlukan penjelasan kebocoran, beban kerja, atau pemetaan.
• Adakah bilangan bebenang, saiz peruntukan, atau jangka hayat objek berubah? Banyak bebenang dan pembebasan merentas bebenang boleh menyebarkan blok merentasi arena atau cache. Objek bercampur yang berhayat pendek dan berhayat panjang boleh meninggalkan satu mangsa terselamat pada banyak halaman yang sebaliknya bebas.
• Adakah cgroup benar-benar berada di bawah tekanan? Bandingkan memory.current, memory.events, PSI, swap, dan proses jiran. RSS yang tinggi dengan ruang lega yang mencukupi mungkin isu kecekapan; peristiwa memory.high yang berulang atau kehampiran dengan 8 GiB menjadikan tingkah laku pelepasan mendesak dari segi operasi.
• Bilakah kelompok seterusnya akan berjalan? Mengekalkan 4 GiB boleh diguna semula selama lima minit mungkin rasional. Mengekalkannya selama dua belas jam melahu di bawah had yang ketat mungkin mewajarkan pembersihan pascakelompok atau corak peruntukan yang berbeza.
• Apakah bajet regresi yang boleh diterima? Kaedah pemulihan berubah jika perkhidmatan boleh menggunakan 2% lebih banyak CPU tetapi tidak boleh menambah 5 ms kepada p99, atau jika kos memori lebih penting daripada latensi peruntukan sejuk.

Rangka Kerja Jawapan 30 Saat

"free() mengembalikan blok kepada penguntuk; ia tidak berjanji untuk menyahpetakan halamannya, jadi RSS boleh kekal tinggi tanpa kebocoran. Saya akan menyelaraskan satu garis masa kelompok dan membandingkan profil peruntukan langsung, bait penguntuk yang digunakan dan bebas, RssAnon, smaps setiap pemetaan, dan penggunaan cgroup. Kemudian saya akan mengulangi kelompok tersebut sebanyak tiga kali. Bait langsung yang berkembang menunjukkan kebocoran; bait langsung yang stabil ditambah RSS mendatar yang diguna semula oleh kelompok seterusnya menunjukkan pengekalan; bait bebas penguntuk yang melimpah dengan sedikit memori yang boleh dilepaskan serta halaman yang dipancang oleh objek yang terselamat menunjukkan pemecahan. Saya akan menggunakan malloc_trim(0) hanya sebagai eksperimen kenari glibc, bukan pembaikan menyeluruh. Kaedah pemulihan akhir boleh berupa pembetulan pemilikan, pengasingan jangka hayat, pemangkasan pascakelompok yang terikat, penalaan arena yang diuji, atau pertukaran penguntuk, yang diterima hanya jika main semula berbentuk pengeluaran kekal di bawah sasaran memori tanpa melanggar p99 120 ms."

Pecahan Terperinci Langkah Demi Langkah

Langkah 1: Bina Satu Garis Masa Memori

Rekodkan versi penggunaan, PID, laluan cgroup, bilangan bebenang, volum permintaan dan kelompok, taburan kadar peruntukan, bait langsung, komponen RSS, memory.current, memory.peak, tekanan, dan peristiwa OOM. Lakukan persampelan sebelum kelompok, pada puncak 6 GiB, serta-merta selepas penyahperuntukan, dan sepanjang tetingkap melahu 20 minit. PID, cgroup, atau beban kerja yang berbeza membatalkan perbandingan tersebut.

Soalan pertama adalah dari segi operasi: adakah RSS sekadar tinggi, atau adakah perkhidmatan menghampiri had dan melakukan penambakan di bawah tekanan? Pada 5.2 GiB di dalam had 8 GiB, ruang lega ketara ialah 2.8 GiB sebelum caj cgroup lain. Penolakan itu hanyalah pemeriksaan skala kerana cgroup juga mengakaunkan memori di luar RSS tanpa nama proses ini. Gunakan memory.current dan memory.stat untuk domain sebenar.

Langkah 2: Terangkan Sempadan Penguntuk-ke-Kernel

Penguntuk meminta kawasan yang lebih besar daripada sistem pengendalian dan membahagikannya kepada ketulan. glibc boleh memperluas arena biasa dan boleh membuat pemetaan tanpa nama yang berasingan untuk peruntukan yang cukup besar. Apabila aplikasi membebaskan ketulan, penguntuk terlebih dahulu menjadikan ketulan itu boleh diguna semula. Ia boleh menggabungkan (coalesce) ketulan bebas yang bersebelahan, meletakkannya dalam bin atau cache, mengekalkannya untuk mengelakkan panggilan sistem masa hadapan, atau melepaskan halaman yang sesuai.

Ketulan besar yang dipetakan secara bebas selalunya boleh dinyahpetakan semasa pembebasan. Memori timbunan biasa adalah lebih sukar. Blok bebas di tengah-tengah rantau tidak boleh mengecilkan hujung timbunan, dan halaman yang mengandungi walaupun satu objek penuding mentah langsung tidak boleh dinyahpetakan tanpa memindahkan objek tersebut. Penguntuk C dan C++ secara amnya tidak dapat memadatkan objek langsung sewenang-wenangnya kerana penuding aplikasi akan menjadi tidak sah.

Ini menghasilkan tiga jenis overhed yang berbeza:

• Pemecahan dalaman (Internal fragmentation): permintaan 20 bait mungkin menggunakan blok penjajaran atau kelas saiz yang lebih besar.
• Pemecahan luaran atau peringkat halaman (External or page-level fragmentation): ruang bebas wujud, tetapi ia terbahagi atau dipancang sehingga seluruh halaman tidak dapat dilepaskan.
• Pengekalan disengajakan (Intentional retention): seluruh atau sebahagian halaman kekal dipetakan kerana penguntuk menjangkakan guna semula dan pelepasan/pemerolehan semula mempunyai kos.

Label-label tersebut menerangkan mekanik, bukan kesimpulan daripada satu nisbah RSS / live_bytes.

Langkah 3: Selaraskan Empat Lapisan Pengukuran

Mulakan dengan perakaunan proses Linux:

VmRSS = RssAnon + RssFile + RssShmem

Baca /proc/PID/status untuk pecahan umum dan /proc/PID/smaps_rollup untuk maklumat agregat RSS, PSS, tanpa nama, fail, dikongsi, dan lazy-free. Gunakan /proc/PID/smaps hanya apabila anda perlu mengenal pasti pemetaan tanpa nama atau bersandarkan fail tertentu yang berkembang. Satu jumlah pmap atau RSS sekali sahaja adalah kurang bermaklumat berbanding delta yang disegerakkan.

Kemudian tambahkan statistik penguntuk. Dalam glibc, mallinfo2 boleh mendedahkan bait yang diperoleh melalui sbrk, bait dalam ketulan yang dipetakan, bait yang diserahkan kepada pemanggil, bait bebas, dan ketulan atas yang boleh dilepaskan. Medan ini tidak meliputi setiap sumber peruntukan dan mesti disampel secara konsisten, tetapi ia membantu menjawab sama ada penguntuk memiliki sebahagian besar jurang tanpa nama. Utamakan pemprofilan asli penguntuk aplikasi apabila ia menyediakan data yang dipetakan, aktif, pemastautin, dikekalkan, dan setiap kelas saiz yang lebih lengkap.

Akhir sekali, selaraskan dengan cgroup v2. cgroup merangkumi semua memori yang dicaj dalam hierarkinya, jadi ia mungkin melebihi RSS satu proses atau berubah atas sebab yang berbeza. Bandingkan memory.current dan memory.stat dengan bukti proses dan bukannya memaksa kedua-duanya menjadi sama.

Langkah 4: Gunakan Eksperimen Guna Semula Tiga Kitaran

Jalankan kelompok yang sama sebanyak tiga kali pada kenari berbentuk pengeluaran dengan konkurensi 64 bebenang dan taburan saiz input yang sama. Selepas setiap kelompok, tunggu selama 20 minit yang sama dan tangkap pembilang yang sama.

Tafsirkan bentuk tersebut:

Dataran tinggi tidak semestinya tidak berbahaya secara automatik. Jika kelompok seterusnya memuncak melebihi 8 GiB kerana halaman lama yang dikekalkan tidak dapat memenuhi taburan saiz baharunya, perkhidmatan masih boleh gagal walaupun data logik stabil. Sebaliknya, dataran tinggi yang tinggi yang memenuhi beban kerja yang sama secara cekap mungkin lebih diutamakan daripada pelepasan paksa dan ralat berulang.

Langkah 5: Gunakan Pemangkasan sebagai Diagnostik Terikat

Pada kenari glibc, panggil malloc_trim(0) sekali pada sempadan pascakelompok dan rekod nilai pulangan, komponen RSS, bait langsung penguntuk, ralat halaman, CPU, dan latensi permintaan berikutnya. Antara muka GNU cuba melepaskan memori timbunan bebas dan mungkin menggunakan sbrk atau madvise; ia tidak menjanjikan pengurangan RSS yang tertentu.

Jika RssAnon turun dengan ketara manakala peruntukan langsung kekal pada 1.1 GiB, beberapa halaman milik penguntuk boleh dilepaskan. Itu mempersempit diagnosis, tetapi ia tidak membuktikan bahawa memanggil pemangkasan dalam pengeluaran ialah dasar yang terbaik. Jika RSS hampir tidak berubah, seluruh halaman bebas mungkin tidak tersedia, pertumbuhan mungkin berada di luar glibc, atau metrik mungkin merangkumi pemetaan yang berbeza. Kegagalan untuk memangkas tidak membuktikan kebocoran.

Jangan sekali-kali meletakkan pemangkasan pada setiap permintaan. Melepaskan halaman boleh menukar memori pemastautin dengan panggilan sistem, ralat kecil (minor faults), pengisian sifar, kehilangan cache, dan latensi ekor apabila kelompok seterusnya tiba. Sempadan fasa semula jadi dengan tetingkap melahu yang panjang ialah calon yang lebih wajar dipertahankan, dan ia masih memerlukan kenari.

Langkah 6: Padankan Kaedah Pemulihan dengan Punca yang Terbukti

• Kebocoran: betulkan rujukan pemilikan, had cache, pembebasan yang hilang, atau kitaran hayat pustaka. Memangkas tidak menjadikan memori langsung boleh dilepaskan.
• Pengekalan disengajakan dengan guna semula jangka masa terdekat: kekalkannya, sediakan peruntukan untuk puncak yang diukur, dan beri amaran pada kenaikan bertangga yang berulang dan bukannya memaksa RSS sepadan dengan bait langsung.
• Pemecahan didorong jangka hayat: asingkan objek kelompok berhayat pendek daripada keadaan perkhidmatan berhayat panjang, gunakan arena atau rantau kelompok yang boleh dilepaskan sebagai satu unit, dan elakkan menyisipkan satu objek berhayat panjang merentasi banyak halaman sementara.
• Penyebaran arena atau cache bebenang: uji arena yang lebih sedikit, turunkan konkurensi pada titik panas peruntukan, atau corak pemilikan yang berbeza. Arena yang lebih sedikit mungkin menjimatkan memori tetapi meningkatkan perbalahan (contention).
• Fasa melahu panjang di bawah had yang ketat: uji satu pemangkasan pascakelompok eksplisit atau pembersihan khusus penguntuk dengan had kadar dan bendera undur balik.
• Ketidakpadanan penguntuk: bandingkan glibc dengan alternatif yang sesuai di bawah surihan yang tepat. Reka bentuk mimalloc Microsoft Research menggambarkan pertukaran teras: halaman setempat bebenang meningkatkan kebolehskalaan dan kelokalan, manakala pemilikan terpencil boleh mengekalkan memori yang tidak dapat diguna semula oleh bebenang lain dengan serta-merta.

arena_max, trim_threshold, dan mmap_threshold milik glibc ialah eksperimen, bukan pemalar ajaib. Menetapkannya menjadikan tingkah laku lebih statik dan boleh mengubah perbalahan, bilangan pemetaan, kekerapan pelepasan, dan kos syscall. Ubah satu faktor pada satu masa dan kekalkan imej asal sebagai pelan undur balik.

Langkah 7: Sahkan Memori dan Latensi Bersama-sama

Mainkan semula 30 kitaran yang serupa pada perkakasan berbentuk pengeluaran. Nombor 30 ialah tetingkap ujian latihan, bukan keperluan sejagat. Jejak peruntukan langsung, bait penguntuk yang dipetakan/bebas/boleh dilepaskan, RssAnon, jumlah RSS, memory.current, tekanan, ralat halaman, latensi peruntukan, CPU, daya pemprosesan, dan latensi permintaan p50/p99.

Contoh kriteria penerimaan untuk senario ini adalah: RssAnon pascamelahu pada atau di bawah 2.2 GiB dalam masa 20 minit, tiada kenaikan bertangga ke atas merentasi 30 kitaran, tiada OOM atau tekanan berterusan, p99 pada atau di bawah 120 ms, dan regresi CPU tidak melebihi 3%. Ambang ini ialah andaian latihan untuk digantikan dengan bajet sebenar perkhidmatan. Kaedah pemulihan yang mencapai 2.2 GiB tetapi menolak p99 kepada 145 ms dianggap gagal; kaedah pemulihan yang mengekalkan latensi tetapi masih menghampiri had 8 GiB di bawah campuran saiz sah seterusnya juga gagal.

Contoh Jawapan Berkualiti Tinggi

"Saya tidak akan menganggap ini sebagai kebocoran daripada RSS semata-mata. free() menamatkan pemilikan aplikasi terhadap sesuatu blok, tetapi glibc mungkin mengekalkan blok tersebut dalam arena untuk guna semula, dan beberapa objek langsung boleh mengekalkan halaman yang sebaliknya bebas sebagai pemastautin. Mula-mula saya akan mengesahkan bahawa nombor 1.1 GiB merangkumi peruntukan langsung asli, kemudian menyelaraskannya dengan pemetaan RssAnon, RssFile, RssShmem, smaps, statistik penguntuk, dan caj cgroup melalui satu kelompok yang lengkap.

Saya akan memainkan semula kelompok yang sama sebanyak tiga kali. Jika peruntukan langsung meningkat selepas setiap tempoh melahu 20 minit, saya akan membandingkan profil perbezaan objek langsung dan membetulkan laluan pemilikan. Jika bait langsung kekal pada 1.1 GiB, RSS kekal berhampiran 5.2 GiB, dan kelompok seterusnya menggunakan semula ruang tersebut tanpa kenaikan lain, pengekalan ialah penjelasan yang lebih kukuh. Jika bait bebas penguntuk adalah tinggi tetapi halaman yang boleh dilepaskan kekal rendah dan dataran tinggi berubah mengikut jangka hayat objek atau konkurensi 64 bebenang, saya akan menyiasat pemecahan dan penyebaran arena.

Sebagai diagnostik khusus glibc, saya akan memanggil malloc_trim(0) sekali pada kenari selepas kelompok tersebut. RssAnon yang lebih rendah dengan bait langsung yang tidak berubah menunjukkan bahawa beberapa halaman penguntuk boleh dilepaskan; ia tidak mewajarkan pemangkasan pada setiap permintaan. Saya kemudiannya akan memilih perubahan khusus punca yang paling kecil: membaiki kebocoran, mengasingkan jangka hayat kelompok ke dalam rantau yang boleh dilepaskan, atau menguji kenari pemangkasan pascakelompok yang terikat atau tetapan arena. Saya akan memainkan semula 30 kitaran dan menerima perubahan itu hanya jika memori pascamelahu memenuhi sasaran yang dipersetujui, RSS tidak menunjukkan kenaikan bertangga, cgroup kekal selamat, dan p99 kekal dalam lingkungan 120 ms."

Kesilapan Biasa

• Memanggil jurang 4.1 GiB sebagai kebocoran → RSS merangkumi halaman bebas penguntuk dan pemetaan bukan timbunan → buktikan pertumbuhan dalam peruntukan langsung atau pemilikan yang dikekalkan dengan profil yang disegerakkan.
• Mendakwa free() sentiasa menurunkan RSS → ketulan yang dibebaskan mungkin kekal dalam arena atau berkongsi halaman dengan ketulan langsung → terangkan guna semula, pelepasan seluruh halaman, dan peruntukan yang dipetakan secara bebas.
• Mendakwa free() tidak pernah mengembalikan memori → penguntuk boleh menyahpetakan pemetaan besar, memangkas ketulan atas, atau memberi nasihat untuk melepaskan seluruh halaman bebas → nyatakan bahawa pelepasan bergantung pada penguntuk, susun atur, dan dasar.
• Menggunakan satu nisbah pemecahan sebagai bukti → puncak baru-baru ini, pemetaan fail, cache, atau pengekalan disengajakan boleh melambungkannya → bandingkan bait langsung, bebas, dipetakan, pemastautin, dan boleh dilepaskan melalui kitaran berulang.
• Memanggil malloc_trim(0) pada setiap permintaan → pelepasan paksa boleh menambah syscall, ralat, dan latensi ekor → uji ia sekali pada sempadan melahu semula jadi dan ukur lonjakan peruntukan seterusnya.
• Menetapkan arena_max kepada satu kerana terdapat 64 bebenang → memori mungkin turun sementara perbalahan kunci meningkat → sapu nilai calon di bawah konkurensi yang sama dan lindungi p99.
• Menukar penguntuk berdasarkan tajuk penanda aras → saiz peruntukan, jangka hayat, dan corak pembebasan merentas bebenang menentukan hasil → lakukan ujian A/B pada surihan yang tepat dengan pelan undur balik serta kriteria memori dan latensi.
• Mengabaikan perakaunan cgroup → RSS satu proses bukanlah keseluruhan domain memori → selaraskan memory.current, memory.stat, keturunan, dan tekanan dengan metrik proses.

Soalan Susulan dan Maklum Balas

Jika malloc_trim(0) menurunkan RSS daripada 5.2 GiB kepada 1.8 GiB, apakah yang telah anda buktikan?

Anda telah menunjukkan bahawa glibc memiliki sejumlah besar memori yang boleh dilepaskan pada peringkat halaman pada saat itu dan RSS yang tinggi bukan semuanya data aplikasi langsung. Anda belum membuktikan ketiadaan kebocoran yang lebih kecil, punca pengekalan, atau keselamatan pemangkasan yang kerap. Jalankan semula beban kerja dan ukur ralat halaman, CPU, latensi peruntukan, dan p99 sebelum memilih dasar.

Jika trim mengembalikan sifar dan RSS tidak bergerak, adakah ia satu kebocoran?

Tidak. Ruang bebas mungkin diagihkan merentasi halaman yang masih mengandungi ketulan langsung, memori mungkin dipegang dalam penguntuk atau pemetaan lain, atau tiada halaman glibc yang boleh dilepaskan wujud. Bandingkan profil langsung, bait bebas dan boleh dilepaskan penguntuk, serta pemilikan smaps. Kebocoran memerlukan bukti peruntukan langsung atau yang dikekalkan berkembang, bukan sekadar pemangkasan yang tidak berjaya.

Bagaimana jika RSS kekal mendatar tetapi memory.current terus berkembang?

Siasat delta cgroup dan bukannya timbunan. memory.stat boleh mendedahkan cache fail, shmem, soket, atau memori kernel, dan cgroup mungkin merangkumi proses atau keturunan lain. Sahkan hierarki dan pemilikan pemetaan. Menala glibc kerana RSS satu proses mendatar akan menyasarkan lapisan yang salah.

Mengapa tidak memaksa glibc menggunakan satu arena?

Satu arena boleh mengurangkan penyebaran tetapi mensirikan lebih banyak kerja peruntukan. Dengan 64 bebenang, tindakan itu mungkin menukar memori pemastautin dengan perbalahan kunci dan regresi p99. Uji beberapa kiraan arena yang terikat di bawah surihan peruntukan sebenar, tangkap perbalahan dan latensi penguntuk, serta pilih kiraan terkecil yang memenuhi kedua-dua bajet.

Bilakah arena kelompok atau penguntuk rantau lebih baik?

Ia menarik apabila kebanyakan objek berkongsi satu jangka hayat yang jelas: peruntukkannya daripada suatu rantau semasa kelompok dan lepaskan rantau tersebut bersama-sama selepas itu. Ia tidak selamat apabila rujukan terlepas ke dalam keadaan perkhidmatan yang berhayat panjang, pemusnah (destructors) atau pembersihan bagi setiap objek diperlukan, atau satu kelompok mengandungi banyak jangka hayat yang tidak berkaitan. Kuat kuasakan sempadan pemilikan sebelum bergantung pada pelepasan pukal.

Bagaimanakah anda akan menilai penguntuk pengganti?

Gunakan binaan yang sama kecuali pautan penguntuk, surihan input yang sama, bilangan bebenang, penempatan CPU, pemanasan (warm-up), dan tetingkap 30 kitaran. Bandingkan RSS puncak dan pascamelahu, jurang langsung-ke-pemastautin, daya pemprosesan peruntukan, CPU, ralat halaman, p50/p99, dan tingkah laku kegagalan berhampiran had 8 GiB. Lakukan ujian kenari terhadap pemenang di sebalik pelan undur balik penggunaan; purata RSS yang lebih rendah sahaja tidak mencukupi.