Brendan Gregg'in Gecikme ve Profil Çıkarma İçin Performans Yöntemleri

Brendan Gregg'in yaklaşımı neden tahminleri azaltır

Brendan Gregg, özellikle Linux dünyasında sistem performansı alanında en etkili isimlerden biridir. Yaygın olarak kullanılan kitaplar yazdı, pratik araçlar geliştirdi ve—en önemlisi—gerçek üretim sorunlarını araştırmak için net yöntemler paylaştı. Ekipler onun yaklaşımını benimsiyor çünkü baskı altında işe yarıyor: gecikme arttığında ve herkes cevap isterken, “belki X”ten “kesinlikle Y”ye az drama ile geçmek için bir yol gerekir.

"Performans metodolojisi" gerçekte ne demektir

Bir performans metodolojisi tek bir araç ya da zeki bir komut değildir. Ne bakılacağını, gördüğünüzü nasıl yorumlayacağınızı ve sonra ne yapacağınıza nasıl karar vereceğinizi belirten tekrarlanabilir bir inceleme yoludur.

Bu tekrarlanabilirlik tahminleri azaltır. En sezgili ya da en yüksek sesli kişiye güvenmek yerine, şu tutarlı süreci izlersiniz:

• problemi belirli bir kaynak, servis veya kod yoluna daraltır
• olgunun yaşandığı aynı zaman penceresinde ne olduğunu ölçer
• değişiklik yapmadan önce darboğazı kanıtla doğrular

Yaygın başarısızlık modu: ölçmeden düzeltme

Birçok gecikme incelemesi ilk beş dakika içinde yanlış yöne gider. İnsanlar doğrudan düzeltmelere atlar: “CPU ekle,” “servisi yeniden başlat,” “cache'i büyüt,” “GC'yi ayarla,” “muhtemelen ağdır.” Bazı durumlarda işe yararlar—çoğunlukla sinyali gizler, zaman kaybettirir veya yeni riskler getirir.

Gregg’in yöntemleri, daha basit soruları cevaplayana kadar “çözümleri” ertelemenizi sağlar: Hangi kaynak doymuş? Hangi hatalar var? Hangi şey yavaşladı—throughput, kuyruğa alma veya bireysel işlemler mi?

Bu rehber size ne sağlar

Bu rehber, kapsamı daraltmanıza, doğru sinyalleri ölçmenize ve optimize etmeden önce darboğazı doğrulamanıza yardımcı olur. Amaç, sonuçların şansa bağlı olmadığı, üretimde gecikme ve profil sorunlarını araştırmak için yapılandırılmış bir iş akışıdır.

Gecikme temelleri: ayarlamadan önce ne ölçülmeli

Gecikme bir belirtidir: kullanıcılar işin bitmesini daha uzun bekler. Neden genellikle başka yerdedir—CPU çatışması, disk veya ağ beklemeleri, kilit çatışması, çöp toplama, kuyruğa alma veya uzak bağımlılık gecikmeleri. Sadece gecikmeyi ölçmek, ağrının nereden kaynaklandığını söylemez.

Throughput, gecikme ve hatalar birlikte hareket eder

Bu üç sinyal birbirine bağlıdır:

• Throughput (istek/saniye) artışı kuyruğa almayı artırabilir ve bu da gecikmeyi yükseltir.
• Hatalar gözlemlenen gecikmeyi düşürebilir (hızlı başarısızlıklar) veya artırabilir (yeniden denemeler ve zaman aşımı).
• Throughput'u sınırlamak (oran sınırlama, backpressure) kuyruklu gecikmeyi iyileştirirken daha az isteğin başarılı olmasına neden olabilir.

Ayarlamaya başlamadan önce aynı zaman penceresi için tüm üç sinyali yakalayın. Aksi takdirde işi düşürerek veya daha hızlı başarısız kılarak gecikmeyi “düzelttiğinizi” sanabilirsiniz.

Ortalama değere güvenmeyin: yüzdelikler ve kuyruk gecikmesi

Ortalama gecikme kullanıcıların hatırladığı sıçramaları gizler. 50 ms ortalaması olan bir servis yine de sık sık 2 s beklemelere sahip olabilir.

Yüzdelikleri izleyin:

• p50: tipik kullanıcı deneyimi
• p95/p99: kuyruk gecikmesi (çoğu olay acısı burada toplanır)

Ayrıca gecikmenin şekline dikkat edin: p50 sabitken p99 yükseliyorsa genellikle aralıklı duraklamalar (ör. kilit çatışması, I/O takılmaları, stop-the-world duraklamaları) vardır, genel bir yavaşlama değil.

Gecikme bütçeleri: zamanın nereye gidebileceğini belirleme

Gecikme bütçesi basit bir muhasebe modelidir: “İstek 300 ms içinde bitmeli ise zaman nasıl harcanabilir?” Bunu şu kategorilere ayırın:

• serviste geçen süre (hesaplama + bekleme)
• alt servislerde geçen süre
• veritabanı/cache süreleri
• ağ transit ve TLS
• kuyruğa alınma süresi (threadler, bağlantı havuzları, load balancerlar)

Bu bütçe ilk ölçüm görevinizi çerçeveler: spike sırasında hangi kovanın büyüdüğünü belirleyin, sonra o alanı araştırın; körü körüne ayarlama yapmayın.

Açık bir soru ve kapsamla başlayın

Gecikme çalışmaları “sistem yavaş” gibi tanımlandığında sapar. Gregg’in yöntemleri daha erken başlar: sorunu belirli, test edilebilir bir soruya zorlayın.

"Yavaş" ne demek (ve kimin için) tanımlayın

Herhangi bir aracı kullanmadan önce iki cümle yazın:

• Ne yavaş? (sayfa yükleme, API uç noktası, toplu iş, giriş, ödeme, belirli bir SQL sorgusu)
• Nerede gözleniyor? (müşteri tarayıcısı, mobil uygulama, bir bölge, bir pod, bir host, dahili bir servis)

Bu, ağrının yanlış katmanı optimize etmenizi (ör. host CPU) engeller; çünkü sorun belirli bir uç nokta veya bağlı serviste olabilir.

Zaman penceresi ve kapsam seçin

Şikayetle eşleşen ve mümkünse “iyi” bir karşılaştırma dönemini içeren bir pencere seçin.

Soruşturmanızı açıkça sınırlandırın:

• Host vs servis vs uç nokta: “Bir Kubernetes düğümü” ile “bir API rotası” farklıdır.
• Hangi trafik dilimi: bölge, müşteri seviyesi, sadece hatalı istekler veya tüm istekler.
• Raporu tetikleyen sinyal: p95 gecikme, zaman aşımı, kuyruk derinliği veya kullanıcı zamanlaması.

Burada kesin olmak, sonraki adımları (USE, RED, profil) hızlandırır çünkü hipotez doğruysa hangi verinin değişmesi gerektiğini bilirsiniz.

Son değişiklikleri hipotez olarak ele alın, cevap değil

Dağıtımlar, yapılandırma değişiklikleri, trafik dalgalanmaları ve altyapı olaylarını not edin—ama nedenselliği varsaymayın. Bunları “Eğer X olsaydı, Y beklerdik” şeklinde yazın, böylece hızlıca doğrulayıp çürütebilirsiniz.

Hafif bir inceleme günlüğü tutun

Küçük bir günlük ekipler arasındaki tekrar eden çalışmayı önler ve devirlerin daha düzgün olmasını sağlar.

Time | Question | Scope | Data checked | Result | Next step

Böyle beş satır bile stresli bir olayı tekrarlanabilir bir sürece dönüştürebilir.

USE Yöntemi: kaynak darboğazlarının hızlı envanteri

USE Yöntemi (Utilization, Saturation, Errors) Gregg’in “büyük dörtlü” kaynakları—CPU, bellek, disk (depolama) ve ağ—tarafından hızlıca taramak için kontrol listesi gibidir; böylece tahmin etmeyi bırakıp sorunu daraltabilirsiniz.

Nedir: kaynak başına kontrol listesi

Düzine grafiklere bakmak yerine, her kaynak için aynı üç soruyu sorun:

• Kullanım: Şu an ne kadar meşgul?
• Doyma (saturation): İş birikiyor mu (kuyruklar, bekleme zamanı), kullanım maksimuma ulaşmamış olsa bile?
• Hatalar: Gecikmeye neden olacak şekilde başarısızlık veya yeniden deneme var mı?

Tutarlı uygulandığında bu, nerede “baskı” olduğunu hızlıca gösteren bir envanter olur.

Uygulamada nasıl uygulanır

CPU için kullanım CPU meşguliyet %, doygunluk run-queue basıncı veya çalışmayı bekleyen thread'ler olarak görünür ve hatalar konteynerlerdeki throttling veya yanlış davranan interrupt'lar olabilir.

Bellek için kullanım kullanılan bellek, doygunluk sayfalama veya sık GC olarak kendini gösterir, hatalar ise allocation hataları veya OOM olaylarıdır.

Disk için kullanım cihaz meşguliyet süresi, doygunluk kuyruk derinliği ve okuma/yazma bekleme zamanı, hatalar ise I/O hataları veya zaman aşımıdır.

Ağ için kullanım throughput, doygunluk düşmeler/kuyruklar/gecikme ve hatalar tekrar göndermeler, reset'ler veya paket kaybıdır.

Gecikme olaylarında en faydalı sinyaller

Kullanıcılar yavaşladı dediğinde, doyma sinyalleri genellikle en açıklayıcı olanlardır: kuyruklar, bekleme süreleri ve çatışma gecikme ile daha doğrudan korelasyon gösterir.

USE, servis metriklerini tamamlar (yerine geçmez)

Servis seviyesindeki metrikler (istek gecikmesi, hata oranı gibi) etkiyi söyler. USE ise hangi kaynağın baskı altında olduğunu bularak nereye bakılacağını söyler.

Pratik döngü:

1. Kullanıcı etkisini doğrula (Süre/Hatalar)
2. USE envanterini çalıştır
3. Şüpheli kaynağa daha derin araçlarla (profil, iz, kernel istatistikleri) yakınlaş

RED Yöntemi: etkiye odaklanan servis sinyalleri

RED Yöntemi sizi host grafiklerine dalmadan önce kullanıcı deneyimine bağlı tutar.

• Rate: servisinizin veya uç noktanızın kaç istek/saniye işlediği
• Errors: kaç isteğin başarısız olduğu (ve uygulamanız için "başarısızlık"ın ne anlama geldiği)
• Duration: başarılı işlemlerin ne kadar sürdüğü (ortalama değil yüzdeliklerle izlenmeli)

RED neden önceliklendirmenize yardım eder

RED, kullanıcıları etkilemeyen “ilginç” sistem metriklerinin peşinden gitmenizi engeller. Daha sıkı bir döngü kurar: hangi uç nokta yavaş, hangi kullanıcılar için ve ne zamandan beri? Eğer Duration sadece tek bir rotada yükseliyorsa ve genel CPU sabitse, zaten daha net bir başlangıç noktanız var demektir.

Faydalı bir alışkanlık: RED'i servis ve en çok kullanılan uç noktalar bazında kırın (veya ana RPC metotları). Bu, geniş çaplı bir bozulmayı yerel bir regresyondan ayırmayı kolaylaştırır.

RED semptomlarını USE kontrollerine eşleme

RED size acıyı nerede gösterir. USE, hangi kaynağın sorumlu olduğunu test etmenize yardımcı olur.

Örnekler:

• Duration arttı + Rate sabit → doygunluk/kuyruk kontrolü: CPU run queue, depolama gecikmesi, DB bağlantı havuzları.
• Errors arttı + Duration arttı → zaman aşımı ve yeniden denemeleri kontrol et: aşırı yüklenmiş downstream'ler, thread havuzları, ağ düşmeleri.
• Rate arttı + Duration arttı → kapasite limitlerini kontrol et: CPU kullanım, load balancer davranışı, autoscaling gecikmeleri.

Minimal "ne değişti?" panosu

Düzeni basit tutun:

1. RED genel görünüm: servis için Rate, Errors ve p50/p95/p99 Duration
2. En iyi uç noktalar: aynı RED sinyalleri uç nokta başına, trafik veya en kötü p95'e göre sıralı
3. Bağımlılıklar: büyük downstream'ler için RED tarzı paneller (DB, cache, dış API'ler)
4. Bir korelasyon satırı: servis görünümünden kök nedene hızla geçişi hızlandıracak birkaç sistem metriği (CPU, bellek basıncı, disk I/O gecikmesi, ağ retransmitleri)

Tutarlı bir olay iş akışı istiyorsanız, bu bölümü /blog/use-method-overview ile eşleştirin ki “kullanıcı hissediyor”dan “bu kaynak kısıt”a daha az çabayla geçebilin.

Önceliklendirme: soruyu daraltmak için sonraki en iyi soruyu seçin

Bir performans incelemesi dakikalar içinde onlarca grafik ve hipoteze patlayabilir. Gregg’in zihniyeti bunu dar tutmaktır: işiniz “daha fazla veri toplamak” değil, belirsizliği en hızlı şekilde ortadan kaldıracak sonraki soruyu sormaktır.

Dar boğazlar için 80/20 kuralı

Çoğu gecikme sorunu tek bir maliyet (veya küçük bir çift) tarafından domine edilir: bir sıcak kilit, yavaş bir bağımlılık, aşırı yüklenmiş disk, tek tip GC duraklaması. Önceliklendirme, önce o baskın maliyeti aramak demektir; çünkü beş farklı yerde %5 azaltmak kullanıcı görebilir gecikmeyi nadiren etkiler.

Pratik test: “Gördüğümüz gecikme değişiminin çoğunu ne açıklayabilir?” Eğer bir hipotez yalnızca küçük bir dilimi açıklayabiliyorsa, düşük önceliklidir.

Yukarıdan aşağı vs aşağıdan yukarı: nereden başlamalı

Yukarıdan aşağı kullanın eğer cevap "Kullanıcılar etkileniyor mu?" ise. Uç noktalardan (RED tarzı sinyaller) başlayın: gecikme, throughput, hatalar. Bu, kritik yol üzerinde olmayan bir şeyi optimize etmenizi engeller.

Aşağıdan yukarı kullanın eğer host açıkça hasta ise (USE tarzı semptomlar): CPU doygunluğu, kontrolsüz bellek basıncı, I/O bekleme. Bir düğüm tıpkıysa, uç nokta yüzdeliklerine bakmak boşuna zaman kaybı olur.

Thrash'i önleyen basit karar ağacı

Bir uyarı geldiğinde bir dal seçip onu doğrulayana veya çürütünceye kadar o dalda kalın:

• Gecikme sıçraması + hata sıçraması → "Bu bir bağımlılık mı yoksa kapasite olayı mı?" (zaman aşımı, bağlantı havuzu tükenmesi, downstream 5xx)
• Gecikme sıçraması + CPU sıçraması → "CPU faydalı iş mi yapıyor yoksa takıldı mı?" (on-CPU vs off-CPU zamanı)
• Gecikme sıçraması + yüksek I/O bekleme → "Hangi cihaz veya dosya sistemi kuyruğa takılıyor?"
• Kaynak sıçraması olmadan gecikme → "Zaman nerede bekleniyor?" (kilitler, scheduler, ağ, uzak çağrılar)

Metrik aşırı yükünden kaçının, sistematik kalın

Başlangıç için küçük bir sinyal seti ile sınırlayın, sonra bir şey hareket ettiğinde derinlemesine inin. Bir kontrol listesine ihtiyacınız varsa, adımlarınızı bir runbook'a bağlayın (ör. /blog/performance-incident-workflow) ki her yeni metrikin bir amacı olsun: belirli bir soruyu cevaplamak.

Üretimde sistemi kapatmadan profil çıkarma

Üretimde profil almak riskli gelebilir çünkü canlı sistemi etkiler—ama çoğu zaman tartışmayı kanıta dönüştürmenin en hızlı yoludur. Loglar ve panolar şeyin yavaş olduğunu söyleyebilir. Profil ise zamanın nereye gittiğini söyler: hangi fonksiyonlar sıcak, hangi thread'ler bekliyor ve hangi kod yolları olay sırasında baskın.

Profil gerçekte neyi cevaplar

Profil, bir “zaman bütçesi” aracıdır. Teorileri tartışmak yerine ("veritabanı" mu yoksa "GC" mi), şu tür kanıtlar alırsınız: “CPU örneklerinin %45'i JSON ayrıştırmada” veya “çoğu istek bir mutex'te bloklanıyor.” Bu, sonraki adımı bir veya iki somut düzeltmeye daraltır.

Üretimde kullanabileceğiniz yaygın tipler

• CPU profili: on-CPU hangi kodun çalıştığını gösterir.
• Off-CPU (bekleme) profili: thread'lerin nerede bloklandığını gösterir (I/O beklemeleri, scheduler gecikmeleri, sleep, ağ, disk).
• Kilit profili: çatışmayı gösterir—kilitler, mutex'ler ve okuma/yazma kilitlemelerinde kaybedilen zaman.

Her biri farklı bir soruyu yanıtlar. Düşük CPU ile yüksek gecikme genellikle off-CPU veya kilit zamanına işaret eder, CPU sıcak noktalarına değil.

Sürekli açık vs talep üzerine

• Sürekli açık profil (düşük yükle sürekli) “saat 03:00’te oldu” gizemleri için geriye bakmayı sağlar.
• Talep üzerine profil ise spike sırasında hedeflenmiş bir yakalama yapar. Benimsesi daha kolaydır, ama tetiklemeye hazır olmalısınız.

Birçok ekip talep üzerine başlar, güven oluşunca sürekli açık profillere geçer.

Güvenlik: yük, örnekleme ve kısa pencereler

Üretim güvenli profil, maliyeti kontrol etmektir. Örneklemeyi tercih edin (her olayı takip etmek yerine), yakalama pencerelerini kısa tutun (ör. 10–30 saniye) ve önce bir kanarya üzerinde yükü ölçün. Emin değilseniz, düşük frekanslı örneklemeyle başlayın ve sinyal çok gürültülü ise artırın.

Flame grafikleri: okumak ve yanlış sonuçlardan kaçınmak

Flame grafikleri, örnekleme penceresindeki zamanın nereye gittiğini görselleştirir. Her “kutu” bir fonksiyon (veya stack frame) ve her yığın o fonksiyona nasıl ulaşıldığını gösterir. Hızlı desenleri fark etmek için mükemmeldir—ama otomatik olarak “hata burada” demezler.

Flame grafiği ne gösterir (ve ne göstermez)

Bir flame grafiği genellikle on-CPU örnekleri temsil eder: programın gerçekten bir CPU çekirdeğinde çalıştığı zaman. CPU-yakan kod yollarını, verimsiz ayrıştırmayı, aşırı serileştirmeyi veya gerçekten CPU harcayan sıcak noktaları vurgulayabilir.

Gecikmelerin nedeni olan disk, ağ, scheduler gecikmeleri veya bir mutex üzerinde bekleme gibi off-CPU zamanını doğrudan göstermez (bunun için farklı profil gerekir). Ayrıca, kullanıcı görünür gecikme ile ilişkilendirmek için dikkatle scoped bir semptomla ilişkilendirilmelidir.

Genişlik ve yığın derinliğini okuma

• Genişlik: o frame'in örneklerde ne kadar göründüğü. Daha geniş olan genellikle “daha fazla CPU zamanı” demektir, ama sadece seçilen zaman penceresi içinde.
• Yığın derinliği: çağrı derinliği. Derin yığınlar otomatik olarak kötü değildir; önemli olan hangi yolların baskın olduğu ve ilgi duyduğunuz iş ile uyuşup uyuşmadığıdır.

Kaçınılması gereken yaygın tuzaklar

En geniş kutuya suç atmak caziptir, ama sorun: değiştirilebilir bir sıcak nokta mı yoksa upstream bir sorunun (malloc, GC, logging) sonucu mu? Ayrıca bağlam eksikliğine (JIT, inlining, semboller) dikkat edin; bu bir kutuyu fail eden değil, sadece mesajcıymış gibi gösterebilir.

Flame grafikleriyle kesin bir soru eşleştirin

Flame grafiğini şu şekilde ele alın: hangi uç nokta, hangi zaman penceresi, hangi hostlar ve ne değişti? “Önce vs sonra” (veya “sağlıklı vs bozuk”) flame grafikleri ile aynı istek yolunu karşılaştırın ki profil gürültüsünden kaçının.

Off-CPU zamanı: gecikmenin gizli kaynağı

Gecikme artınca birçok ekip önce CPU%'e bakar. Bu anlaşılır—ama genellikle yanlış yöne işaret eder. Bir servis "sadece %20 CPU" kullanıyor olsa bile, thread'lerin çoğu çalışmıyor ise son derece yavaş olabilir.

CPU% neden yanıltır

CPU% “işlemci ne kadar meşgul” sorusuna cevap verir. Bir isteğin zamanının nerede geçtiğini söylemez. İstekler, thread'ler beklerken, bloklanırken veya scheduler tarafından park edilirken duraklayabilir.

Ana fikir: bir isteğin duvar saati zamanı hem on-CPU işi hem de off-CPU beklemeyi içerir.

Yaygın off-CPU suçluları

Off-CPU zamanı genellikle bağımlılıklar ve çatışma arkasında gizlenir:

• Disk I/O: senkron okuma/yazma, fsync, yavaş depolama, sayfa önbelleği missleri.
• Ağ beklemeleri: DNS sorguları, TCP retransmitleri, aşırı yüklü upstream servisler.
• Kilit ve mutex çatışması: thread'lerin kilitlerde beklemesi, okuma/yazma kilitleri, allocator çatışması.
• Kuyruğa alma: thread havuzlarında, bağlantı havuzlarında veya dahili iş kuyruklarında bekleme.

İzlemeniz gereken belirtiler

Bir kaç sinyal genellikle off-CPU darboğazlarıyla korelasyon gösterir:

• artan kuyruk zamanı (isteklerin başlamadan önce beklemesi)
• artan runnable thread sayısı (CPU için daha fazla rekabet)
• yükselen I/O wait ve daha uzun disk/ağ gecikmeleri

Bu semptomlar “bekliyoruz” der, ama neye beklediğimizi söylemez.

Off-CPU profilinin zamanın nereye gittiğini göstermesi

Off-CPU profil, "neden çalışmıyordunuz"u işaret eder: syscalls içinde bloklanma, kilitlerde bekleme, uyuma veya deschedule edilme. Bu, gecikme işleri için güçlüdür çünkü belirsiz yavaşlamaları eyleme dönüştürülebilir kategorilere çevirir: “mutex X'te bloklanıyor”, “read() için disk bekliyor” veya “upstream'e connect() içinde takılıyor.” Beklemeyi isimlendirdiğinizde onu ölçebilir, doğrulayabilir ve düzeltebilirsiniz.

Sezgiler yerine kanıtla darboğazı doğrulayın

Performans çalışması genellikle aynı anda başarısız olur: biri kuşkulu bir metriği görür, "sorun bu" der ve ayarlamaya başlar. Gregg’in yöntemleri sizi yavaşlamaya ve sistemi sınırlayan şeyi kanıtlamaya zorlar.

Darboğaz, sıcak nokta ve gürültü

Bir darboğaz, şu anda throughput'u sınırlayan veya gecikmeyi sürükleyen kaynak veya bileşendir. Onu rahatlatırsanız, kullanıcılar iyileşme görür.

Bir sıcak nokta, zamanın harcandığı yerdir (ör. profilde sık görünen bir fonksiyon). Sıcak noktalar gerçek darboğaz olabilir—veya yavaş yol üzerinde etkisi olmayan yoğun işler olabilir.

Gürültü, anlamlı görünen ama olmayan her şeydir: arka plan işler, tek seferlik sıçramalar, örnekleme artefaktları, cache etkileri veya kullanıcı görünür soruna korele olmayan “top talker”lar.

Karşılaştırmalar ve kontrollü değişikliklerle kanıtlayın

Temiz bir önce anlık görüntüsü ile başlayın: kullanıcıya yansıyan semptom (gecikme veya hata oranı) ve önde gelen aday sinyaller (CPU doygunluğu, kuyruk derinliği, disk I/O, kilit çatışması vb.). Sonra sadece şüpheli nedeni etkilemesi gereken kontrollü bir değişiklik uygulayın.

Nedensel test örnekleri:

• Şüpheli kaynağa kapasite ekleyin (bir işçi daha, daha fazla CPU payı, daha yüksek bağlantı havuzu) ve gecikmenin iyileşip iyileşmediğine bakın.
• Talebi geçici olarak azaltın (gürültülü bir uç noktayı sınırlayın, daha küçük bir iş yükü replay edin) ve şüpheli kısıtın gevşeyip gevşemediğine bakın.

Korelasyon bir ipucudur, hüküm değildir. Eğer “CPU arttığında gecikme artıyor” ise, CPU kullanılabilirliğini değiştirerek veya CPU işi azaltarak gecikmenin takip edip etmediğini doğrulayın.

Kanıtladıklarınızı belgeleyin

Ne ölçüldü, yapılan tam değişiklik, önce/sonra sonuçları ve gözlemlenen iyileşmeyi yazın. Bu, tek seferlik bir kazanımı sonraki olay için tekrar kullanılabilir bir oyuna dönüştürür—ve sezgilerin sonradan tarihi yeniden yazmasını engeller.

Performans olayları için tekrarlanabilir bir iş akışı oluşturun

Performans olayları acil hissettirir; tam da bu durumda tahminler devreye girer. Hafif, tekrarlanabilir bir iş akışı sizi “bir şey yavaş” durumundan “ne değiştiğini biliyoruz” noktasına thrash olmadan taşır.

Olay döngüsü: tespit → triyaj → ölç → düzelt

Tespit: kullanıcıya yansıyan gecikme ve hata oranına göre uyarı verin, sadece CPU değil. Susturmalı bir pencere için p95/p99 eşiği aşıldığında sayfalayın.

Triyaj: hemen üç soruyu cevaplayın: ne yavaş, ne zaman başladı ve kim etkilendi? Kapsamı (servis, uç nokta, bölge, cohort) adlandıramıyorsanız optimize etmeye hazır değilsiniz.

Ölç: darboğazı daraltan kanıtları toplayın. Kıyaslama yapabilmek için zaman sınırlı yakalamaları tercih edin (ör. 60–180 saniye).

Düzelt: aynı anda tek bir değişiklik yapın, sonra aynı sinyalleri yeniden ölçerek iyileşmeyi doğrulayın ve placebo'yu elersiniz.

Küçük bir grafik setini standartlaştırın

Olaylar sırasında herkesin kullandığı paylaşılan bir pano tutun. Sıkıcı ve tutarlı olsun:

• Gecikme: p50 / p95 / p99 (kritik uç nokta başına)
• RED sinyalleri: Rate, Errors, Duration (servis-odaklı görünüm)
• Birkaç USE metriği: CPU, disk ve ağ için kullanım, doygunluk, hatalar

Amaç her şeyi grafiklemek değil; ilk gerçeğe ulaşma süresini kısaltmaktır.

Kritik uç nokta başına “altın sinyaller” belirleyin

En çok önem taşıyan uç noktaları (checkout, giriş, arama) instrument edin, her uç nokta için beklenen p95, maksimum hata oranı ve ana bağımlılığı (DB, cache, üçüncü taraf) belirleyin.

Olay sırasında ne yakalanacağına karar verin

Bir sonraki kesinti öncesi yakalama kitini kararlaştırın:

• Profiller (CPU ve off-CPU), ayrıca flame grafikleri
• Yavaş uç noktalar için izler
• Hata/zaman aşımı logları (örneklenmiş)

Bunu kısa bir runbook'ta (ör. /runbooks/latency) belgelen, kimlerin yakalama çalıştırabileceğini ve artefaktların nerede saklanacağını belirtin.

Koder.ai, Gregg tarzı iş akışında nerede durur

Gregg’in metodolojisi esasen kontrollü değişiklik ve hızlı doğrulama ile ilgilidir. Eğer ekibiniz hizmetleri Koder.ai kullanarak (web, backend ve mobil uygulamalar oluşturup yineleyen sohbet tabanlı bir platform) geliştiriyorsa, iki özellik bu zihniyete doğrudan uyar:

• Planning Mode bir gecikme tahminini açık bir hipoteze ve küçük, test edilebilir bir değişiklik setine dönüştürmenize yardımcı olur.
• Snapshots and rollback tek değişkenli deneyleri güvenli hale getirir: bir değişiklik uygulayın, RED/USE sinyallerini yeniden ölçün ve kanıt "hayır" derse hızla geri alın.

Olay sırasında yeni kod üretmiyor olsanız bile, küçük diff'ler, ölçülebilir sonuçlar ve hızlı geri alabilme alışkanlıkları Gregg’in önerdiği alışkanlıklarla örtüşür.

Pratik bir yürüyüş: gecikme sıçramasından doğrulanmış düzeltmeye

Senaryo: tepe trafikte p99 yükselir

Saat 10:15 ve panonuz API için p99'un tepe trafik sırasında ~120ms'den ~900ms'ye çıktığını gösteriyor. Hata oranı sabit, ancak müşteriler "yavaş" isteklerden şikayet ediyor.

Adım 1 — Kullanıcı etkisini bulmak için RED ile başlayın

Servis-odaklı olarak başlayın: Rate, Errors, Duration.

Duration'ı uç nokta bazında dilimlediğinizde tek bir rota p99'u domine ediyor: POST /checkout. Rate 2× artmış, hatalar normal ama Duration özellikle eşzamanlılık artınca yükseliyor. Bu kuyruğa alma veya çatışmaya işaret eder, açık bir arıza değil.

Sonra gecikmenin hesaplama zamanı mı yoksa bekleme zamanı mı olduğunu kontrol edin: uygulama “handler süresi” ile toplam istek süresini karşılaştırın (veya izleme varsa upstream vs downstream span'leri). Handler süresi düşük, toplam süre yüksek—istekler bekliyor.

Adım 2 — Şüpheli host(lar)da USE uygula

Muhtemel darboğazları envanterleyin: CPU, bellek, disk ve ağ için Kullanım, Doyma, Hatalar.

CPU kullanımı sadece ~%35, ama CPU run queue ve context switch'ler yükseliyor. Disk ve ağ stabil görünüyor. Bu uyumsuzluk (düşük CPU%, yüksek bekleme) klasik bir ipucu: thread'ler CPU yakmıyor—bloklanıyor.

Adım 3 — Semptomlara göre profil seçin

• CPU yüksekse: CPU profili (on-CPU flame grafikleri) kullanın.
• İstekler bekliyorsa: thread'lerin ne için bloklandığını görmek için off-CPU profili kullanın.

Spike sırasında alınan off-CPU profili, paylaşılan “promotion validation” cache etrafında yoğun mutex bekleme süresi gösteriyor.

Adım 4 — Düzelt ve doğrula

Global kilidi anahtar-bağımlı bir kilitle (per-key lock) veya kilitsiz bir okuma yoluyla değiştirin, dağıtın ve Rate yüksek kalırken p99'un normale döndüğünü izleyin.

Olay sonrası kontrol listesi:

• Tam RED semptomlarını ve daraltılan uç noktayı kaydedin.
• Profili ve zaman penceresini saklayın.
• Belirli doygunluk sinyali (ör. kilit bekleme / run queue) için uyarı ekleyin.
• Eğer tekrar olursa sorulacak “sonraki soru”yu not edin.