Hiệu năng Linux

 (brendangregg.com)
3 điểm bởi GN⁺ 2023-10-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trang Linux Performance của Brendan Gregg là một trung tâm liên kết tập hợp tài liệu về quan sát, phân tích, benchmark và tinh chỉnh cần thiết khi bắt đầu điều tra hiệu năng Linux
  • Luồng công cụ cốt lõi đi từ perf, eBPF, bcc, bpftrace đến Flame Graphs, cho phép truy cập ngay từ ví dụ lệnh tới công cụ truy vết và trực quan hóa
  • Tài liệu mở rộng sang bài viết phân tích hiệu năng năm 2015 của Netflix, tinh chỉnh EC2, Linux load averages, frame pointers, ví dụ gdb và hai cuốn sách về hiệu năng
  • Danh sách bài giảng cung cấp lộ trình học theo từng tình huống như tổng quan 40 phút, hướng dẫn công cụ 90 phút, phân tích hiệu năng container và checklist SRE
  • Với mỗi sơ đồ công cụ, cần kiểm tra năm ở góc dưới bên phải của hình để biết độ mới; sơ đồ tổng hợp không đầy đủ bằng các sơ đồ riêng lẻ khác

Trung tâm tài liệu hiệu năng và sơ đồ công cụ

  • Trang này là một trung tâm liên kết tập hợp tài liệu về Linux performance do Brendan Gregg tạo ra
  • Hình sơ đồ công cụ ở bên phải được làm với cỡ chữ lớn để phù hợp với slide deck, và có thể in ra để dán lên tường văn phòng
  • Sơ đồ công cụ chia công việc hiệu năng Linux thành các mảng sau
  • Để biết từng hình còn mới đến mức nào, cần kiểm tra năm ở góc dưới bên phải
  • Ngoài ra còn có sơ đồ độ phân giải cao gộp observability, static performance tuning và perf-tools/bcc
    • png
    • svg
    • Sơ đồ tổng hợp này không đầy đủ bằng các sơ đồ riêng lẻ khác

Các công cụ chính có thể truy cập ngay

  • perf: perf one-liners, ví dụ và tài liệu trực quan hóa
  • eBPF tools: công cụ truy vết BPF/bcc và ví dụ
  • perf-tools: bộ công cụ perf dựa trên Ftrace
  • bcc: bộ công cụ hiệu năng BPF/bcc
  • bpftrace: bộ công cụ hiệu năng BPF/bpftrace
  • Flame Graphs: cách dùng Flame Graph với perf và các profiler khác

Tài liệu và nguồn học tập

Bài viết chuyên sâu về eBPF, ftrace, perf

Các bài thuyết trình được đề xuất theo từng tình huống

  • Linux Systems Performance, USENIX LISA 2019

    • Tóm tắt hiệu năng hệ thống Linux trong 40 phút qua 6 khía cạnh: observability, methodology, benchmarking, profiling, tracing và tuning
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • Tóm tắt trong bài keynote 20 phút về những thay đổi và tính năng mới của Linux performance trong năm 2018
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • Bài hướng dẫn 90 phút bao quát observability hiệu năng, benchmarking, tuning, static performance tuning, công cụ và phương pháp tracing, cùng demo trực tiếp
    • youtube playlist, slideshare, PDF

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

    • Tập trung vào tuning hơn là observability hiệu năng, đồng thời đề cập đến bối cảnh của Netflix, các loại và tính năng của AWS EC2 instance, Linux kernel tunables và observability
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Trình bày cách tìm vị trí nút thắt cổ chai giữa host và container, profiling ứng dụng container và đi sâu hơn vào kernel
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Đề cập đến các vấn đề thường gặp trong công cụ hệ thống Linux, chỉ số, thống kê, trực quan hóa, overhead đo lường và benchmark, cùng lời khuyên “What You Can Do”
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • Tập trung vào CPU profiling và cách Flame Graphs hoạt động, đồng thời bao gồm các vấn đề về stack traces và symbols khi profiling với perf_events trên Java, Node.js, VM và 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

    • Trình bày cách tận dụng enhanced BPF được thêm vào dòng Linux 4.x, tức eBPF, cho phân tích hiệu năng, observability và debugging
    • Frontend là dự án mã nguồn mở bcc, cung cấp giao diện BPF và bộ công cụ
    • youtube, slideshare, PDF

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

    • Đề cập đến công cụ ftrace và perf_events, cùng perf-tools chủ yếu dùng ftrace
    • ftrace được giới thiệu là một tracer đã được tích hợp trong Linux kernel suốt nhiều năm nhưng hầu như chưa được khám phá
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Ở phần sau có checklist cho incident performance response trên Linux, nên cũng có thể hữu ích cho các tình huống phân tích hiệu năng Linux khẩn cấp
    • youtube, usenix, slideshare, PDF

Tài liệu tham khảo bên ngoài

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-15
Ý kiến trên Hacker News

  • Tôi đang dùng tuned trên Debian/Ubuntu VPS chạy ứng dụng thời gian thực, và nó hoạt động khá tốt
    Đơn giản hơn việc tự thay đổi các tham số kernel, tức cấu hình sysctl hay các tunable của kernel
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • Chúng tôi cũng dùng Tuned cho workload SAP và rất hài lòng

  • Tôi không biết Brendan Gregg giờ đang ở Intel
    https://en.wikipedia.org/wiki/Brendan_Gregg
    Ông cũng là nhân vật chính trong video viral Shouting in the Data Center
    https://www.youtube.com/watch?v=tDacjrSCeq4
    Đúng là thiên tài

  • Cũng đáng lưu ý rằng gần như mọi nội dung được bàn trong bài gốc là về throughput/băng thông của mạng, đĩa, I/O khác và CPU, chứ không phải độ trễ
    Với nhiều người, hiệu năng nghĩa là throughput nên cũng dễ hiểu. Nhưng có những trường hợp độ trễ quan trọng hơn throughput rất nhiều, và để tune độ trễ trên Linux thì cần một bộ công cụ khác

    • Nhận xét khá hợp lý. Giảm độ trễ cũng khó hơn nhiều so với tăng throughput[1], nên việc quan tâm đến độ trễ thường rất quan trọng
      Một trục khác mà mọi người có thể tối ưu là hiệu năng trên mỗi watt, nhưng ở đây tôi sẽ không nói dài
      Có những trường hợp tối ưu throughput cũng đồng nghĩa với tối ưu độ trễ. Ví dụ nếu có thể đưa nhiều process hơn lên cùng một máy, khoảng cách trung bình giữa process và đối tượng giao tiếp sẽ giảm, từ đó độ trễ trung bình cũng thấp hơn
      Một việc rất hiển nhiên khi tối ưu độ trễ là tăng throughput đủ để nó không trở thành nút thắt cổ chai
      Nếu tối ưu độ trễ một cách quyết liệt, tôi có cảm giác bản thân phần tuning Linux không nhiều. Có thể tôi sai, nhưng nhìn chung có vẻ trọng tâm là cố định core, chạy tickless, networking ở user space, và các điều chỉnh phía phần cứng như kích thước page, SMT, thiết lập tiết kiệm điện, lựa chọn phần cứng
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • Có lẽ gọi là throughput thì đúng hơn là bandwidth. Nghĩa thì tương tự, nhưng sự đối lập giữa throughput và độ trễ đã được thảo luận từ lâu
      Đôi khi có thể cải thiện cả hai, nhưng thường thì đó là một sự đánh đổi
    • Tôi tò mò có công cụ hay tài liệu nào đáng đề xuất liên quan đến tuning độ trễ không
    • Nếu mục tiêu là giảm độ trễ để có đặc tính thời gian thực cho hệ thống, thì dù vặn bao nhiêu núm trên một bản phân phối Linux mặc định, khả năng cao vẫn không tạo ra được một hệ thống thỏa mãn

  • Chờ đợi cũng là một chiến lược tốt
    Từ Linux 6.5, scheduler hiểu rằng khi một “core” SMT đang bận, việc đặt thứ gì đó lên “core” khác có thể không phải lựa chọn tốt nhất. Vì trên thực tế nó gần giống một core đơn với chi phí context switch rất thấp
    Nhờ vậy các tác vụ có tính song song cao trở nên phản hồi nhanh hơn thấy rõ, và cũng có thể thấy trên biểu đồ sử dụng CPU
    Kết quả có thể khác nhau do các vấn đề cache coherence và NUMA

    • Với các kernel cũ hơn, chỉ cần tắt SMT cũng có thể có cảm giác nhanh nhạy hơn, đồng thời chặn được một số tấn công kênh bên và tăng hiệu quả năng lượng

  • Bài liên quan:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - tháng 1/2017, 64 bình luận
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - tháng 8/2014, 22 bình luận

  • Nếu ai đó muốn thay đổi một tham số tunable nào đó nhưng không giải thích được vì sao thay đổi ấy sẽ tạo ra hiệu quả mong muốn, và vì sao ngay từ đầu nó được đặt ở giá trị đó, thì tôi sẽ không cho thay đổi trong môi trường production
    Có thể gọi là “tham số tunable của Chesterton”

    • Ngay cả khi có thể đưa ra một lý do giả định, chẳng phải cứ benchmark ngoài môi trường production là được sao?

  • Nghĩ đến công việc eBPF của Brendan, tài liệu này được tôi hiểu như một cách để giám sát và đánh giá dễ hơn trong nhiều tình huống hiệu năng khác nhau
    Việc điều chỉnh và tuning có các đánh đổi, và thông thường tối ưu một thứ sẽ khiến thứ khác chịu thiệt
    Ngoài ra, btop rất hữu ích như một trình xem hiệu năng/tải hệ thống TUI tất cả trong một để thay thế glances. Tôi cũng tò mò các developer đang tận dụng nó đến mức nào, và liệu họ có động lực tạo ra các công cụ giám sát TUI tốt hơn không
    Khi vào server, việc đầu tiên tôi làm là bật tmux và dành một cửa sổ cho btop

  • Với tôi, “tuning” hiệu năng Linux đồng nghĩa với tắt các biện pháp giảm thiểu Spectre/Meltdown
    Trong trường hợp này, các node tính toán chạy trong VPC không có quyền truy cập Internet, nên rủi ro có vẻ khá thấp

    • Còn tùy dùng CPU nào. Trên Zen 4, việc tắt các biện pháp giảm thiểu không được hỗ trợ và đã gây lỗi hoặc crash
      Có vẻ lỗi crash cụ thể đó đã được sửa, nhưng tôi vẫn không khuyến nghị. Các CPU mới nhất của AMD và Intel được thiết kế để chạy với ít nhất các biện pháp giảm thiểu mặc định được bật

  • Đã đánh dấu lại. Có vẻ sẽ sớm hữu ích cho việc tôi đang làm
    Tôi vẫn chưa đọc hết toàn bộ slide, nhưng tò mò không biết đã có ai từng thấy tùy chọn build kernel mang lại cải thiện hiệu năng đáng kể chưa
    Trước đây khi dùng Gentoo và chỉnh các build flag, tôi từng sửa Makefile của kernel để dùng -O3 và áp dụng patch -march=native. Nhìn lại thì theo benchmark của Phoronix, cách này có vẻ còn gây hại cho nhiều workload, nên tôi tò mò không biết có ai từng thấy trường hợp ngược lại không

  • Một trang hay. Nó có xu hướng muốn tóm lược hiệu năng Linux, dù là tuning hay monitoring, nên đọc vào thấy như phải hít một hơi thật sâu
    Chủ đề này rất sâu, và các loại công cụ quan sát cũng cực kỳ nhiều. Ít nhất phải hiểu sâu uptime, dmesg, iostat. Những công cụ này lướt qua nhiều khía cạnh của hệ thống như tải, bộ nhớ, CPU, v.v. và cho manh mối đầu tiên để chẩn đoán trạng thái. Đây mới là trang 1 trong 100 trang của checklist mà tôi gọi là “thử nhìn qua một lượt”
    Trong phương pháp luận phân tích hiệu năng, người ta khuyến nghị benchmark cẩn trọng để đánh giá tổng thể hành vi hệ thống và đặc tính workload. Hãy so sánh các kịch bản trước và sau khi thay đổi, trước tiên thực hiện thay đổi nhỏ rồi dần dần gộp những thay đổi được xem là có lợi. Môi trường lab và production tuyệt đối không bao giờ hoạt động giống hệt nhau
    Từ đây bắt đầu khó. CPU profiling bằng các công cụ như perf và các trực quan hóa như flame graph cho phép phân tích có mục tiêu hoạt động CPU, và khi thêm cả theo dõi sự kiện phần cứng thì có thể tối ưu hiệu quả tính toán. Cần biết nhiều hơn mức “lỗi ở app đó, trước bản phát hành mới nhất của đội dev thì vẫn ổn”
    Với tư cách admin, khi nói chuyện với developer thì trên Linux sẽ cần các công cụ như ftrace và BPF. Chúng có thể theo dõi chi tiết việc thực thi hàm kernel và system call, nên rất quan trọng cho xử lý sự cố và tối ưu hiệu năng. Ngược lại, nếu là developer thì có thể bạn phải kiểm chứng trực giác của admin. Như câu nói, hãy tin nhưng vẫn phải kiểm chứng
    Nếu đó là code của bạn, bạn cần biết BPF. BPF không chỉ cho phép tracing hiệu quả bên trong kernel, mà còn thúc đẩy việc phát triển các công cụ profiling tùy biến nâng cao thông qua bcc và bpftrace, giúp nhìn sâu hơn vào hiệu năng hệ thống
    Cuối cùng, việc này thật sự khó. Tuning là điều chỉnh vô số thành phần hệ thống và tham số kernel, từ CPU và bộ nhớ cho đến cấu hình mạng, để tối ưu hiệu năng và độ tin cậy trên nhiều workload khác nhau. Hoặc cứ đổ lỗi cho mạng cũng được
    Trên thực tế, cần có thái độ tốt với quản lý thay đổi. Việc lần theo code hay tham số kernel đều có thể khiến mọi người quá tải, và trong tình huống bị thời gian thúc ép, áp lực sẽ làm tăng khả năng con người mắc lỗi