Go dilinde çöp toplama (garbage collection) nasıl çalışıyor ve performansa etkisi nedir?

03 Eki 11:57

Go’nun GC’si “concurrent mark‑and‑sweep” tabanlı, yani iş parçacığıyla eşzamanlı olarak işaretleme yapıyor ve sadece “stop‑the‑world” anlarında kısa bir pause (genelde birkaç milisaniye) alıyor. Bu pause’ların uzunluğu büyük ölçüde heap’in büyüklüğüne ve “GOGC” (garbage‑collection hedefi) değerine bağlı. Varsayılan GOGC = 100 % olduğunda heap, son GC’den itibaren %100 büyüdükten sonra yeni bir GC tetikleniyor; bunu 50 % gibi düşük bir değere çeker iseniz GC daha sık ama daha az iş yapar, pause süresi kısalır ama toplam CPU harcaması artabilir. Ayrıca Go 1.5 sonrası gelen “generational” iyileştirmeler sayesinde kısa ömürlü nesneler daha çabuk toplanıyor, bu da yüksek tahsis oranlı servislerde pause’ları büyük ölçüde düşürüyor. Performans açısından kritik iki nokta var: birincisi tahsis hızı, ikincisi büyük nesnelerin (≥ 1 MB) heap’e sıkça eklenmesi. Tahsis hızı çok yüksekse GC’nin “concurrent mark” aşaması bile geride kalabilir ve pause’lar aniden 10‑20 ms’yi bulabilir. Büyük nesneler ise “large object heap”e düşer ve bu alanın toplama döngüsü daha nadir ama daha maliyetli olur. Bu yüzden üretim ortamında “GOGC” değerini %50‑%75 aralığında tutmak, “GODEBUG=gctrace=1” ile GC loglarını izlemek ve “pprof –alloc_space” gibi araçlarla tahsis profilini analiz etmek iyi bir başlangıçtır. Peki ya senin uygulamanın içinde sık sık “slice” yeniden tahsis edip kopyalama yapıyorsun? Bu tip “copy‑on‑write” davranışı GC’yi ekstra zorlamaz ama tahsis oranını artırır, bu da pause süresini uzatabilir. Ya da bir microservice içinde büyük JSON payload’larını `[]byte` olarak tutuyorsan, bu nesnelerin “large object” havuzuna düşmesi GC’nin “mark‑sweep” sürecinde ekstra bir yüke neden oluyor mu? Bu senaryoları göz önünde bulundurarak `sync.Pool` ile nesne yeniden kullanımını artırmak veya büyük payload’ları chunk‑luyarak yönetmek, pause’ları daha da kısaltabilir. Deneyimlerini paylaş, hangi ayarlarla en düşük latency’yi yakaladın?

03 Eki 14:39

Kanka, Go’nun GC’si “tri‑color marking” ve “concurrent sweeping” ile çalışıyor, duraklama süresi genelde milisaniyeler düzeyinde kalıyor; GOGC değeriyle heap büyümesini kontrol edip, GODEBUG=gctrace ile pause istatistiklerini izleyebilirsin. Biraz daha düşük latency istiyorsan GOGC’yi %50‑70’e çekerken, yüksek throughput için %200‑300 tutmayı denedin mi?

03 Eki 15:58

Go’da GC’nin “stop‑the‑world” tarzı bir duraklaması var ama modern sürümlerde bu süreler milisaniyeye inmiş. Benim en büyük ağrım, yüksek concurrency‑li bir websocket server’da aniden 10‑15 ms’lik pause’lar görüp istemcilerin timeout’a takılmasıydı. Sorunu çözmek için önce `GOGC` değerini %200’e çıkardım; bu GC’nin tetiklenme sıklığını azaltıp duraklamaları 3‑4 ms’ye çekti. Sonra ise `GODEBUG=gctrace=1` ile GC’nin ne zaman ve ne kadar süreyle durduğunu logladım, “mark‑terminate” aşamasının %70’inin büyük nesne havuzundan geldiğini fark ettim. Buradan yola çıkarak büyük slice ve map’leri mümkün olduğunca yeniden kullanmaya (sync.Pool) ve kısa ömürlü objelerden kaçınmaya başladım. Bir diğer ipucu da `GOMAXPROCS` ayarı; CPU sayısını artırınca GC’nin paralel mark aşaması daha hızlı çalışıyor, ama çok yüksek bir değer “work‑stealing” overhead’ine yol açabiliyor. Ben 8 çekirdekli bir makinede `GOMAXPROCS=4` kullandığımda latency en dengeli oldu. Kısacası, GC’nin duraklama süresini kontrol etmenin yolu: (1) `GOGC` ile tetikleme sıklığını ayarlamak, (2) büyük ve sık kullanılan objeleri pool’da tutmak, (3) `GODEBUG` ile trace alıp “hot‑spot”ları tespit etmek ve (4) `GOMAXPROCS` ile paralellik dengesini bulmak. Bu ayarlarla uygulamamda pause ortalaması 2‑3 ms’e düştü, kanka, performans artık çok daha stabil.