Rust servisinin 358 MB RSS'si Transparent Huge Pages ve jemalloc'a bağlandı; düzeltme değeri 87 MB'a indirdi

Yaklaşık 52 MB canlı veri tutan bir Rust servisi 358 MB resident memory tüketiyordu ve bunun nedeni bir bellek sızıntısı değildi. 26 Ağustos 2026'da yayımlanan bir dev.to yazısına göre, resident set size (RSS), Linux çekirdeğinin Transparent Huge Pages (THP) özelliğinin jemalloc allocator'ı ve iş yükünün tahsisat deseniyle etkileşimi sonucunda şişmişti. THP'yi always modundan madvise moduna geçirmek, servisin kodunda herhangi bir değişiklik yapmadan RSS'yi 358 MB'tan 87 MB'a düşürdü.

Belirti: canlı verinin yedi katı fazla resident memory

Sorunu ayrıca certstream.dev blogunda daha kapsamlı bir yazıya dönüştüren yazının yazarı, allocator istatistiklerinin yaklaşık 52 MB canlı tahsisat gösterdiğini, sürecin ise 358 MB RSS bildirdiğini aktarıyor — bu, fiilen kullanılan belleğin neredeyse yedi katı. İlk şüpheliler, native bir dilde yazılmış bir servis için alışılmış olanlardı: allocator içindeki parçalanma ya da serbest bırakıldıktan sonra çekirdeğe iade edilmeyip elde tutulan extent'ler. Ancak ikisi de bu kadar geniş bir farkı açıklayamıyordu.

Kanıtların izini sürmek

Soruşturma, jemalloc'un kendi istatistik çıktısı ve /proc altındaki, çekirdeğin bellek eşleme muhasebesini özetleyen süreç başına smaps_rollup özetinden geçti. Bu görünümler birlikte, parçalanmış ya da elde tutulan bir heap yerine, huge page'lerle desteklenen anonim belleğe işaret etti. THP yapılandırmasını kontrol etmek — /sys/kernel/mm/transparent_hugepage/enabled üzerinden görülebiliyor — sunucunun always modunda çalıştığını gösterdi ve bu da tanıyı tamamladı.

Huge page'ler ve jemalloc neden birlikte kötü sonuç doğuruyor

Arka plan için: Linux normalde bir sürecin anonim belleğini 4 KB'lık sayfalarla destekler. THP, çekirdeğin bunun yerine 2 MB'lık huge page'ler kullanmasını sağlar; bu da belleğe yoğun erişen iş yüklerinde TLB miss sayısını azaltır. always modunda çekirdeğin, uygulamanın isteyip istemediğine bakmaksızın uygun bölgeleri agresif biçimde yükseltir.

Maliyet, RSS'nin muhasebeleştirilme biçiminde yatar. Fiziksel bellek sayfa çözünürlüğünde ölçülür; dolayısıyla 2 MB'lık bir huge page içindeki tek bir byte'a dokunulduğunda, page'in tamamı resident hale gelir ve sürecin ayak izine dahil edilir. Canlı verisi birçok bölgeye dağınık küçük parçalar halinde yayılmış uzun ömürlü bir servis — jemalloc gibi arena tabanlı, size-class kullanan bir allocator'ın üretebileceği türden bir düzen — çekirdeğe yükseltilecek çok sayıda seyrek kullanımlı bölge sunar. Her yükseltme, belki yalnızca birkaç kilobyte canlı veri için 2 MB fiziksel belleği sabitler ve bu israf heap boyunca katlanarak büyür. dev.to yazısı, bu vakadaki şişmeyi tam olarak bu bileşime bağlıyor.

Düzeltme ve dengeleri

Yazıya göre THP'yi madvise moduna — yalnızca huge page'leri açıkça isteyen adres aralıklarının bunları aldığı orta mod — ayarlamak RSS'yi 358 MB'tan 87 MB'a indirdi. 52 MB'lık canlı heap üzerindeki kalan fark ise, kodun, stack'lerin, allocator üstverisinin ve çekirdeğe iade edilmeyi bekleyen sayfaların getireceği ek yük ile uyumlu.

İki uyarıya değinmekte fayda var. always modunun var olmasının nedeni, yoğun ve sıralı iş yüklerinin huge page'lerden gerçekten yarar görmesi; ayrıca bazı dağıtımlar bu modu varsayılan olarak sunuyor. Ayarı sistem geneli değiştirmek, aynı sunucudaki diğer servislerin performans profilini de etkileyebilir; bu yüzden etki varsayılmamalı, ölçülmelidir. Mümkün olduğu durumlarda süreç başına madvise ile tercih yapmak daha hedefli bir yoldur.

Neden önemli

RSS, container runtime'larının, orchestrator'ların ve izleme panellerinin fiilen dayandıkları sayıdır. Şişmiş bir ayak izi, aksi halde sağlıklı olan bir servisi bir cgroup bellek limitinin üzerine çıkarıp OOM kill'e sürükleyebilir ya da kapasite planlamasını ve sunucu maliyetlerini sessizce çarpıtabilir. Bu hikaye aynı zamanda bir hata ayıklama şablonu olarak da iş görüyor: allocator istatistikleri tek başına sürecin boyutunu açıklayamıyordu ve yanıt ancak çekirdek düzeyindeki bellek muhasebesi ile THP yapılandırması devreye girdiğinde ortaya çıktı. THP'nin neden olduğu müdahale, uzun süredir çalışan native servisler için belgelenmiş bir sorundur — büyük veritabanı projeleri yıllardır bunun konusunda uyarıyor — bu yüzden native bir sürecin resident belleği canlı heap'inden çok daha büyük göründüğünde kontrol listesinde yerini almalıdır.