Linux sunucularda yoğun işlem sırasında CPU zamanının nerede harcadığını anlamak için perf top ilk araçlardan biri olarak benim tercihimdir. Canlı, fonksiyon bazlı bir görünüm sunar fakat varsayılan olarak kullanıcı alanı ve çekirdek alanı örneklerini karıştırır. Bu durumda, yavaşlamanın uygulama kodundan mı yoksa çekirdeğin derinliklerinden mi kaynaklandığını belirlemek zorlaşır. -u ve -k bayraklarıyla bu iki alanı ayırarak sadece ihtiyacım olan odak noktasına odaklanabilirim.
Kullanıcı Alanı Fonksiyonlarını Sadece Örneklemek İçin -u Kullanımı
Bazen darboğazın uygulama kendi içinde olduğunu şüphelenirim — belki bir Java servisi, bir Python betiği veya özel bir ikili dosya. Bu gibi durumlarda, kullanıcı alanı fonksiyonlarını sadece örneklemek için perf top -u komutunu çalıştırırım. Bu sayede çekirdek aktivitesi filtrelenir ve çalıştırılabilir dosyam veya paylaşılan kütüphanelerimdeki hangi fonksiyonların en çok CPU tükettiğini görürüm.
Örneğin, yüksek trafiğe sahip bir web uygulaması çalıştıran bir sunucuda şöyle bir çıktı alabilirim:
# perf top -u
Samples: 12K of event 'cpu-clock', Event count (approx): 12000000
Overhead Command Shared Object Symbol
.. . . .
5.23% java libjvm.so [.] InterpretBytecode
4.87% java libjava.so [.] Java_java_lang_String_indexOf
3.91% java [unknown] [.] 0x00007f8d12345678
2.15% mysqld mysqld [.] sql_parse
1.89% nginx nginx [.] ngx_http_header_filterBu çıktı, kullanıcı alanı CPU'nun %10'unun üzerinde JVM bytecode yorumlaması ve string işlemlerinde harcadığını gösterir — bu da uygulama mantığına veya JVM ayarlarına bakmam gerektiği bir ipucu olur. Daha önce Java servislerinde yüksek CPU kullanımını araştırırken bu yaklaşımı kullandım, JVM izlemeyle ilgili yazımda da bahsetmiştim.
Çekirdek Alanı Aktivitesini İzole Etmek İçin -k Kullanımı
Bazı zamanlar sorun daha sistemik hisseder — yüksek kesme oranları, yavaş disk G/İ veya belirli bir süreçle korelasyonu olmayan açıksız sistem yükü. İşte bu gibi durumlarda perf top -k ile sadece çekirdek fonksiyonlarına bakarak kullanıcı alanı gürültüsünü çıkarıp çekirdeğin kendi döngülerini ne kadar yorduğunu görürüm.
Tipik çekirdek-only görünümü şöyle olabilir:
# perf top -k
Samples: 8K of event 'cpu-clock', Event count (approx): 8000000
Overhead Command Shared Object Symbol
.. . . .
6.42% [kernel] [k] [.] _raw_spin_lock_irqsave
5.18% [kernel] [k] [.] __alloc_pages_nodemask
4.03% [kernel] [k] [.] ext4_journal_start_sb
3.71% [kernel] [k] [.] tcp_v4_rcv
2.89% [kernel] [k] [.] __x64_sys_writeBurada spin kilitleme ve bellek ayırma işlemlerinde önemli zaman harcadığını görürüm — yüksek eşzamanlılık altında kilit çakışması veya bellek baskısının işaretleri olabilir. _raw_spin_lock_irqsave'de çok zaman görüyorsam, sürücüler veya strese açık alt sistemlerde kilitleme desenlerine bakmam gerektiğini anlarım. Benzer şekilde, __alloc_pages_nodemask'te yüksek oran bellek baskısı veya parçalanması işaret edebilir.
Daha Derin İçgörü İçin Görünümleri Birleştirme
Gerçek güç her iki görünümü birlikte kullanmakta yatar. Çoğu zaman önce perf top -u ile çalıştırarak sıcak noktanın kullanıcı alanı mı yoksa değil mi olduğunu kontrol ederim. Tek bir fonksiyon baskın değilse (düz görünürse) -k ile geçerek çekirdek tarafındaki sorunları araarım. Bazen sorun etkileşimden kaynaklanır — örneğin kullanıcı alanı süreci sık sistem çağrısı yaparak pahalı çekirdek yollarını tetikler.
Örneğin, perf top -u bir veritabanı kullanıcı sürecinde yüksek CPU gösterirken, perf top -k de ext4_journal_start_sb'de çok zaman gösteriyorsa, veritabanının günlük taahhütleri için bekleme yaptiğini anlarım — bu da mount seçeneklerini, disk hızını veya iş yükü özelliklerini kontrol etmemi gerekebilir.
Pratik İpuçları ve Dikkat Edilecek Noktalar
- perf top, çekirdek sembolleri ve sayaçlara erişim için root veya CAP_SYS_ADMIN yetkisi gerektirir.
- KASLR etkin sistemlerde sembol çözümlemesi /proc/kallsyms'e erişim sağlanmadığı sürece daha az doğru olabilir.
- Çıktıda [unknown] çok görünüyorsa, daha iyi çözümleme için hata ayıklama sembollerini kurmayı düşünebilirim (örneğin, linux-image-*-dbg paketleri).
- Varsayılan örnekleme hızı 4000 Hz'dir; daha yüksek çözümleme veya daha düşük overhead gerekiyorsa -c veya -f bayraklarıyla ayarlanabilir.
- perf top bulgularını vmstat, iostat veya pidstat gibi diğer araçlarla ilişkilendirmek her zaman iyi bir uygulamadır; böylece tam bir analiz resmi elde edilir.
perf top -u ve -k gibi basit bayraklar, aracı genel bir CPU izleyiciden odaklı bir tanı aracına dönüştürür. Gecelik duyarlı bir servisi ayarlarken veya gizemli bir sistem yükü tırmanışını izlerken, kullanıcı ve çekirdek alanını fonksiyon seviyesinde izole edebilmek benim için saatlerce tahmin çalışmasını önlemiş oldu.
Kapak görseli: Kevin Buehner · CC0 (Openverse / kamu malı) · https://www.thingiverse.com/thing:2655875