Recall.ai, haftalık milyonlarca toplantıyı kaydeden ve işleyen, alışılmadık bir iş yüküne sahip bir şirket. Toplantıların çoğu saat başında başladığı için, sistemleri anlık ve yüksek yoğunluklu yük artışlarıyla karşılaşıyor. Bu ani talep artışları, altyapılarının neredeyse her katmanında darboğazlara yol açmış. Şirket, bu darboğazlardan birini araştırırken, PostgreSQL'in derinliklerine inerek daha önce gözden kaçan bir performans sorununu ortaya çıkarmış.
Sorunun temelinde, her PostgreSQL sunucusunun başlangıcında ve sonunda çalışan postmaster süreci yatıyor. postmaster, bağlantıları ve paralel çalışanları yönetmek için alt süreçler oluşturmaktan ve sonlandırmaktan sorumlu. Ancak, postmaster tek iş parçacıklı bir ana döngüde çalışıyor. Yüksek sayıda yeni çalışan (worker) oluşturulması gerektiğinde, bu döngü tüm bir CPU çekirdeğini tüketerek bağlantı kurma, paralel sorgular ve sinyal işleme gibi süreçleri yavaşlatabiliyor. Bu durum, bazı EC2 örneklerinin 10-15 saniye gecikmesine neden olan, nadir ve hata ayıklaması zor bir soruna yol açmış; zira örnekler, bağlantıyı ele alacak yeni bir arka uç süreci oluşturması için postmaster'ı beklemek zorunda kalmış.
Aylar süren araştırmalar sonucunda, gecikmelerin PostgreSQL'e bağlantı kurma aşamasında yaşandığı tespit edilmiş. Müşteri, TCP bağlantısını başarıyla kurmasına rağmen, başlangıç mesajına sunucudan yanıtın 10 saniye sonra geldiği gözlemlenmiş. CPU, bellek, disk G/Ç ve ağ G/Ç gibi bariz kaynak darboğazları elenmiş. Bu durum, postmaster'ın tek iş parçacıklı yapısının, yüksek ölçekli ve dinamik iş yüklerinde nasıl kritik bir performans engeli oluşturabileceğini gözler önüne seriyor.
Yüksek ölçekli ve anlık yük artışları yaşayan sistemlerde PostgreSQL'in `postmaster` sürecinin tek iş parçacıklı yapısı, beklenmedik bağlantı gecikmelerine ve performans sorunlarına yol açabilir.