Linux Performansı

 (brendangregg.com)
3 puan yazan GN⁺ 2023-10-15 | 1 yorum | WhatsApp'ta paylaş
  • Brendan Gregg’in Linux Performance sayfası, Linux performans incelemesine başlarken gereken gözlemlenebilirlik, analiz, kıyaslama ve ayarlama kaynaklarını tek yerde toplayan bir bağlantı merkezidir
  • Temel araç akışı perf, eBPF, bcc, bpftrace, Flame Graphs şeklinde ilerler; komut örneklerinden izleme araçlarına ve görselleştirmeye kadar doğrudan erişim sunar
  • Dokümantasyon kaynakları Netflix’in 2015 tarihli performans analizi yazısı, EC2 ayarlama, Linux load averages, frame pointers, gdb örnekleri ve iki performans kitabıyla genişler
  • Konuşma listesi; 40 dakikalık genel bakış, 90 dakikalık araç eğitimi, konteyner performans analizi ve SRE kontrol listesi gibi duruma göre öğrenme yolları sunar
  • Her araç haritasının güncelliği, görselin sağ altındaki yıla bakılarak kontrol edilmeli; birleşik diyagram ise diğer tekil diyagramlar kadar eksiksiz değildir

Performans kaynak merkezi ve araç haritası

  • Bu sayfa, Brendan Gregg’in hazırladığı Linux performance kaynaklarını bir araya getiren bir bağlantı merkezidir
  • Sağdaki araç haritası görseli, slayt destelerine uygun olacak şekilde büyük yazı tipiyle hazırlanmıştır; çıktısı alınıp ofis duvarına asılabilecek formattadır
  • Araç haritası, Linux performans çalışmalarını şu alanlara ayırarak gösterir
  • Her görselin ne kadar güncel olduğunu anlamak için sağ alttaki yıl kontrol edilmelidir
  • Gözlemlenebilirlik, statik performans ayarlama ve perf-tools/bcc’yi birleştiren yüksek çözünürlüklü bir diyagram da ayrıca sunulur
    • png
    • svg
    • Bu birleşik diyagram, diğer tekil diyagramlar kadar eksiksiz değildir

Doğrudan erişilebilen başlıca araçlar

  • perf: perf one-liners, örnekler, görselleştirme materyalleri
  • eBPF tools: BPF/bcc izleme araçları ve örnekler
  • perf-tools: Ftrace tabanlı perf araç seti
  • bcc: BPF/bcc performans araç seti
  • bpftrace: BPF/bpftrace performans araç seti
  • Flame Graphs: perf ve diğer profiler’larla Flame Graph kullanımı

Dokümantasyon ve öğrenme kaynakları

eBPF, ftrace, perf derinlemesine yazıları

Duruma göre önerilen konuşmalar

  • Linux Systems Performance, USENIX LISA 2019

    • 40 dakika içinde Linux sistem performansını gözlemlenebilirlik, metodoloji, benchmark, profilleme, izleme ve tuning olmak üzere 6 açıdan özetler
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • 2018’de Linux performance alanındaki son değişiklikleri ve özellikleri 20 dakikalık keynote olarak özetler
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • 90 dakikalık bir tutorial olarak performans gözlemlenebilirliği, benchmark, tuning, statik performans tuning’i, izleme araçları ve metodolojileri ile canlı demoları kapsar
    • youtube playlist, slideshare, PDF

  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • Performans gözlemlenebilirliğinden çok tuninge odaklanır; Netflix arka planını, AWS EC2 instance tiplerini ve özelliklerini, Linux kernel tunables’larını ve gözlemlenebilirliği ele alır
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Darboğazın host’ta mı container’da mı olduğunu bulmayı, container uygulamalarını profillemeyi ve kernel’e daha derine inmeyi ele alır
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Linux sistem araçlarında, metriklerde, istatistiklerde, görselleştirmelerde, ölçüm overhead’inde ve benchmark’larda sık görülen sorunları ve “What You Can Do” önerilerini birlikte ele alır
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • CPU profillemeye ve Flame Graphs’in nasıl çalıştığına odaklanır; perf_events özellikleri ile Java, Node.js, VM ve container profillemede stack traces ve symbols sorunlarını içerir
    • youtube, slideshare

  • Give me 15 minutes and I'll change your view of Linux tracing, LISA 2016

  • Performance analysis superpowers with Linux eBPF, O’Reilly Velocity 2017

    • Linux 4.x serisine eklenen enhanced BPF’yi, yani eBPF’yi performans analizi, gözlemlenebilirlik ve debugging için kullanmayı ele alır
    • Frontend, BPF arayüzü ve araç seti sağlayan açık kaynak proje bcc’dir
    • youtube, slideshare, PDF

  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • ftrace ve perf_events araçlarını, ayrıca ağırlıklı olarak ftrace kullanan perf-tools’u ele alır
    • ftrace, Linux kernel’inde uzun yıllardır yerleşik olmasına rağmen pek keşfedilmemiş bir tracer olarak tanıtılır
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Son bölümünde Linux incident performance response için bir checklist içerir; acil Linux performans analizi için de yararlı olabilir
    • youtube, usenix, slideshare, PDF

Dışarıdan Önerilen Kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-15
Hacker News yorumları

  • Gerçek zamanlı uygulamalar çalıştıran Debian/Ubuntu VPS’lerde tuned kullanıyorum ve oldukça iyi çalışıyor
    Çekirdek parametrelerini, yani sysctl ayarlarını veya kernel tunable’larını doğrudan değiştirmekten daha basit
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • SAP iş yükleri için de Tuned kullanıyoruz ve çok memnunuz

  • Brendan Gregg’in artık Intel’de olduğunu bilmiyordum
    https://en.wikipedia.org/wiki/Brendan_Gregg
    Viral video Shouting in the Data Center’ın da baş kahramanı
    https://www.youtube.com/watch?v=tDacjrSCeq4
    Gerçek bir dâhi

  • Orijinal metinde ele alınanların neredeyse tamamının gecikme süresi değil; ağ, disk, diğer giriş/çıkışlar ve CPU’nun işleme kapasitesi/bant genişliği ile ilgili olduğunu belirtmekte fayda var
    Birçok kişi için performans işleme kapasitesi anlamına geliyor, bunu anlıyorum. Ancak gecikme süresinin işleme kapasitesinden çok daha önemli olduğu durumlar da var ve Linux’ta gecikme süresini ayarlamak için farklı bir araç seti gerekiyor

    • Oldukça yerinde bir tespit. İşleme kapasitesini artırmaktansa gecikme süresini azaltmak çok daha zor olduğundan[1], gecikmeye dikkat etmek çoğu zaman önemli
      İnsanların optimize edebileceği başka bir eksen de watt başına performans, ama burada uzatmayacağım
      İşleme kapasitesi optimizasyonunun aynı zamanda gecikme süresi optimizasyonu olduğu durumlar da var. Örneğin bir kutuya daha fazla süreç sığdırabiliyorsanız, süreç ile iletişim kurduğu taraf arasındaki ortalama mesafe azalır ve ortalama gecikme de düşer
      Gecikme süresini optimize ederken çok bariz yapılacak şey, işleme kapasitesini darboğaz olmayacak kadar artırmaktır
      Gecikmeyi agresif biçimde optimize edecekseniz Linux tuning tarafında yapılacak çok şey yok gibi geliyor. Yanılıyor olabilirim ama genel olarak çekirdek sabitleme, tickless çalışma, kullanıcı alanı ağ yığını ve sayfa boyutu·SMT·güç tasarrufu ayarları·donanım seçimi gibi donanım tarafı ayarlar ön planda gibi
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • bandwidth yerine throughput demek daha doğru görünüyor. Anlamları benzer ama işleme kapasitesi ile gecikme süresi karşıtlığı uzun zamandır tartışılıyor
      Bazen ikisini de iyileştirebilirsiniz, ama genelde bir trade-off söz konusu
    • Gecikme süresi ayarlama konusunda önerebileceğiniz araçlar veya kaynaklar var mı merak ediyorum
    • Hedefiniz sistemin gerçek zamanlı özellikleri için gecikmeyi azaltmaksa, standart bir Linux dağıtımında ne kadar çok düğmeyle oynarsanız oynayın tatmin edici bir sisteme ulaşamama ihtimaliniz yüksek

  • Beklemek de iyi bir strateji
    Linux 6.5’ten itibaren scheduler, bir SMT “çekirdeği” meşgulken işi başka bir “çekirdeğe” yerleştirmenin her zaman en iyi seçenek olmayabileceğini anlıyor. Çünkü pratikte bu, context switch maliyeti çok düşük olan tek bir çekirdeğe daha yakın
    Bu sayede yüksek paralelliğe sahip işler fark edilir biçimde daha hızlı tepki verir hale geldi ve bu CPU kullanım grafiğinde de görünüyor
    Önbellek tutarlılığı ve NUMA sorunları nedeniyle sonuçlar değişebilir

    • Önceki çekirdeklerde de yalnızca SMT’yi devre dışı bırakarak daha hızlı tepki veren bir etki elde edilebilir; ayrıca bazı side-channel saldırıları da engellenir ve güç verimliliği artar

  • İlgili yazılar:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - Ocak 2017, 64 yorum
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - Ağustos 2014, 22 yorum

  • Bir tunable parametreyi değiştirmek istiyor ama bu değişikliğin neden istediği etkiyi yaratacağını, hatta başta neden o değere ayarlandığını açıklayamıyorsa, üretim ortamında değiştirmesine izin vermem
    Buna “Chesterton’ın tunable parametresi” denebilir

    • Varsayımsal bir neden açıklayabilsen bile, zaten üretim ortamı dışında benchmark yapamaz mısın?

  • Brendan’ın eBPF çalışmalarını düşününce, bu materyali çeşitli performans durumlarını daha kolay izleme ve değerlendirme yolu olarak görüyorum
    Ayarlama ve tuning’de trade-off’lar var; genelde bir şeyi optimize ettiğinizde diğer tarafta kayıp yaşanıyor
    Ek olarak btop, glances’ın yerine geçen hepsi bir arada bir TUI sistem performansı ve yük görüntüleyicisi olarak çok faydalı oldu. Geliştiricilerin bundan ne kadar yararlandığını ve daha iyi TUI izleme araçları yapma motivasyonları olup olmadığını da merak ediyorum
    Bir sunucuya girdiğimde ilk iş tmux’u açıp bir pencereyi btop’a ayırıyorum

  • Benim için Linux performans “tuning”i, Spectre/Meltdown azaltma önlemlerini devre dışı bırakmak demek
    Bu durumda hesaplama düğümü internete erişimi olmayan bir VPC içinde çalıştığından risk oldukça düşük görünüyor

    • Hangi CPU’yu kullandığınıza bağlı. Zen 4’te azaltma önlemlerini devre dışı bırakmak desteklenmiyordu ve bug’lara ya da crash’lere yol açıyordu
      O belirli crash’i düzeltmişler gibi, ama yine de önermem. AMD ve Intel’in en yeni CPU’ları en azından temel azaltma önlemleri açık halde çalışacak şekilde tasarlanmış durumda

  • Yer imlerine ekledim. Yakında üzerinde çalıştığım işte işe yarayacak gibi görünüyor
    Slaytların tamamını henüz okumadım ama kernel build seçenekleriyle anlamlı bir performans artışı gören olup olmadığını merak ediyorum
    Eskiden Gentoo kullanıp build flag’leriyle oynarken kernel Makefile’ını değiştirip -O3 kullanır ve -march=native yamasını uygulardım. Geriye dönüp bakınca Phoronix benchmark’larına göre çeşitli iş yüklerinde bunun daha çok zararlı olduğu görülüyor; bunun tersine örnek gören oldu mu merak ediyorum

  • Güzel bir site. Linux performansını, ister tuning ister monitoring olsun, özetleme eğilimi olduğu için derin bir nefes aldırıyor
    Bu konu derin ve gözlem araçlarının türü de çok fazla. En azından uptime, dmesg, iostat araçlarını derinlemesine bilmek gerekir. Bu araçlar yük, bellek, CPU gibi sistemin çeşitli yönlerine göz atarak durum teşhisi için ilk ipuçlarını verir. Benim “bir bakalım” kontrol listemin 100 sayfasından 1. sayfası
    Performans analizi metodolojisinde, sistem davranışını ve iş yükü özelliklerini bütüncül olarak değerlendirmek için dikkatli benchmark’lar önerilir. Değişiklik öncesi ve sonrası senaryoları karşılaştırmalı, önce küçük değişiklikler yapıp faydalı olduğuna karar verilenleri kademeli olarak birleştirmelisiniz. Laboratuvar ve üretim ortamı asla aynı şekilde davranmaz
    İş buradan itibaren zorlaşıyor. perf gibi araçlarla yapılan CPU profiling ve flame graph gibi görselleştirmeler, CPU etkinliğini hedefli biçimde analiz etmeyi sağlar; donanım olay izleme de eklenince hesaplama verimliliği optimize edilebilir. “Sorun uygulamada, geliştirme ekibinin son sürümünden önce iyiydi” seviyesinden fazlasını bilmek gerekir
    Yönetici olarak geliştiricilerle konuşurken Linux’ta ftrace ve BPF gibi araçlara ihtiyaç duyarsınız. Kernel fonksiyon yürütmesini ve sistem çağrılarını ayrıntılı izleyebildiği için sorun giderme ve performans optimizasyonunda önemlidir. Tersine, geliştiriciyseniz yöneticinin sezgisini doğrulamanız gerekebilir. Söylendiği gibi, güven ama doğrula
    Kendi kodunuzsa BPF’yi bilmelisiniz. BPF yalnızca kernel içinde verimli izlemeyi mümkün kılmakla kalmaz; bcc ve bpftrace üzerinden gelişmiş, özel profiling araçlarının geliştirilmesini de destekler ve sistem performansına daha derin bakmanızı sağlar
    Son olarak, bu gerçekten zor. Tuning; CPU ve bellekten ağ ayarlarına kadar sayısız sistem bileşenini ve kernel parametresini ayarlayarak farklı iş yüklerinde performansı ve güvenilirliği optimize etme işidir. Ya da suçu ağa atabilirsiniz
    Gerçekte ise değişiklik yönetimine karşı iyi bir tutuma ihtiyaç vardır. Kodun ya da kernel parametrelerinin peşine düşmek herkesi bunaltabilir; zaman baskısı altında ise baskı, insan hatası olasılığını daha da artırır