Postgres Nasıl Yavaşlatılır

• Postgres performansını aşırı derecede düşürebilecek parametre kombinasyonlarına yönelik deneysel bir yaklaşım tanıtılıyor
• Genellikle önbellek, indeks, WAL, I/O gibi çeşitli unsurlar ters yönde ayarlanıyor
• shared_buffers, autovacuum, WAL ile ilgili seçenekler uç noktalara çekilerek TPS'de 42.000 kat düşüş elde ediliyor
• Yeni Postgres 18/19 sürümlerindeki io_method ve io_workers gibi güncel özellikler de kullanılarak tek I/O iş parçacığı sınırı deneyi yapılıyor
• Deney sonuçları, yalnızca Postgres yapılandırma dosyasıyla bile aşırı performans düşüşünün mümkün olduğunu kanıtlıyor

---

Genel Bakış

Bu yazı, normalde hızlandırmaya odaklanan Postgres ayarlamasının tersine, yalnızca yavaşlatmayı hedefleyerek çeşitli PostgreSQL yapılandırma değerlerini değiştirip performansı sınırına kadar düşürmeye yönelik bir deneyin içeriğini anlatıyor.
Testler, BenchBase'in TPC-C iş yükü (128 depo, 100 bağlantı, her biri en fazla saniyede 10.000 işlem denemesi, güncel Postgres 19devel, Ryzen 7950x, 32GB RAM, 2TB SSD ortamı, 120 saniye çalışma) temelinde yapıldı.
Varsayılan durumda performans 7082 TPS idi ve her parametre müdahalesiyle ne kadar yavaşladığı adım adım gözlemlendi.

Önbelleği Büyük Ölçüde Azaltmak

• Postgres, disk I/O'yu azaltmak için güçlü bir önbellek (shared_buffers) kullanır
• Varsayılan değerden (10GB) shared_buffers 8MB'a düşürüldüğünde, TPS 1/7 seviyesine (1052 TPS) geriledi
• Önbellek isabet oranı %99,90'dan %70,52'ye düştü, read syscall sayısında 300 kattan fazla artış gözlemlendi
• 128kB'a kadar düşürülmeye çalışıldı ancak Postgres en az yaklaşık 2MB'a izin verdiği için performans 485 TPS'ye kadar daha da geriledi

Arka Plan İşlerini Artırmak (autovacuum ayarı)

• autovacuum ile ilgili tüm eşikler en düşük seviyeye çekilerek, neredeyse her işlemde vacuum çalışacak hale getirildi
  • autovacuum_vacuum_insert_threshold=1, autovacuum_naptime=1 gibi kombinasyonlar
  • Vacuum, fiilen yapacak işi olmasa bile neredeyse her 1 saniyede bir tekrar çalıştı
• Bu süreçte maintenance_work_mem 128kB'a düşürüldü, tüm autovacuum günlükleme seçenekleri etkinleştirildi
• Sonuç olarak TPS 293'e düştü (başlangıca göre 1/20'nin altı)
• autovacuum ile ilgili gerçek zamanlı günlükler üzerinden, sık arka plan işlerinin performans düşüşünün nedeni olduğu doğrulandı

WAL (Write-Ahead Log) Yazma İşlerini En Kötü Hale Getirmek

• WAL ile ilgili parametrelerin tamamı en kötü duruma ayarlandı
  • wal_writer_flush_after=0, wal_writer_delay=1, wal_sync_method=open_datasync vb.
  • Checkpoint her 30 saniyede bir zorlandı, min/max_wal_size=32MB ile minimumda tutuldu
  • wal_level=logical, wal_log_hints=on gibi ayarlarla WAL'e gereksiz bilgiler de yazdırıldı
  • track_wal_io_timing, summarize_wal gibi ek yükler de etkinleştirildi
• Bunun sonucunda TPS 98'e kadar düştü (başlangıca göre 1/70'in altı)
• Günlüklerde checkpoint'lerin birkaç yüz ms arayla tekrarlandığı gibi anormal davranışlar görüldü

İndeks Etkisini Ortadan Kaldırmak

• İndeks kullanımının tamamı, maliyeti en yüksek hesaplanan değerler (random_page_cost=1e300, cpu_index_tuple_cost=1e300) olarak ayarlanarak fiilen etkisiz hale getirildi
• Kararlılığı korumak için shared_buffers 8MB'a çıkarıldı, TPS ise 0,87'ye kadar düştü (7.000 kat yavaşlama sağlandı)

Tek I/O İş Parçacığını Zorlamak

• En yeni Postgres 18+ özellikleri kullanıldı
• io_method=worker, io_workers=1 ile tüm I/O tek bir worker iş parçacığına zorlandı
• TPS 0,016'ya kadar daha da düştü (42.000 kat yavaşlama)
• 100 bağlantılı, 120 saniyelik testte yalnızca 11 işlemin başarılı olabildiği kadar sınırlı bir performans görüldü

Sonuç ve Yeniden Üretim Rehberi

• Toplam 32 farklı parametre müdahalesiyle üretim veritabanının fiilen "felç" durumuna getirilebildiği kanıtlandı
• Yalnızca postgresql.conf ayarlarına dokunarak performans düşüşü en üst düzeye çıkarılabiliyor
• Deneyi yeniden üretmek isteyen kullanıcıların BenchBase Postgres'i, yukarıda belirtilen TPC-C ortamını ve tüm yapılandırma listesini incelemesi gerekiyor
• Bazı ek parametreler veya daha fazla yavaşlatma denemesi dahil edilmedi

Parametrelerin Kısa Özeti

• shared_buffers = 8MB
• autovacuum ile ilgili threshold/scale_factor değerleri = 0~1, en düşük seviye
• Vacuum ile ilgili maliyet, bellek ve günlükleme: en düşük ve en yüksek uçlara çekilmiş durumda
• WAL ile ilgili sync/flush/günlükleme/seviye vb.: yavaş kalacak şekilde ayarlanmış
• İndeks ile ilgili random_page_cost, cpu_index_tuple_cost: 1e300 olarak ayarlanmış
• io_method = worker, io_workers = 1
• Diğer ayrıntılı değerler için metindeki listeye bakın

Kapanış

• Sadece postgresql.conf dosyasıyla bile aşırı performans düşüşü tetiklenebilir
• Gerçek hayatta bu kombinasyonlar tersinden, yani verimli performans iyileştirmesi için referans alınmaya değer
• Yazı, deney sırasında yazarın bel ağrısı nedeniyle ara vermek zorunda kaldığını belirterek sona eriyor

[GN⁺]

Hacker News görüşleri

• İndeksler, birden çok tablo, transaction'lar, entity ilişkileri, referential integrity gibi şeyleri tamamen unutup, TRIRIGA'nın ilk sürümlerindeki gibi tüm veriyi tek bir tabloda KVS NoSQL SQL tarzında kullanma yaklaşımını tanıtıyor
• Bu yaklaşım o kadar eğlenceli ki, bunun devamı olarak "işleri daha da nasıl berbat ederiz" temasını işleyen bir kitap serisi bile çıksa güzel olur diye düşündüm; insan öğrenirken tersinden daha iyi yöntemleri de bulabiliyor. O’Reilly tarzında, kapağında özensiz çizilmiş fantastik hayvanlar olsa harika olurdu (örneğin iki başlı bir unicorn'un AirPods ile konuşurken bir dolandırıcıya para vermesi, PowerPoint hazırlaması, tıka basa yemesi ve uyuşturucu kullanması gibi)
  • 2. Dünya Savaşı sırasında gerçekten buna benzer bir strateji kullanılmıştı; pilotların sağ kalma oranını artırmak için meteorologlar önce en fazla can kaybına yol açan koşulları tespit etmiş, sonra görev planlarını bu koşullardan kaçınacak şekilde hazırlamıştı. İlgili bağlantı: Suppose I wanted to kill a lot of pilots
  • Yaratıcı yazarlık derslerinde de benzer egzersizler vardı; alıştırma sırasında kötü yazılmış metinleri okuyup analiz eder ya da iyi bir yazıyı bilerek kötü yeniden yazardık. En faydalı yazma egzersizleri bunlar olmuştu
  • ORLYBooks parodi sitesi da buna bakmak için güzel bir örnek
• Gözlemlenebilirlik araçlarını denemek için üretim benzeri bir sandbox ortamı olsa gerçekten harika olurdu diye düşünüyorum; makul büyüklükte SaaS tarzı bir sistem, kullanım simülasyonu ve sadece orta karar bir postgres/rabbit kurulumu üzerinde debug araçları ya da stratejiler konusundaki becerimi sınamak isterdim
• Bu fikir gerçekten dahiyane; optimizasyonu iyi yapmak istiyorsanız başlangıçta ya da kontrol grubu olarak önce tam tersini yapıp sistemi bilinçli şekilde berbat etmek iyi bir yöntem olabilir. Veritabanı ya da sistemlerle gerçekten bilimsel şekilde mi ilgileniyoruz, yoksa sadece belirsiz alışkanlıkları mı takip ediyoruz diye kendimize sormak lazım
  • Yeni bir cloud service kullanırken ben hep bunu yapıyorum; önce Series A'yı olabildiğince hızlı harcıyorum, sonra cloud cost optimization tarafına geçiyorum
• The Defence of Duffer's Drift kitabı bu türün erken örneklerinden biri. İlk hikâyede manga taktiklerini berbat ederek birliklerinin çoğunu kaybediyor; sonraki hikâyelerde ise taktik koşulları değiştirerek sonuçlar giderek iyileşiyor. Musicians of Mars 2 gibi daha yeni taktik kitapları da aynı yaklaşımı kullanıyor. İlk Team Badger hikâyesi, Duffer's Drift'e çok benziyor; sadece konum, ekipman ve teknoloji açısından uyarlanmış bir versiyonu. İlgili PDF'lere The Defence of Duffer's Drift ve Musicians of Mars 2 üzerinden ulaşılabilir. Team Badger komutanının ağır yenilginin ardından, özgüvenine ve hazırlığına rağmen neden bu kadar kötü yenildiğini sorgulaması özellikle etkileyiciydi
  • Benzer damardaki filmler arasında Groundhog Day ve özellikle Edge of Tomorrow var; ayrıca yakın zamanda bir Britanya askeri blogunda yayımlanan modern saygı duruşu niteliğindeki şu yazı da ilginç: Defence Baltic Bridge Dreams
• Deadlock'tan bahsedilmesi ilginçti; acaba transaction isolation level ayarlarıyla ilgili bir bölüm de var mı diye merak ettim
• B Sanderson referansını görmek hoşuma gitti
• Hyperbole and a Half ile bir db admin karışımı gibiydi; okurken keyif aldım ve birkaç şey de öğrendim
• Yazım tarzı ve düşünceleri açma biçimi gerçekten çok iyiydi; oldukça eğlenceli bir okumaydı

[sonic0987]

Harika. Bu tür bir yaklaşımı gerçekten çok seviyorum.