10 puan yazan xguru 2021-11-15 | 1 yorum | WhatsApp'ta paylaş
  • Heap, analiz amaçlı çoklu petabayt ölçeğinde Postgres işletiyor

  • Hızla büyürken düğüm kullanım oranı %80'i aştı ve veri toplama pipeline'ında performans sorunları ortaya çıktı

  • Sorunun nedeni, SSD'lerin kullanım oranı %100'e yaklaştığında performanslarının düşme eğilimi göstermesi

  • CoW (Copy-on-Write) olan ZFS kullanılması nedeniyle sorun daha da kötüleşti

→ blok her güncellendiğinde yeni bir kopya yazılıyor

  • Elbette CoW'un çeşitli avantajları da var

→ dosya sistemi düzeyindeki sıkıştırma, diğer dosya sistemlerine kıyasla daha kolay olduğu için 4-5x sıkıştırma ile alandan tasarruf sağlıyor

→ daha yüksek dayanıklılık sunduğu için Postgres'in full_page_writes ayarını devre dışı bırakmak mümkün oluyor; bu da performansı artırıp toplam IO'yu azaltıyor

→ tutarlılığı garanti eden point-in-time snapshot'lar - sayfalar fiilen değiştirilemediği için snapshot sırasında da eski sayfalar korunuyor

  • Ancak ZFS gibi CoW dosya sistemlerinde kapasite doldukça performans düşüyor

→ her sayfa güncellemesinde blok allocator'ın boş blok bulması gerektiğinden, kullanım oranı yükseldikçe performans kaybı ciddi hale geliyor

→ daha önce unlink edilmiş blokların silinmesi ve mevcut bloklarla karıştırılması gerekiyor

→ daha yüksek sıkıştırma oranı elde etmek için blok boyutunun 64kb olarak büyük ayarlanmış olması durumu daha da kötüleştirdi

→ bu nedenlerle ZFS kullanım oranının %80'i aşmaması öneriliyor

  • ZFS 2.x'e yükseltilip lz4 sıkıştırmadan Zstandard sıkıştırmaya geçiş denenmiş

lz4 son derece hızlı ve yaklaşık 4.4x sıkıştırma oranı sunuyor

→ Zstandard ise yaklaşık 5.5x'e kadar sıkıştırma oranı göstererek %20 iyileşme sağlıyor

→ ancak birçok benchmark'ta Zstandard'ın lz4'ten daha yavaş olduğu görülüyor

→ bu yüzden gerçek ortamda sıkı testler yapmaya karar verilmiş

→ test sonuçlarında sorgu performansı değişmezken depolama kullanımı yaklaşık %20 azalmış ve yazma sorgularının süresi yarıya inmiş

  • Heap'in DB kümesi 5 düğüme ayrılmış durumda ve her biri kendi ASG'sine bağlı

→ düğüm değiştirmek için yalnızca ASG'den ayırmak yeterli; ardından ASG yeni bir düğüm oluşturuyor, son yedekten geri yüklüyor ve warm standby moduna geçiyor

→ yeni yapılandırmayla bir AMI oluşturulup her düğüm tek tek geçirilmiş

→ toplam kullanım yaklaşık %21 azaldı, yazma süresi %50 düştü ve sorgu performansında kayda değer bir fark olmadı

1 yorum

 
xguru 2021-11-15

Yazıda CPU kullanım oranından bahsedilmiyor, ancak HN'de orijinal yazarın yorumuna bakılırsa bunun yaklaşık %40'tan yaklaşık %50'ye çıktığı söyleniyor. (Yani Zstd'nin CPU'yu daha fazla kullandığı anlamına geliyor)