Linux'ta CPU Profiling ve perf Kullanımı: strace'in Kör Noktası ve Zihin Okuma

Önceki yazımızda Linux Bellek Yönetimi ve OOM Killer ile Yüzleşmek başlığı altında, RAM bittiğinde Kernel’ın nasıl bir “Seri Katil”e dönüştüğünü ve süreçleri nasıl infaz ettiğini incelemiştik.

Peki ya program ölmezse? Ya tam tersine, aşırı yaşam enerjisiyle dolup CPU’yu %100 sömürürse?

Sunucu odasına girdiniz. Fanlar son devirde dönüyor. Bir uçak kalkıyor sanki. Terminale koştunuz, top yazdınız. En tepede bir süreç, kıpkırmızı %100 CPU ile size bakıyor. Hemen dedektif çantanızdan o güvendiğiniz büyülteci (strace) çıkardınız ve suçluyu izlemeye başladınız.

Siz: “Yakalandın! Bakalım arkada hangi dosyaları okuyorsun?” Strace: (Sessizlik…) Siz: “Hadi ama, bir read, bir write, en azından bir futex?” Strace: (Koca bir hiç…)

İmleç yanıp sönüyor. Ekranda hiçbir hareket yok. Ama top hala %100 diyor.

Siz: “Kim yalan söylüyor?” Kernel: “İkisi de doğru söylüyor. Sorun, senin baktığın yerde.”

📚 Teknik Mola: %us vs %sy Ayrımı top çıktısındaki CPU satırı bir haritadır.

• %sy (System): Yüksekse, Kernel meşguldür (Disk, Ağ, Donanım). -> strace kullanın.
• %us (User): Yüksekse, program kendi beyninin içinde (User Space) matematik yapıyordur. -> strace kördür, perf gerekir.
• %st (Steal): Buluttaysanız (%10+), komşunuz kaynağınızı çalıyordur. Yapacak bir şey yok, sağlayıcıya bağırın.

Bu yazıda, strace mikroskobunu çöpe atıp, perf (Linux Profiling Tools) cihazını elimize alıyoruz. Çünkü sorun artık Kernel’da (Devlet Dairesi) değil, uygulamanın kendi beyninin (User Space) içinde.

� Bu Yazıda Ne Öğreneceksin?

Bu yazı, sadece bir komut listesi değil, işlemcinin (CPU) zihnine bir yolculuktur. Okumayı bitirdiğinizde:

• Görünmezi Görmek (Sampling): Video çekmek yerine “Fotoğraf Çekme” (Sampling) yöntemiyle, sistemi yormadan nasıl analiz yapacağınızı öğreneceksiniz.
• Flame Graph Sanatı: Anlamsız metin yığınlarını, New York silüeti gibi okunabilir Alev Grafikleri’ne nasıl çevireceğinizi keşfedeceksiniz.
• Donanım Yalanları (IPC & Cache Miss): İşlemcinin “Çalışıyorum” derken aslında RAM’den veri beklerken nasıl “Parmaklarıyla ritim tuttuğunu” (Stall) göreceksiniz.
• Production Stratejileri: Canlı sistemde perf record ile veri kaybetmeden nasıl analiz yapacağınızı ve “Frame Pointer” tuzağına düşmemeyi öğreneceksiniz.

Şimdi dedektif şapkanızı takın. Suç mahalli User Space.

🕵️‍♂️ 1. Duvarın Ötesi: Kütüphane Analojisi

Bizim bugünkü konumuz, %us değerinin tavan yaptığı ama %sy değerinin düşük olduğu durumlar.

graph TD
    subgraph UserSpace["User Space (%us)"]
        App["Uygulama"]
        Loop["Sonsuz Döngü / Hesaplama"]
        App --> Loop
        Loop --> App
    end
    
    subgraph KernelSpace["Kernel Space (%sy)"]
        Syscall["Sistem Çağrıları"]
        Disk["Disk I/O"]
        Net["Network"]
    end

    App -- "read/write" --> Syscall
    
    Perf["perf"] -.->|Gözler| UserSpace
    Strace["strace"] -.->|Gözler| Syscall
    
    style UserSpace stroke:#01579b,stroke-width:2px,fill:transparent
    style KernelSpace stroke:#b71c1c,stroke-width:2px,fill:transparent
    style Perf stroke:#4caf50,stroke-width:2px,fill:transparent
    style Strace stroke:#ff9800,stroke-width:2px,fill:transparent

🧱 1. Duvarın Ötesi: Kütüphane Analojisi

Bu durumu anlamak için Kütüphane (Kernel) ve Öğrenci (Program) analojimizi derinleştirelim.

• strace (Kütüphaneci): Masasında oturur. Öğrenci gelip “Şu kitabı verir misin?” (read) veya “Fotokopi çeker misin?” (write) dediğinde bunu kaydeder.
• User Space (Çalışma Masası): Öğrenci kitabı alır ve masasına geçer.

Öğrenci masasında kitabı okurken, kafasından hesap yaparken veya sadece tavana bakıp hayal kurarken (CPU Bound), kütüphaneci bunu göremez. Kütüphaneci sadece öğrenci masaya (Kernel Space) geldiğinde devreye girer.

Eğer öğrenci masasında sonsuz bir döngüye girip aynı sayfayı 1000 kere okuyorsa, kütüphanecinin ruhu bile duymaz. strace ekranı bu yüzden boştur. Öğrenci çalışıyordur, ter döküyordur (CPU ısınır), ama kütüphaneciden hiçbir şey istemiyordur.

İşte bu noktada, masaları tek tek gezip “Sen ne okuyorsun?” diye soran bir müfettişe ihtiyacımız var: perf.

🔬 2. Yeni Silahımız: perf ve Sampling (Örnekleme)

Eğer strace bir güvenlik kamerasıysa (giriş-çıkışı izler), perf bir müfettiştir.

perf, Linux çekirdeğinin (CPU’nun donanım sayaçlarının) gücünü kullanarak Sampling (Örnekleme) yöntemiyle çalışır.

📸 Analoji: Video Kamera vs Fotoğraf Makinesi strace bir video kamera gibidir; her şeyi saniyesi saniyesine kaydeder (aşırı yer kaplar). perf ise seri çekim yapan bir fotoğraf makinesi gibidir. Saniyede 1000 kare fotoğraf çeker. Her şeyi göremez ama 1000 karenin 990’ında “Uyuyan Kedi” görüyorsanız, kedinin gün boyu uyuduğunu istatistiksel olarak kanıtlarsınız.

Çalışma mantığı şöyledir:

1. Müfettiş (perf), elinde bir düdükle odaya girer.
2. Saniyede 100/1000 kez düdük çalar (Interrupt).
3. O an CPU’da çalışan herkese “Don!” der.
4. Kimin hangi sayfayı okuduğuna (Instruction Pointer) bakar.
5. Not alır ve “Devam et” der.

🧠 Teknik Detay: Instruction Pointer (IP) İşlemcinin (CPU) o an çalıştırdığı kod satırının bellek adresidir. CPU her bir komutu (Instruction) işlediğinde, bu ibre bir sonraki komutu gösterecek şekilde ilerler. perf bu adresi okuyarak “Şu an kodun neresindeyiz?” sorusuna cevap verir.

Bu işlem o kadar hızlı olur ki, programlar durdurulduklarını (neredeyse) hissetmez bile.

sequenceDiagram
    participant CPU
    participant Perf as Perf (Müfettiş)
    participant App as Uygulama (User Space)

    Note over App: Matematik Hesabı Yapıyor...
    App->>CPU: Instruction A
    App->>CPU: Instruction B
    
    Perf->>CPU: ⚡ INTERRUPT (Düdük Çal!)
    Note right of Perf: O an neredeyiz? "Function X"
    Perf-->>App: (Kaydet ve Devam Et)
    
    App->>CPU: Instruction C
    App->>CPU: Instruction D
    
    Perf->>CPU: ⚡ INTERRUPT
    Note right of Perf: O an neredeyiz? "Function X"
    
    Note over Perf: Sonuç: %100 Vakit "Function X"te geçiyor.

Bu istatistiksel bir yaklaşımdır. Eğer müfettiş odaya 100 kere girdiğinde 90’ında sizi “Çay içerken” yakalıyorsa, mesainizin %90’ını çay içerek geçiriyorsunuz demektir.

Kurulum (Eğer Yoksa)

Çoğu minimal sistemde gelmez.

# Ubuntu/Debian
sudo apt install linux-tools-common linux-tools-generic linux-tools-$(uname -r)

# RHEL/CentOS/Fedora
sudo yum install perf

⚠️ Hata Alırsanız: Paranoyak Kernel perf komutu çalışmıyorsa (örn: “Permission denied”), Kernel güvenlik seviyesi yüksek olabilir (/proc/sys/kernel/perf_event_paranoid > 2). Geçici olarak izin vermek için: sudo sysctl -w kernel.perf_event_paranoid=-1

🎥 3. Canlı İzleme: perf top

Hadi şu %100 CPU yiyen hayalet süreci yakalayalım. Komutumuz tipk top gibidir, ama fonksiyonları gösterir:

☁️ Bulut Kullanıcılarına Not (No PMU): AWS EC2 (T serisi), DigitalOcean vb. paylaşımlı sanal sunucularda donanım sayaçları (Hardware Counters) genelde kapalıdır. perf top hata verirse veya boş gelirse, donanım döngüleri yerine yazılım saatini kullanmaya zorlayın: sudo perf top -e cpu-clock

# -g: Call Graph (Çağıran fonksiyonları da göster)
# -F 99: Frequency (Saniyede sadece 99 kez bak, sistemi yorma)
sudo perf top -g -F 99 -p <PID>

(Eğer PID vermezseniz tüm sistemi izler).

Karşınıza şöyle bir ekran çıkacaktır:

Samples: 45K of event 'cycles', Event count (approx.): 123456789
Overhead  Shared Object       Symbol
  95.50%  my_bad_program      [.] heavy_calculation_function
   2.10%  libc-2.31.so        [.] _int_malloc
   0.50%  [kernel]            [k] do_syscall_64

🔄 Özel Durum: Spinlock (Meşgul Bekleme) Eğer Overhead listesinin tepesinde _spin_lock, pthread_spin_lock gibi ifadeler görüyorsanız, programınız aslında bekliyordur. Ancak “uyuyarak” (Context Switch) değil, “dönüp durarak” (Busy Wait) bekliyordur. Bu, çok çekirdekli sistemlerdeki hatalı Thread senkronizasyonunun en büyük işaretidir.

Bu Tabloyu Nasıl Okuruz?

1. Overhead: İşlemcinin harcadığı vaktin yüzdesi. %95.50 çok ciddi bir rakam.
2. Shared Object: Bu kod nerede? my_bad_programın kendisinde mi, yoksa çağırdığı bir kütüphanede (libc, libssl) mi?
3. Symbol: Fonksiyonun adı. İşte suçlu burada: heavy_calculation_function.

Artık sorunun diskte, ağda veya kernel’da olmadığını biliyorsunuz. Sorun, yazılımcının yazdığı heavy_calculation_function isimli fonksiyonda.

📼 4. Olay Mahalli Kaydı: perf record ve perf report

Canlı izlemek (top) heyecanlıdır ama SSH bağlantınız koptuğu an veriler uçar. Ayrıca production sunucusunda analiz yapmak sistemi yorar. Profesyonel yöntem şudur: Kaydet, İndir, İncele.

graph LR
    subgraph Live["Canlı (Riskli)"]
        Top["perf top"] -- "SSH Koparsa?" --> Lost["Veri Kaybı"]
    end

    subgraph Offline["Offline (Güvenli)"]
        Record["perf record"] -- "perf.data" --> Disk["Disk (Kayit)"]
        Disk -- "perf report" --> Analyze["Analiz"]
    end
    
    style Live stroke:#f44336,stroke-width:2px,fill:transparent
    style Offline stroke:#4caf50,stroke-width:2px,fill:transparent
    style Top stroke:#f44336,stroke-width:1px,fill:transparent
    style Record stroke:#4caf50,stroke-width:1px,fill:transparent
    style Disk stroke:#2196f3,stroke-width:1px,fill:transparent
    style Analyze stroke:#4caf50,stroke-width:1px,fill:transparent

1. Kayıt Al (10 Saniye): Tüm CPU aktivitesini perf.data dosyasına kaydeder.

   # -a: All CPUs (Tüm çekirdekler)
   # -g: Call Graph (Hiyerarşi)
   # -- sleep 10: 10 saniye boyunca topla ve dur
   sudo perf record -a -g -- sleep 10
   

   ⚠️ Grafik Çıkmıyor mu? (Kırık Stack Trace Sorunu) Eğer raporunuzda hiyerarşi (ağaç yapısı) görmüyor ve fonksiyonlar birbirinden kopuk duruyorsa, sisteminiz Frame Pointer‘ları kapatarak derlenmiş demektir (-fomit-frame-pointer). Bu durumda perf zinciri takip edemez. Çözüm olarak DWARF yöntemini (daha yavaştır ama kesindir) kullanın: sudo perf record -g --call-graph dwarf -p <PID> -- sleep 10 (Not: Bu işlem perf.data dosyasını devasa boyutlara ulaştırabilir, dikkat!)

2. Raporu Oku: Oluşan perf.data dosyasını terminalde interaktif olarak inceleyin.

   sudo perf report
   

   (Bu arayüzde ok tuşlarıyla fonksiyonların içine girebilir, + işaretine basarak o fonksiyonu kimin çağırdığını (Call Graph) genişletebilirsiniz.)

   • Self vs Children:
     • Self: Fonksiyonun bizzat kendi kodunu çalıştırırken harcadığı vakit. (Suçlu burasıdır).
     • Children: Fonksiyonun çağırdığı diğer fonksiyonların harcadığı vakit. (Burası sadece bir yöneticidir, asıl işi başkası yapıyordur).
     • Optimizasyon yapacaksanız Self değeri yüksek olanlara odaklanın.

🧮 5. Ne Kadar Verimli? perf stat ve IPC

Bazen fonksiyonun “nerede” vakit harcadığı yetmez, “nasıl” harcadığı da önemlidir. İşlemci verimli mi çalışıyor, yoksa belleği mi bekliyor? Bunun için IPC (Instructions Per Cycle) metriğine bakarız.

sudo perf stat -p <PID> sleep 5

Çıktıda şunun gibi bir satır arayın:

3,456,789      cycles
2,500,000      instructions              # 0.72  insn per cycle

📚 Teknik Kural: IPC Skoru

• IPC > 1.0: İşlemci çok verimli. Kod iyi yazılmış (Branch Prediction başarılı). Gerçek bir “CPU Bound” iş (Video işleme, Şifreleme).
• IPC < 1.0: İşlemci tembel. Çoğu döngüsünde (cycle) boşta bekliyor (Stall). Muhtemelen Memory Latency (RAM’den veri gelmesini bekleme) veya kötü yazılmış kod (Cache Miss) sorunu var.

🐢 Analoji: Ferrari ve Kaplumbağa İşlemciniz (CPU) bir Ferrari‘dir. RAM (Memory) ise bir Kaplumbağa‘dır. Eğer kodunuz sürekli RAM’den veri okumak zorundaysa (Cache Miss), Ferrari sürekli fren yapıp kaplumbağanın yolu geçmesini bekler. Motor bağırır (%100 CPU), benzin yakar ama araba gitmez (Düşük IPC). İyi kod, verileri Ferrari’nin bagajında (L1/L2 Cache) tutarak kaplumbağayı beklemeden son sürat gitmeyi başarır.

🧩 CPU Neyi Bekliyor? (Cache Miss) IPC düşükse (< 0.5), işlemci muhtemelen Cache Miss yaşıyordur. Yani işlemci çok hızlıdır ama veriler RAM’den işlemciye gelene kadar işlemci “parmaklarıyla ritim tutarak” bekliyordur. Bu bekleme süresi de CPU kullanımına dahil edilir! Bunu doğrulamak için: perf stat -e cycles,instructions,cache-misses -p <PID>

❓ Hangi Olayları İzleyebilirim? CPU’nuzun desteklediği tüm olayları görmek için perf list komutunu kullanın. perf list | grep cache diyerek sadece önbellek olaylarını bulabilir, sonra bunları perf stat -e L1-dcache-loads ... şeklinde kullanabilirsiniz.

---

🚦 6. Görünmez Maliyet: Context Switch (pidstat)

Bazen perf ile bile net bir fonksiyon göremezsiniz. Ama CPU kullanımı yüksektir. Sorun, programın sürekli Gönüllü (Voluntary) veya Zorla (Involuntary) CPU’yu bırakması olabilir.

⚡ Teknik Detay: Context Switch (Bağlam Değiştirme) CPU bir işlemi durdurup diğerine geçerken, o anki tüm kayıtları (Registers) ve belleği (Stack) kaydetmek zorundadır. Bu işlem “Masa toplamak ve yeniden kurmak” gibidir; maliyetlidir. Saniyede binlerce kez yapılırsa, CPU iş yapmak yerine sadece masa toplayıp kurmakla (%System) vakit harcar.

pidstat -w -p <PID> 1

• cswch/s (Voluntary): Program kendi isteğiyle (sleep, mutex lock beklerken) CPU’yu bırakıyor. Sorun mantıksal olabilir (Kötü Lock kullanımı).
• nvcswch/s (Involuntary): Programın süresi doldu (Time Slice) veya daha öncelikli bir iş geldi. CPU yetmiyor veya çok fazla thread (1000+) ile “Thrashing” yaşanıyor.

🕵️‍♂️ 7. Vaka Analizi: “Sonsuz Döngü” (Infinite Loop)

Bir Python scripti yazdınız ama yanlışlıkla sonsuz döngüye soktunuz.

# bad_loop.py
def hesapla():
    i = 0
    while True:
        i = i + 1  # Sonsuza kadar topla

hesapla()

Bunu çalıştırın. Bir çekirdeği %100 kullanacaktır. strace -p <PID> yapın. Ekran bomboş olacaktır. Çünkü i + 1 işlemi Kernel’ı ilgilendirmez. Tamamen CPU ve RAM (Register) arasında döner.

Şimdi perf top -p <PID> yapın:

Overhead  Shared Object       Symbol
  40.00%  python3.8           [.] _PyEval_EvalFrameDefault
  20.00%  python3.8           [.] PyLong_FromLong

Gördünüz mü? Python yorumlayıcısının (_PyEval_EvalFrameDefault) sürekli çalıştığını yakaladınız. Bu, kodun sürekli bir döngüde “yorumlandığını” (execute edildiğini) kanıtlar.

💡 İpucu: Derlenen dillerde (C/C++, Go, Rust) fonksiyon adını net görürsünüz. Yorumlanan dillerde (Python, Ruby, Java) ise genellikle o dilin sanal makinesinin (VM) fonksiyonlarını görürsünüz (Örn: JVM, V8, PyEval). Daha derin analiz için o dillere özel profiler’lar (py-spy, async-profiler) gerekebilir ama perf size “Sorun CPU Bound” teşhisini koydurur.

🕵️‍♂️ 8. Vaka Analizi: “Deli Gibi Şifreleme” (Crypto Mining veya SSL)

Bazen sunucunuz hacklenmiştir ve bir Crypto Miner çalışıyordur. Veya uygulamanız yanlışlıkla sürekli SSL Handshake yapıyordur. perf top çıktısında şunları görürseniz tetikte olun:

Overhead  Symbol
  80.12%  sha256_transform_avx2
  10.05%  aes_encrypt_block

sha256, md5, aes, gzip gibi kelimeler görüyorsanız, işlemci Matematiksel Hesaplama ile meşguldür.

• Bu beklenen bir şey mi? (Video işleme, sıkıştırma sunucusu?)
• Yoksa beklenmedik bir şey mi? (Hacklenme, sonsuz şifreleme döngüsü?)

strace bunu asla gösteremezdi. Çünkü şifreleme, saf matematiktir ve User Space’te yapılır.

🛠️ 9. “Symbol not found” (Hex Adresler) Sorunu

Bazen perf top çalıştırırsınız ve fonksiyon isimleri yerine sadece anlamsız Hex adresler görürsünüz:

Overhead  Symbol
  60.00%  0x0000000004f2a1
  30.00%  0x0000000004f2b5

Bunun sebebi, kullandığınız programın “Stripped” (Sembollerinden arındırılmış) olmasıdır. Derlenirken debug sembolleri (isim etiketleri) silinmiştir. Production ortamlarında bu normaldir (Dosya boyutu küçülsün diye).

📖 Teknik Detay: Symbol Table (Sembol Tablosu) Bilgisayarlar sayılarla (Hex adresler: 0x4005d9), insanlar isimlerle (function_topla) çalışır. Derleyici kodu makine diline çevirirken bu eşleşmeleri bir “Sembol Tablosu”nda tutar. “Stripped” dosyalar, dosya boyutu küçülsün diye bu tabloyu çöpe atar. Bu yüzden perf size sadece kapı numarasını (adres) söyler, içeride kimin oturduğunu söyleyemez.

Çözüm: Eğer bu bir sistem paketi ise (örn: nginx, libc), o dağıtımın Debug Info paketlerini kurmanız gerekir.

• Ubuntu: nginx-dbgsym, libc6-dbgsym
• CentOS: debuginfo-install glibc

Bu paketleri kurduğunuzda perf, o hex adreslerin hangi fonksiyona denk geldiğini haritalayabilir.

⚠️ Önemli Not (JIT ve Containerlar):

• Java / Node.js: “Just-In-Time” (JIT) dilleri, makine kodunu RAM’de anlık üretir. perf bunları tanıyamaz. perf-map-agent (Java) veya --perf-basic-prof (Node.js) kullanmazsanız sadece hex adresler görürsünüz.
• Docker / Kubernetes: Host makineden perf top -p <ContainerPID> ile konteynerin içine bakabilirsiniz. Ancak kütüphaneler (libc, npm modülleri) konteyner dosya sisteminde olduğu için semboller yine eksik (hex) görünebilir.

⚠️ Önemli Not: Ubuntu’da debug sembolleri için ddebs deposunu, RHEL/CentOS’te ise debuginfo reposunu açmanız gerekebilir. Aksi takdirde paket yöneticisi paketleri bulamaz.

🔥 10. İleri Seviye: Flame Graphs (Alev Grafikleri)

perf top anlık izleme için harikadır ama raporlamak zordur. Patronunuza “Bak burada yüzde 90 yazıyor” demek yerine, havalı ve renkli bir grafik göstermek isterseniz dünyaca ünlü Flame Graph (Brendan Gregg) tekniğini kullanmalısınız.

Mantık basittir:

1. perf record: Veriyi 10-20 saniye boyunca diske kaydet.
2. perf script: Kaydı okunabilir metne çevir.
3. FlameGraph.pl: Metni grafiğe çevir (SVG).

Grafiği Okumak (Width vs Height)

graph TD
    subgraph Logic["Flame Graph Mantığı"]
        direction TB
        root["root"] --> A["Function A"]
        root --> B["Function B"]
        A --> A1["Child A1"]
        A --> A2["Child A2"]
        
        style root stroke:#f96,stroke-width:2px,fill:transparent
        style A stroke:#ff9,stroke-width:2px,fill:transparent
        style A1 stroke:#f96,stroke-width:2px,fill:transparent
    end
    
    Info1["Ayakları Yere Basan Fonksiyonlar"] -- "Yükseklik = Stack Derinliği" --> Logic
    Info2["En Geniş Olan = En Suçlu Olan"] -- "Genişlik = CPU Vakti" --> Logic

Sonuçta oluşan grafik, fonksiyonların birbirini çağırma hiyerarşisini (Stack Depth) ve harcadığı zamanı (Width) gösterir.

• Yükseklik (Height): Kim kimi çağırdı? En tepedeki kuleler, en derin fonksiyon çağrılarıdır.
• Genişlik (Width): Toplam CPU vaktinin ne kadarını yiyor? En geniş bar, optimize etmeniz gereken yerdir. (X ekseni zaman değildir, alfabetiktir!)

🏙️ Analoji: New York Silüeti Flame Graph’a baktığınızda karşınızda bir şehir silüeti görmelisiniz.

• Gökdelenler (Uzun ve İnce): Derin çağrılar (Deep Stack) ama toplamda az vakit harcıyorlar. Zararsızdır.
• Fabrikalar (Alçak ve Geniş): Az derinlikte ama çok yer kaplıyorlar. İşlemcinin tüm vaktini bunlar yiyor. Balvaz (Balyoz) ile dalmanız gereken yer burasıdır.

🖥️ GUI Sevenlere: Hotspot Perl scriptleri ve SVG dosyalarıyla uğraşmak istemiyorsanız, KDAB tarafından geliştirilen Hotspot aracını deneyin. perf record ile aldığınız perf.data dosyasını içine atın, size interaktif, zoom yapılabilir bir Flame Graph sunsun.

🚀 11. Geleceğin Teknolojisi: eBPF

perf harikadır ama eski usul çalışır. Günümüzde eBPF (Extended Berkeley Packet Filter) teknolojisi, Kernel’ı durdurmadan, çok daha düşük maliyetle ve çok daha derinlemesine analiz yapabilmemizi sağlıyor. Eğer perf yetersiz kalırsa, bcc-tools veya bpftrace araçlarına (örneğin profile.py veya offcputime) göz atmanızın vakti gelmiştir. Ama o, başka bir yazının konusu…

🚦 Özet: Araç Seçim Rehberi (Cheat Sheet)

Kafalar karışmasın. Hangi durumda hangi aracı çekeceksiniz?

Belirti (Semptom)	Olası Sorun	Doğru Araç
CPU %0, Program Bekliyor	Network, Disk, Kilit (Lock)	strace (Kraldır)
CPU %100, Fan Sesi Var	Sonsuz Döngü, Hesaplama	perf (User Space)
CPU %3-5 ama yavaş	Karışık (Hem I/O Hem CPU)	İkisi de (strace -c + perf)
Memory Şişiyor	Memory Leak	valgrind, heaptrack

🔮 Bir Sonraki Adım: “Kayıp Parola”

Performans sorunlarını çözdük. İşlemciyle barıştık. Peki ya sorun performans değil de “Mantık” ise? Programınız çalışıyor, sizden bir parola istiyor, giriyorsunuz ve “Yanlış!” diyor. strace ile bakıyorsunuz, ne dosya okuyor ne ağa gidiyor. Sadece “Yanlış” diyor.

Parolayı neyle karşılaştırdı? Doğru parola neydi?

Bir sonraki yazıda, strace‘in bile göremediği User Space dünyasının en derinlerine iniyoruz. Kütüphane çağrılarını dinleyen, şifreleri havada kapan ve kapalı kutuları açan ajanı tanıyacağız.

🚀 Serinin Devam Yazısı: User Space Dedektifi: ltrace ile Kütüphane Çağrılarını (Library Calls) Yakalamak