AWS mühendisi, Linux 7.0'da PostgreSQL performansının yarıya düştüğünü bildirdi – düzeltmesi kolay olmayabilir

 (phoronix.com/news)
7 puan yazan GN⁺ 24 일 전 | 2 yorum | WhatsApp'ta paylaş
  • Amazon/AWS mühendisleri, Linux 7.0 geliştirme çekirdeğinde PostgreSQL veritabanı sunucusunun iş hacminin önceki çekirdeğe kıyasla yaklaşık yarıya düştüğü ciddi bir performans gerilemesi tespit etti
  • Graviton4 sunucularında yapılan ölçümlere göre Linux 7.0, önceki çekirdeğin yalnızca yaklaşık 0,51 katı iş hacmi sunuyor ve bunun nedeninin kullanıcı alanı spinlock üzerinde çok daha fazla zaman harcanması olduğu belirlendi
  • Gerilemenin nedeni, Linux 7.0'da yapılan çekirdek preemption modu kısıtlaması değişikliği; PREEMPT_NONE'ı varsayılan olarak geri getiren bir yama gönderildi ancak kabul edilip edilmeyeceği belirsiz
  • Orijinal yazar Peter Zijlstra, çekirdeği değiştirmek yerine PostgreSQL'in RSEQ (Restartable Sequences) zaman dilimi uzantısından yararlanacak şekilde güncellenmesi gerektiğini savunuyor
  • Linux 7.0 kararlı sürümünün yaklaşık 2 hafta içinde çıkması ve Ubuntu 26.04 LTS'nin temel çekirdeği olarak da kullanılacak olması nedeniyle, PostgreSQL uyum sağlayana kadar yaygın performans düşüşü endişesi bulunuyor

Sorunun keşfi ve boyutu

  • Amazon/AWS mühendisi Salvatore Dipietro, PostgreSQL'in iş hacmi ve gecikme gerilemesini bildirdi
  • Graviton4 sunucuları üzerinde yapılan ölçümlerde Linux 7.0, mevcut çekirdeğe kıyasla yalnızca 0,51 kat iş hacmi sağladı
    • Bunun nedeninin kullanıcı alanı spinlock üzerinde çok daha fazla zaman harcanması olduğu doğrulandı

Gerilemenin nedeni: preemption modu kısıtlaması

  • Bisecting sonucunda, sorunun Linux 7.0'da çekirdek preemption modunun kısıtlanmasına yol açan değişiklikten kaynaklandığı tespit edildi
  • Söz konusu değişiklik, modern CPU mimarileri için yalnızca Full ve Lazy preemption modlarını koruma yönünde yapıldı ve Linux 7.0 zamanlayıcı güncellemesinin bir parçası olarak dahil edildi

Gönderilen yama ve çekirdek bakımcılarının tepkisi

  • Ciddi gerileme gerekçesiyle PREEMPT_NONE'ı varsayılan preemption modu olarak geri getiren bir yama Linux çekirdek posta listesine gönderildi
  • Ancak orijinal kodun yazarı Peter Zijlstra bu yamayı kabul etmeye sıcak bakmıyor ve çözümün PostgreSQL'in RSEQ (Restartable Sequences) zaman dilimi uzantısından yararlanması olduğunu söylüyor
    • RSEQ zaman dilimi uzantısı da Linux 7.0'a eklenen özelliklerden biri
    • Zijlstra, "bunun sayesinde kilit sahibinin preemption'a maruz kalması sınırlandırılabilir" açıklamasını yaptı

Etki alanı ve çıkış takvimi

  • Bu yaklaşım korunursa, PostgreSQL güncellenene kadar Linux 7.0 kararlı sürümünde bazı senaryolarda PostgreSQL performansı ciddi biçimde düşebilir
  • Linux 7.0 kararlı sürümünün yaklaşık 2 hafta sonra çıkması planlanıyor
  • Linux 7.0, Ubuntu 26.04 LTS'nin temel çekirdeği olacak; bu nedenle nisan sonunda çıkması beklenen Ubuntu 26.04 LTS'de de aynı etkinin görülmesi mümkün

İlgili okumalar

2 yorum

 
unstabler 23 일 전

Duyduğuma göre kernel geliştiricileri yaklaşık 10-20 yıldır PostgreSQL geliştiricilerine "userland'de spinlock önerilmiyor, bu yüzden bunu yeniden düşünseniz iyi olur" diye söylüyormuş..

https://x.com/kosaki55tea/status/2040458791536497035
 
GN⁺ 24 일 전
Hacker News görüşleri

  • Postgres geliştiricisi Andres Freund’un LKML takip yazısını okumaya değer

    • Performans sorunu yeniden üretilebilir bir regresyonsa (regression), bunu çözmek için 7.0’da yeni eklenen özellikleri kapatmak zorunda olmak tuhaf bir durum
    • Tek bir yazı yerine tüm ileti dizisini takip ederseniz ek bilgi çok daha fazla
    • Yalnızca 7.0’da görülen bir regresyonu çözmek için 7.0’da yeni getirilen düşük seviyeli özellikleri zorunlu kılmak iyi bir yaklaşım değil
      Linux bakımcılarının PostgreSQL gibi kritik uygulamaları öncelikli destek hedefi olarak görmesi gerektiği söyleniyor
      Bu, eskiden Fedora’da Wine kurulunca güncellemelerin engellendiği olayı hatırlatıyor
    • “hugepages kullanın” çözümü hep öneriliyor ama kullanıcıların çoğu bunu görmezden geliyor
    • Yalnızca ARM64 96 çekirdekli makinede performans 0,51 kata düştü, AMD64’te ise yeniden üretilemedi
      Yani PostgreSQL’i en yeni çekirdeğe yükselten herkesin yaşayacağı bir sorun değil

  • Kullanıcı alanında spinlock’u çekirdek desteği olmadan kullanmanın performans düşüşünü davet etmek olduğu görüşü var

    • Ben de Postgres’in spinlock kullanımını sevmiyorum ve bunu kademeli olarak kaldırıyorum
      Ancak futex tabanlı kilitler, bellek bariyeri artışı nedeniyle performans regresyonuna yol açıyor
      Ayrıca Postgres’in hâlâ 8 bayt atomik işlemleri desteklemeyen platformları hesaba katması gerekiyor, bu yüzden değiştirmek kolay değil
      Söz konusu spinlock kısa süre önce kaldırıldı ve huge pages kullanıldığında darboğaz neredeyse kayboluyor
    • Kullanıcı alanında spinlock kullanmak için “kendine çekişle suratına vurmak” benzetmesi yapılıyor
    • PostgreSQL’in eski çekirdeklerle uyumluluğu korumak için spinlock kullandığı ama artık bunu bırakma zamanının geldiğini söyleyenler de var

  • “Kimse en yeni çekirdeği prodüksiyonda kullanmaz” iddiası da vardı
    Gerçekte Ubuntu 26.04 LTS Linux 7.0 tabanlı olarak yakında çıkacağı için, pek çok kullanıcı bunu yakında kullanacak
    Sorun şu ki şu anda çözüm sysctl değil, çekirdek yaması gerektiriyor

    • Yine de bu tür sorunların erken fark edilmesi için en yeni çekirdeği test eden insanların olması gerekir
    • PostgreSQL etkileniyorsa, başka uygulamaların da etkilenme ihtimali var
    • Docker ortamlarında ana makine çekirdeği paylaşıldığı için seçme şansı olmadığı da belirtiliyor
    • Ayrıca PREEMPT_NONE seçeneğinin çoğu platformda kaldırıldığı hatırlatılıyor

  • PREEMPT_LAZY’nin arka planı için LWN makalesine bakılabilir

  • “Jia Tan son dönemde çekirdek yaması gönderdi mi diye baktınız mı?” şeklinde şaka yollu bir yorum vardı,
    buna da “buna gerek yok, zaten ortalık açıklarla dolu” diye yanıt verildi

  • PostgreSQL 18’deki asenkron I/O ve paralel sorgu optimizasyonlarının bu performans düşüşünü telafi edip edemeyeceğini merak edenler vardı
    İlgili ayrıntılar PostgreSQL 18 sürüm notlarında görülebilir

  • PREEMPT_LAZY gibi dinamik preemption modlarının neden gerekli olduğu da sorgulandı
    Sıradan kullanıcının elde edeceği faydanın belirsiz olduğu söyleniyor

    • Buna verilen yanıtta, bunun gecikmeyi artırmadan verimi yükseltmek için tasarlanmış olduğu açıklandı
      Çekirdeğin daha açık bilgiler alarak zamanlayıcı kararlarını iyileştirebildiği belirtiliyor

  • FreeBSD 14 ile 15.0 arasında %10 performans düşüşü ölçtüğünü söyleyen biri, bu örneği görünce rahatladığını yazdı

    • Ardından “ama en azından o kadar özellik eklendi mi?” tepkisi geldi

  • Phoronix’in yeterli doğrulama yapmadan haberi yayımladığı yönünde eleştiriler de vardı
    Takip e-postasında, benchmark’ın kendisinin hatalı olduğu ve gerçekte büyük bir sorun olmadığı sonucuna varıldı

    • Yine de regresyon yalnızca huge pages kullanılmadığında ortaya çıkıyor
      PostgreSQL için büyük bir sorun olmayabilir ama huge pages kullanamayan başka uygulamaları etkileyebilir
      Bu yüzden tamamen göz ardı edilecek bir durum olmadığı söyleniyor

  • Eski bir LKML ileti dizisi bağlantısı da paylaşıldı