Performa Linux

 (brendangregg.com)
3 poin oleh GN⁺ 2023-10-15 | 1 komentar | Bagikan ke WhatsApp
  • Halaman Linux Performance milik Brendan Gregg adalah hub tautan yang mengumpulkan materi observabilitas, analisis, benchmarking, dan tuning yang dibutuhkan saat mulai menyelidiki performa Linux di satu tempat
  • Alur alat utamanya berlanjut melalui perf, eBPF, bcc, bpftrace, Flame Graphs, sehingga bisa langsung mengakses mulai dari contoh perintah hingga alat tracing dan visualisasi
  • Materi dokumentasinya meluas ke tulisan analisis performa Netflix tahun 2015, tuning EC2, Linux load averages, frame pointers, contoh gdb, dan dua buku performa
  • Daftar presentasinya menyediakan jalur belajar sesuai situasi seperti gambaran umum 40 menit, tutorial alat 90 menit, analisis performa container, dan checklist SRE
  • Untuk memeriksa seberapa mutakhir tiap peta alat, lihat tahun di kanan bawah gambar, dan diagram terpadu tidak selengkap diagram individual lainnya

Hub materi performa dan peta alat

  • Halaman ini adalah hub tautan yang mengumpulkan materi performa Linux buatan Brendan Gregg
  • Gambar peta alat di sebelah kanan dibuat dengan font besar agar cocok untuk slide deck, dan formatnya juga bisa dicetak lalu ditempel di dinding kantor
  • Peta alat membagi pekerjaan performa Linux ke dalam area berikut
  • Untuk mengetahui seberapa terbaru tiap gambar, periksa tahun di kanan bawah
  • Diagram resolusi tinggi yang menggabungkan observabilitas, tuning performa statis, dan perf-tools/bcc juga disediakan secara terpisah
    • png
    • svg
    • Diagram terpadu ini tidak selengkap diagram individual lainnya

Alat utama yang bisa langsung diakses

  • perf: perf one-liners, contoh, dan materi visualisasi
  • eBPF tools: alat tracing BPF/bcc dan contohnya
  • perf-tools: kumpulan alat perf berbasis Ftrace
  • bcc: kumpulan alat performa BPF/bcc
  • bpftrace: kumpulan alat performa BPF/bpftrace
  • Flame Graphs: cara menggunakan Flame Graph dengan perf dan profiler lainnya

Dokumen dan materi pembelajaran

Artikel lanjutan tentang eBPF, ftrace, dan perf

Rekomendasi ceramah berdasarkan situasi

  • Linux Systems Performance, USENIX LISA 2019

    • Ringkasan 40 menit tentang performa sistem Linux dari 6 aspek: observabilitas, metodologi, benchmarking, profiling, tracing, dan tuning
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • Merangkum perubahan dan fitur terbaru Linux performance pada 2018 dalam keynote 20 menit
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • Tutorial 90 menit yang membahas observabilitas performa, benchmarking, tuning, tuning performa statis, alat dan metodologi tracing, serta demo langsung
    • youtube playlist, slideshare, PDF

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

    • Lebih berfokus pada tuning daripada observabilitas performa, mencakup latar belakang Netflix, tipe dan fitur instance AWS EC2, Linux kernel tunables, serta observabilitas
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Membahas cara menemukan lokasi bottleneck antara host dan container, melakukan profiling aplikasi container, dan menyelami kernel lebih dalam
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Membahas masalah yang sering muncul pada alat sistem Linux, metrik, statistik, visualisasi, overhead pengukuran, dan benchmark, beserta saran “What You Can Do”
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • Berfokus pada profiling CPU dan cara kerja Flame Graphs, termasuk masalah stack traces dan symbols saat melakukan profiling perf_events, Java, Node.js, VM, dan container
    • 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

    • Membahas enhanced BPF yang ditambahkan ke seri Linux 4.x, yaitu eBPF, untuk analisis performa, observabilitas, dan debugging
    • Front-end-nya adalah proyek open source bcc yang menyediakan antarmuka BPF dan kumpulan alat
    • youtube, slideshare, PDF

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

    • Membahas alat ftrace dan perf_events, serta perf-tools yang terutama menggunakan ftrace
    • ftrace diperkenalkan sebagai tracer yang telah tertanam di kernel Linux selama bertahun-tahun tetapi hampir tidak pernah ditemukan
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Pada bagian akhir mencakup checklist untuk Linux incident performance response, sehingga juga bisa berguna untuk analisis performa Linux yang mendesak
    • youtube, usenix, slideshare, PDF

Materi rekomendasi eksternal

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-15
Pendapat Hacker News

  • Saya memakai tuned di VPS Debian/Ubuntu yang menjalankan aplikasi real-time, dan sejauh ini bekerja cukup baik
    Lebih sederhana daripada mengubah langsung parameter kernel, yaitu pengaturan sysctl atau kernel tunables
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • Kami juga memakai Tuned untuk workload SAP, dan sangat menyukainya

  • Saya tidak tahu Brendan Gregg sekarang ada di Intel
    https://en.wikipedia.org/wiki/Brendan_Gregg
    Ia juga tokoh dalam video viral Shouting in the Data Center
    https://www.youtube.com/watch?v=tDacjrSCeq4
    Benar-benar jenius

  • Patut dicatat bahwa hampir semua yang dibahas dalam artikel asli berkaitan dengan throughput/bandwidth jaringan, disk, I/O lain, dan CPU, bukan latensi
    Bisa dimengerti, karena bagi banyak orang performa berarti throughput. Namun ada kasus ketika latensi jauh lebih penting daripada throughput, dan untuk men-tuning latensi di Linux dibutuhkan kumpulan alat yang berbeda

    • Ini poin yang cukup valid. Mengurangi latensi juga jauh lebih sulit daripada meningkatkan throughput[1], jadi sering kali penting untuk memperhatikan latensi
      Sumbu lain yang bisa dioptimalkan orang adalah performa per watt, tetapi saya tidak akan membahasnya panjang di sini
      Ada juga kasus ketika optimasi throughput sekaligus menjadi optimasi latensi. Misalnya, jika lebih banyak proses bisa ditempatkan dalam satu box, jarak rata-rata antara proses dan pihak yang diajak berkomunikasi berkurang, sehingga latensi rata-rata juga turun
      Hal yang sangat jelas saat mengoptimalkan latensi adalah meningkatkan throughput secukupnya agar tidak menjadi bottleneck
      Jika mengoptimalkan latensi secara agresif, rasanya tuning Linux itu sendiri tidak terlalu banyak. Mungkin saya keliru, tetapi secara umum yang utama tampaknya adalah pinning core, eksekusi tickless, networking di user space, serta penyesuaian sisi hardware seperti ukuran page, SMT, pengaturan hemat daya, dan pilihan hardware
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • Tampaknya lebih tepat menyebutnya throughput daripada bandwidth. Maknanya mirip, tetapi kontras antara throughput dan latensi sudah lama dibahas
      Kadang keduanya bisa ditingkatkan, tetapi biasanya ada trade-off
    • Saya penasaran alat atau materi apa yang direkomendasikan terkait tuning latensi
    • Jika tujuannya mengurangi latensi demi karakteristik real-time sistem, besar kemungkinan distribusi Linux standar tidak akan menjadi sistem yang memuaskan, sebanyak apa pun knob yang diutak-atik

  • Menunggu juga strategi yang bagus
    Mulai Linux 6.5, scheduler memahami bahwa ketika satu “core” SMT sedang sibuk, menempatkan sesuatu di “core” lain belum tentu pilihan terbaik. Dalam praktiknya, itu lebih mirip satu core dengan biaya context switch yang sangat rendah
    Berkat ini, pekerjaan yang sangat paralel terasa lebih responsif, dan terlihat juga pada grafik penggunaan CPU
    Hasil bisa berbeda karena koherensi cache dan masalah NUMA

    • Di kernel sebelumnya pun, cukup dengan menonaktifkan SMT bisa mendapatkan efek yang lebih responsif, sekaligus mencegah beberapa serangan side-channel dan meningkatkan efisiensi daya

  • Artikel terkait:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - Januari 2017, 64 komentar
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - Agustus 2014, 22 komentar

  • Jika seseorang ingin mengubah parameter tunable tertentu tetapi tidak bisa menjelaskan mengapa perubahan itu akan menghasilkan efek yang diinginkan, atau mengapa sejak awal nilainya disetel seperti itu, saya tidak akan mengizinkannya diubah di lingkungan produksi
    Ini layak disebut “parameter tunable Chesterton”

    • Sekalipun bisa menjelaskan alasan hipotetis, bukankah tetap bisa melakukan benchmark di luar lingkungan produksi?

  • Mengingat pekerjaan Brendan di eBPF, materi ini saya anggap sebagai cara untuk lebih mudah memantau dan mengevaluasi berbagai situasi performa
    Penyesuaian dan tuning memiliki trade-off, dan biasanya ketika satu hal dioptimalkan, sisi lain sering dirugikan
    Sebagai tambahan, btop sangat berguna sebagai viewer performa dan beban sistem TUI all-in-one pengganti glances. Saya juga penasaran seberapa banyak developer memanfaatkannya, dan apakah ada motivasi untuk membuat alat monitoring TUI yang lebih baik
    Saat masuk ke server, hal pertama yang saya lakukan adalah menjalankan tmux dan mengalokasikan satu window untuk btop

  • Bagi saya, “tuning” performa Linux sama dengan menonaktifkan mitigasi Spectre/Meltdown
    Dalam kasus ini, node komputasi berjalan di dalam VPC tanpa akses internet, jadi risikonya tampak cukup rendah

    • Tergantung CPU yang digunakan. Di Zen 4, penonaktifan mitigasi tidak didukung dan menyebabkan bug atau crash
      Sepertinya crash spesifik itu sudah diperbaiki, tetapi tetap tidak saya rekomendasikan. CPU terbaru AMD dan Intel dirancang untuk berjalan setidaknya dengan mitigasi dasar diaktifkan

  • Sudah saya bookmark. Sepertinya akan berguna untuk pekerjaan yang sedang saya kerjakan dalam waktu dekat
    Saya belum membaca semua slidenya, tetapi penasaran apakah ada yang pernah melihat peningkatan kinerja yang berarti dari opsi build kernel
    Dulu saat memakai Gentoo dan mengutak-atik build flag, saya biasa mengubah Makefile kernel untuk memakai -O3 dan menerapkan patch -march=native. Kalau dipikir-pikir, berdasarkan benchmark Phoronix, itu tampaknya justru merugikan di berbagai workload; saya penasaran apakah ada yang pernah melihat contoh sebaliknya

  • Situs yang bagus. Ia cenderung merangkum kinerja Linux, baik untuk tuning maupun monitoring, sampai membuat saya menarik napas panjang
    Topik ini dalam, dan jenis alat observasinya juga sangat banyak. Setidaknya uptime, dmesg, dan iostat harus dipahami secara mendalam. Alat-alat ini meninjau berbagai aspek sistem seperti beban, memori, CPU, dan memberi petunjuk pertama untuk diagnosis kondisi. Ini halaman 1 dari 100 halaman checklist “coba kita lihat dulu” versi saya
    Dalam metodologi analisis kinerja, benchmark yang cermat dianjurkan untuk mengevaluasi perilaku sistem dan karakteristik workload secara menyeluruh. Bandingkan skenario sebelum dan sesudah perubahan; lakukan perubahan kecil terlebih dahulu, lalu gabungkan secara bertahap hal-hal yang dinilai memberi manfaat. Lingkungan lab dan produksi tidak akan pernah berperilaku sama persis
    Dari sini mulai rumit. CPU profiling dengan alat seperti perf dan visualisasi seperti flame graph memungkinkan analisis aktivitas CPU yang terarah, dan dengan tambahan pelacakan event hardware, efisiensi komputasi bisa dioptimalkan. Kita perlu tahu lebih dari sekadar “ini masalah aplikasi, sebelum rilis terbaru tim developer masih baik-baik saja”
    Sebagai administrator, saat berbicara dengan developer, Anda akan membutuhkan alat seperti ftrace dan BPF di Linux. Keduanya bisa melacak eksekusi fungsi kernel dan system call secara terperinci, sehingga penting untuk troubleshooting dan optimasi kinerja. Sebaliknya, jika Anda developer, Anda mungkin perlu memverifikasi intuisi administrator. Seperti kata pepatah: percaya, tetapi tetap verifikasi
    Jika itu kode Anda sendiri, Anda perlu mengenal BPF. BPF tidak hanya memungkinkan tracing internal kernel yang efisien, tetapi juga mendorong pengembangan alat profiling kustom tingkat lanjut melalui bcc dan bpftrace, sehingga memberi pandangan yang lebih dalam terhadap kinerja sistem
    Terakhir, ini benar-benar sulit. Tuning berarti menyesuaikan begitu banyak komponen sistem dan parameter kernel, mulai dari CPU dan memori hingga pengaturan jaringan, untuk mengoptimalkan kinerja dan keandalan pada berbagai workload. Atau ya, salahkan saja jaringan
    Dalam praktiknya, yang dibutuhkan adalah sikap yang baik terhadap manajemen perubahan. Mengejar perubahan kode atau parameter kernel bisa membuat semua orang kewalahan, dan dalam situasi dikejar waktu, tekanan akan makin memperbesar kemungkinan kesalahan manusia