Meta, jemalloc için yeni yatırım ve açık kaynak iş birliğini güçlendiriyor

• Yüksek performanslı bellek ayırıcısı jemalloc, Meta yazılım yığınında Linux çekirdeği ve derleyicilerle birlikte çekirdek altyapı rolü üstlenen temel bir bileşen oldu
• Son yıllarda jemalloc geliştirmesine yön veren temel mühendislik ilkelerinden kademeli olarak uzaklaşılmasıyla teknik borç birikti ve ilerleme yavaşladı
• Topluluk geri bildirimleri dikkate alındı ve proje kurucusu Jason Evans dahil topluluk üyeleriyle yapılan görüşmelerin ardından, orijinal açık kaynak deposu yeniden etkinleştirildi (unarchived)
• Bundan sonra teknik borcun temizlenmesi, Huge-Page allocator iyileştirmeleri, bellek verimliliğinin artırılması ve AArch64 optimizasyonlarına odaklanılması planlanıyor
• Meta, jemalloc için uzun vadeli stewardship taahhüdünü yeniden teyit ederken, toplulukla iş birliği içinde projeyi geliştirme yönüne geçiyor

---

jemalloc'un konumu ve önemi

• jemalloc, yüksek performanslı bir bellek ayırıcısı olarak Meta yazılım yığınında sürekli yüksek etki sağlayan bir bileşen oldu
• Donanım değişimlerine ve üst katman yazılımlarındaki değişikliklere göre sürekli uyum sağladı; Linux çekirdeği ve derleyicilerle birlikte Meta altyapısının kararlılığına ve performansına katkıda bulundu

İlkelerden sapma ve değerlendirme

• Temel yazılım bileşenleri, pratiklik ile ilkeler arasında en yüksek düzeyde disiplin gerektirir
• jemalloc'un sağladığı yüksek etki nedeniyle kısa vadeli kazanımları gerçekleştirme yönünde bir cazibe vardır; buna direnmek için kurumsal ölçekte güçlü öz disiplin gerekir
• Son birkaç yılda jemalloc geliştirmesine yön veren temel mühendislik ilkelerinden kademeli bir sapma yaşandı
• Bazı kararlar anlık fayda sağladı, ancak bunun sonucunda oluşan teknik borç ilerlemeyi engelledi
• Topluluk geri bildirimleri ciddiyetle ele alındı ve proje kurucusu Jason Evans dahil topluluk üyeleriyle görüşmeler yapıldı
• Stewardship'in jemalloc'un uzun vadeli sağlığı üzerindeki etkisi derinlemesine değerlendirildi ve yaklaşım değişikliği paylaşıldı
• Teknik borcu gidermek ve jemalloc için uzun vadeli yol haritasını yeniden kurmak üzere çalışmalara başlandı

Yeni dönem: depo arşivden çıkarılıyor ve gelecek planları

• Toplulukla yapılan görüşmeler sonucunda, orijinal jemalloc açık kaynak deposu yeniden etkinleştirildi (unarchived)
• Bu sayede Meta, projede steward rolünü sürdürürken bakım yükünü azaltmaya ve kod tabanını modernize etmeye odaklanabilecek
  • Teknik borcun temizlenmesi: Refactoring ve iyileştirmelerle tüm kullanıcılar için verimli, güvenilir ve kullanımı kolay bir durumun korunması
  • Huge-Page allocator (HPA): Transparent Hugepages (THP) kullanımını daha iyi değerlendirerek CPU verimliliğini artırma
  • Bellek verimliliği: Packing, caching ve purging mekanizmalarını iyileştirerek bellek verimliliğini optimize etme
  • AArch64 optimizasyonu: ARM64 platformunda varsayılan durumda iyi performans sağlama

Toplulukla iş birliğini güçlendirme

• Meta, eylemle güven inşa etmeyi vurguluyor ve jemalloc'un sağlıklı gelişimini hedefliyor
• Topluluğun geri bildirimini ve katılımını memnuniyetle karşılıyor ve jemalloc'un geleceğini birlikte şekillendirmeyi umuyor
• Açık kaynak ekosistemi içinde sürdürülebilir iş birliği ve gelişimi ilerletecek

[GN⁺]

Hacker News görüşleri

• Facebook’ta çalıştığım dönemde, jemalloc’un purging mekanizmasını iyileştirmek için çekirdek yamaları sürdürdüm
  Çekirdek ya da güvenlik topluluğunda pek sevilmiyordu ama benchmark’larda verimliydi
  Sorun, belleği başka bir iş parçacığına yeniden tahsis ederken zeroing yapılması ve bunun önbellek yerelliği ile performansı etkilemesiydi
  Aynı güvenlik alanı içinde belleği yeniden kullanırken bu gereksiz bir davranıştı, ancak “güvenlik alanı”nın nereye kadar uzandığı konusunda uzlaşmak zordu
  İlgili tartışma Linux Kernel posta listesinde yer alıyor

  • O yamadan hâlâ bahsediliyor olması şaşırtıcı
    HHVM’de söz konusu yamayı uygulamadan önce ve sonra kapsamlı benchmark’lar yaptık, ancak sistem düzeyinde istatistiksel olarak anlamlı bir fark yoktu
    Bazı mikro benchmark’larda iyileşme olmuş olabilir ama genel sistem performansına etkisi olmadığı için çekirdeğe alınmadı
  • Hangi metriğin (metric) iyileştiğini merak ediyorum
  • cgroup içinde süreçler arasında bellek içeriğinin sızmasının sorun olmayacağını düşünmek tehlikeli geliyor

• Kısa süre önce Microsoft’un mimalloc’unu LD_PRELOAD ile kullanıp 1GB huge page’lerden yararlandım
  Bellek yoğun bir programda yaklaşık %20 performans artışı elde ettim
  Linux’ta açık kaynak bir MS kütüphanesi kullanarak performansı artırmak tuhaf hissettiriyor
  malloc alanında daha fazla rekabet gerektiğini düşünüyorum

  • Çeşitli allocator’ları test ettim; en güncel tcmalloc, hem süre hem bellek kullanımında en iyi sonucu verdi
    Uygulamalar Rust ile yazılmıştı ve çoğu statik olarak linklenmişti
    Örneğin app1’de, glibc’ye kıyasla tcmalloc RSS’i %35 azalttı ve işlem süresini %30 kısalttı
    Tüm sonuçlar tcmalloc deposu temel alınarak test edildi
  • Eskiden Dr. Dobbs ya da BYTE gibi dergilerde özel bellek ayırıcı reklamları çok olurdu
    Hatta Turbo Pascal bile bellek ayırıcısını doğrudan tanımlayabilmek için API sunuyordu
    Sonuçta “one size fits all” yaklaşımının sınırları çok eskiden beri belliydi
  • GC dillerinin avantajlarından biri, tahsis/serbest bırakma maliyetlerinin birlikte paketlenmesi ve bu sayede profiling sırasında daha net görünmesidir
  • Eski Apache Portable Runtime’daki bellek havuzu kavramı etkileyiciydi
    Her istek için bir havuz oluşturuluyor, istek bitince de tamamı tek seferde serbest bırakılıyordu
    malloc’un da bu yönde evrilmesi için çok alan olduğunu düşünüyorum
  • Bazı durumlarda malloc yerine doğrudan mmap ile huge page eşlemek daha verimlidir
    Tahsis deseni basitse, üçüncü taraf malloc’tan bile daha iyi sonuç alınabilir
    malloc’a sihirli bir kara kutu gibi bakılıyor ama gerçekte o kadar da üstün değil

• Ekibimiz 2 yıl önce glibc malloc’tan jemalloc’a geçti
  Python servislerinde bellek kullanımı %15~20 azaldı
  Ancak konteyner ortamında oversize_threshold ayarı önemliydi — yanlış yapılandırılırsa OOM oluşabiliyor
  Uzun süre çalışan servislerde jemalloc ile mimalloc’u karşılaştıran benchmark olup olmadığını merak ediyorum

• İlgili ek okuma olarak Jemalloc Postmortem ile
  Jemalloc Repositories Are Archived öneriliyor

• Acaba bu değişikliğin nedeni küresel bellek kıtlığı olabilir mi diye merak ediyorum
  “Bellek ayırıcısını değiştirerek yılda milyonlarca dolar tasarruf” gibi hesaplar çıkabilir

  • Facebook 10 yıl önce de bu tür mikro optimizasyonlarla maliyet düşürmeye odaklanıyordu
    Yalnızca %0,1 verimlilik artışı bile ayda 100 bin dolar tasarruf sağlayabiliyordu
    Başlıca tasarruf kalemleri soğutma maliyetleri (HVAC) ve daha az sunucu satın alma ihtiyacıydı
    Bugün bellek tasarrufu da büyük bir konu ama o dönemde öyle değildi
  • Mesele sadece maliyet değil; bellek tedarikindeki gecikmeleri telafi etmek için verimlilik artışı da önemli
  • Meta’da milyonlarca dolarlık tasarruf fırsatları aramak sıradan bir durum
    Binlerce sunucuyu etkileyen küçük bir iyileştirme bile büyük rakamlara dönüşüyor
    Böyle bir nicel iyileştirme kültürü yerleşmiş durumda
  • Şirketin itibarı düşünüldüğünde, bunun yalnızca bellek kıtlığından ibaret olmayan daha karmaşık nedenleri de olabilir
  • LLM’ler, enerji ve sunucu belleği verimliliğinin giderek daha önemli hâle geldiği bir dönemdeyiz
    Sadece %10 daha hızlı olmak bile LLM rekabetinde avantaj sağlayabilir
    Performans iyileştirmesi için teşvik çok büyük

• Avustralya’da düşük seviyeli programlama yaparken işten çıkarıldım
  Bu tür sorunları çözmeyi gerçekten seviyorum ama yerel pazarın çoğu React CRUD işleri etrafında dönüyor, bu da üzücü

  • AU’da düşük seviyeli veri işleme alanında işe alım yapıyoruz. Bağlantı profilde var
  • Ben de Avustralya’da sadece React CRUD yaparken aynı şeyi düşündüm
  • Uzaktan çalışma arıyorsanız Igalia iş ilanları sayfası ilginizi çekebilir
  • HFT şirketleri (IMC trading) de bu tür düşük seviyeli optimizasyon işleri yapıyor ve şu anda Avustralya’da işe alım yapıyor
  • SIG de Sidney’de ilgili pozisyonlar için alım yapıyor: SIG Careers

• World Bank fonuyla yürütülen bir startup projesinde Ruby + jemalloc’u production’a aldık
  Hız ve bellek verimliliği gözle görülür biçimde iyileşti, AWS maliyetleri ciddi şekilde düştü
  Bu 8 yıl önceydi; jemalloc’un neden hâlâ standart hâline gelmediğini merak ediyorum

  • Çoğu zaman sebep basitçe bilgi eksikliği ya da atalet
    Hâlihazırda çalışan bir sistemi değiştirmek, faydası açık olsa bile kolay değil

• jemalloc kullanarak bellek sızıntısının nedenini takip eden örnekler de var
  Ayrıntı için GOV.UK teknik blog yazısına bakılabilir

• Meta, kendi fork’unda üzerinde çalıştığı içeriği büyük ölçekte birleştirdi
  PR #2863 üzerinden görülebilir

• jemalloc’un zaman çizelgesi ya da tarihini derleyen bir kaynak olup olmadığını merak ediyorum
  Açık kaynak bir proje olmasına rağmen Meta’nın neden kontrolü elinde tuttuğu da soru işareti

  • Kurucusu Jason Evans, geçen yıl tüm süreci özetledi
    Bkz. Jemalloc Postmortem blogu
  • Son 5 yıldaki commit’lere bakıldığında ilk 6 kişinin 4’ü Meta çalışanı
    Kalan 2 kişinin de açıkça belirtilmemiş olsa bile Meta’dan olma ihtimali var