ประสิทธิภาพของ Linux

• หน้า Linux Performance ของ Brendan Gregg เป็นฮับลิงก์ที่รวบรวม ทรัพยากรด้านการสังเกตการณ์·การวิเคราะห์·การเบนช์มาร์ก·การปรับจูน ที่จำเป็นเมื่อต้องเริ่มตรวจสอบประสิทธิภาพของ Linux ไว้ในที่เดียว
• โฟลว์เครื่องมือหลักเชื่อมต่อกันตั้งแต่ perf, eBPF, bcc, bpftrace, Flame Graphs และสามารถเข้าถึงได้ทันทีตั้งแต่ตัวอย่างคำสั่งไปจนถึงเครื่องมือติดตามและการทำภาพข้อมูล
• เอกสารขยายไปยังบทความวิเคราะห์ประสิทธิภาพของ Netflix ปี 2015, การปรับจูน EC2, Linux load averages, frame pointers, ตัวอย่าง gdb และหนังสือด้านประสิทธิภาพ 2 เล่ม
• รายการบรรยายให้ เส้นทางการเรียนรู้ตามสถานการณ์ เช่น ภาพรวม 40 นาที, บทเรียนเครื่องมือ 90 นาที, การวิเคราะห์ประสิทธิภาพคอนเทนเนอร์ และเช็กลิสต์ SRE
• แผนที่เครื่องมือแต่ละรายการควรตรวจสอบความทันสมัยจาก ปี ที่มุมขวาล่างของภาพ และไดอะแกรมรวมไม่ได้สมบูรณ์เท่าไดอะแกรมแยกอื่น ๆ

---

ฮับทรัพยากรด้านประสิทธิภาพและแผนที่เครื่องมือ

• หน้านี้เป็นฮับลิงก์ที่รวบรวม ทรัพยากร Linux performance ที่ Brendan Gregg จัดทำไว้
• ภาพแผนที่เครื่องมือด้านขวาถูกสร้างด้วยฟอนต์ขนาดใหญ่ให้เหมาะกับชุดสไลด์ และเป็นรูปแบบที่สามารถพิมพ์ออกมาติดผนังสำนักงานได้
• แผนที่เครื่องมือแบ่งงานด้านประสิทธิภาพของ Linux ออกเป็นพื้นที่ต่อไปนี้
  • Linux observability tools
  • Linux static performance analysis tools
  • Linux benchmarking tools
  • Linux tuning tools
  • Linux sar
• ควรตรวจสอบว่าแต่ละภาพทันสมัยแค่ไหนจาก ปี ที่มุมขวาล่าง
• ยังมีไดอะแกรมความละเอียดสูงที่รวมการสังเกตการณ์, การปรับจูนประสิทธิภาพแบบสแตติก และ perf-tools/bcc แยกต่างหากด้วย
  • png
  • svg
  • ไดอะแกรมรวมนี้ไม่ได้สมบูรณ์เท่าไดอะแกรมแยกอื่น ๆ

เครื่องมือหลักที่เชื่อมต่อได้ทันที

• perf: perf one-liners, ตัวอย่าง และสื่อภาพข้อมูล
• eBPF tools: เครื่องมือติดตาม BPF/bcc และตัวอย่าง
• perf-tools: ชุดเครื่องมือ perf ที่ใช้ Ftrace
• bcc: ชุดเครื่องมือประสิทธิภาพ BPF/bcc
• bpftrace: ชุดเครื่องมือประสิทธิภาพ BPF/bpftrace
• Flame Graphs: วิธีใช้ Flame Graph ด้วย perf และโปรไฟเลอร์อื่น ๆ

เอกสารและสื่อการเรียนรู้

• Linux Performance Analysis in 60,000 Milliseconds เป็นเอกสารของ Netflix ปี 2015 ที่สรุป 10 คำสั่งแรกที่ใช้เมื่อเริ่มตรวจสอบประสิทธิภาพ
  • มีเอกสารที่เกี่ยวข้องเป็น video และ PDF
• Performance Tuning Linux Instances on EC2 รวม ค่าการปรับจูน EC2 Linux ที่ Netflix ใช้
• Linux Load Averages: Solving the Mystery กล่าวถึงความหมายของ Linux load average และเหตุผลที่รวมสถานะ uninterruptible sleep ไว้ด้วย
• The Return of the Frame Pointers อธิบายบทบาทของ frame pointers, เหตุผลที่กลับมาในดิสทริบิวชัน Linux หลัก ๆ และเทคนิค stack walking แบบอื่น
• gdb Debugging Full Example เป็นบทเรียน gdb ที่รวมการใช้เครื่องมือ perf/debugging
• Systems Performance: Enterprise and the Cloud, 2nd Edition ครอบคลุมระเบียบวิธีวิเคราะห์ประสิทธิภาพและเครื่องมือ Linux รวมถึง perf, Ftrace, eBPF
• BPF Performance Tools ครอบคลุม เครื่องมือวิเคราะห์ประสิทธิภาพ eBPF มากกว่า 100 รายการ พร้อมสรุปสั้น ๆ ของเครื่องมือแบบดั้งเดิม
  • หาก Systems Performance 2nd Edition เป็นเล่ม 1 หนังสือเล่มนี้ก็มีลักษณะเทียบได้กับเล่ม 2
• ยังมีทรัพยากรแยกต่างหากสำหรับสร้าง Flame Graph บน Linux ด้วย perf และ eBPF
  • CPU Flame Graphs
  • Off-CPU Flame Graphs
  • Memory Flame Graphs

บทความเชิงลึกเกี่ยวกับ eBPF, ftrace, perf

• บทความเกี่ยวกับ eBPF, bcc, bpftrace มีต่อเนื่องตั้งแต่ปี 2015 ถึง 2023
  • Linux eBPF
  • bcc: Taming Linux 4.3+ Tracing Superpowers
  • Learn eBPF Tracing: Tutorial and Examples
  • A thorough introduction to bpftrace
  • BPF binaries: BTF, CO-RE, and the future of BPF perf tools
  • eBPF Observability Tools are not Security Tools
• Ftrace: The Hidden Light Switch เป็นบทความของ lwn.net ที่กล่าวถึงกรณีการใช้งาน Linux ftrace
• บทความเกี่ยวกับ perf-tools ที่ใช้ ftrace มีให้ตั้งแต่ปี 2014–2015 และรวมถึงบทความเกี่ยวกับ iosnoop, opensnoop, execsnoop, tcpretrans, Page Cache Hit Ratio, uprobe, USDT
• เอกสารที่อิงกับ perf ครอบคลุม perf_events และ CPU sampling, static tracepoints, heat maps, counting, kernel line tracing, off-CPU flame graphs, Netflix Linux profiling, Java mixed-mode flame graphs, perf sched เป็นต้น
• Working Set Size Estimation เป็นเอกสารเกี่ยวกับการประมาณ working set size สำหรับ Linux
• KPTI/KAISER Meltdown Initial Performance Regressions กล่าวถึง performance regressions ที่เกี่ยวข้องกับ Meltdown ในปี 2018
• CPU Utilization is Wrong กล่าวถึงปัญหาที่ memory stall cycles มีอิทธิพลต่อดัชนี %CPU มากขึ้น
• USE Method: Linux Performance Checklist และ Off-CPU Analysis Method เป็นเอกสารเกี่ยวกับระเบียบวิธีวิเคราะห์ประสิทธิภาพของ Linux

การบรรยายแนะนำตามสถานการณ์

• Linux Systems Performance, USENIX LISA 2019

  • สรุปประสิทธิภาพของระบบ Linux ภายใน 40 นาที ผ่าน 6 ด้าน ได้แก่ observability, methodology, benchmarking, profiling, tracing และ tuning
  • video, youtube, slides, PDF

• Linux Performance 2018, PerconaLive 2018

  • สรุปความเปลี่ยนแปลงและฟีเจอร์ล่าสุดของ Linux performance ในปี 2018 ในรูปแบบ keynote 20 นาที
  • youtube, slideshare, PDF

• Linux Performance Tools, Velocity 2015

  • เป็น tutorial 90 นาที ครอบคลุม observability ด้านประสิทธิภาพ, benchmarking, tuning, static performance tuning, เครื่องมือและวิธีการ tracing รวมถึงเดโมสด
  • youtube playlist, slideshare, PDF

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

  • มุ่งเน้นที่ tuning มากกว่า observability ด้านประสิทธิภาพ โดยครอบคลุมเบื้องหลังของ Netflix, ประเภทและฟีเจอร์ของ AWS EC2 instances, Linux kernel tunables และ observability
  • youtube, slideshare

• Container Performance Analysis, DockerCon 2017

  • ครอบคลุมวิธีค้นหาว่าคอขวดอยู่ที่ host หรือ container, การ profiling แอปใน container และวิธีลงลึกไปถึง kernel
  • youtube, slideshare

• Broken Linux Performance Tools, SCaLE14x 2016

  • ครอบคลุมปัญหาที่พบบ่อยในเครื่องมือระบบ Linux, metrics, statistics, visualization, overhead จากการวัด และ benchmarks พร้อมคำแนะนำ “What You Can Do”
  • youtube, slideshare, PDF

• Using Linux perf at Netflix, Kernel Recipes 2017

  • มุ่งเน้นที่ CPU profiling และการทำงานของ Flame Graphs รวมถึงคุณสมบัติของ perf_events และปัญหา stack traces กับ symbols เมื่อ profiling Java, Node.js, VM และ containers
  • youtube, slideshare

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

  • เป็นเดโมที่แสดง ftrace, perf และ bcc/BPF
  • youtube, full talk video, slides

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

  • ครอบคลุมการใช้ enhanced BPF หรือ eBPF ที่เพิ่มเข้ามาในซีรีส์ Linux 4.x สำหรับ performance analysis, observability และ debugging
  • frontend คือโปรเจกต์โอเพนซอร์ส bcc ที่มีอินเทอร์เฟซและชุดเครื่องมือ BPF
  • youtube, slideshare, PDF

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

  • ครอบคลุมเครื่องมือ ftrace และ perf_events รวมถึง perf-tools ที่ใช้ ftrace เป็นหลัก
  • แนะนำ ftrace ว่าเป็น tracer ที่ฝังอยู่ใน Linux kernel มาหลายปี แต่แทบไม่มีใครค้นพบ
  • youtube, slideshare, PDF

• Performance Checklists for SREs, SREcon 2016

  • ช่วงท้ายมี checklist สำหรับการตอบสนองต่อ incident ด้านประสิทธิภาพบน Linux และอาจมีประโยชน์ต่อการวิเคราะห์ประสิทธิภาพ Linux แบบเร่งด่วนด้วย
  • youtube, usenix, slideshare, PDF

แหล่งข้อมูลแนะนำภายนอก

• RHEL Performance Guide มีเครื่องมือ CLI และ tunables จำนวนมาก
• Performance analysis & tuning of Red Hat Enterprise Linux - 2015 Red Hat Summit เป็นวิดีโอความยาว 2 ชั่วโมงที่เจาะลึกเรื่อง Linux performance tuning และสามารถนำไปใช้ได้กับ Linux distribution ส่วนใหญ่
• Linux Instrumentation เป็นสไลด์จากการบรรยายของ Ian Munsie เมื่อเดือนมิถุนายน 2010 ซึ่งสรุป Linux tracer หลากหลายชนิด
• บล็อกของ Julia Evans มีบทความหลากหลายหัวข้อ รวมถึงเครื่องมือด้านประสิทธิภาพ
• โพสต์เกี่ยวกับประสิทธิภาพ Linux ของ Davidlohr Bueso ก็รวมอยู่ในแหล่งข้อมูลแนะนำด้วย

[GN⁺]

ความคิดเห็นจาก Hacker News

• ผมใช้ tuned บน Debian/Ubuntu VPS ที่รันแอปแบบเรียลไทม์อยู่ และมันทำงานได้ค่อนข้างดี
  ง่ายกว่าการไปเปลี่ยนพารามิเตอร์ของเคอร์เนลโดยตรง เช่น การตั้งค่า sysctl หรือค่า tunable ของเคอร์เนล
  https://access.redhat.com/documentation/en-us/red_hat_enterp...
  sudo apt install tuned

  • เราก็ใช้ Tuned กับ SAP workload อยู่เหมือนกัน และชอบมาก

• ไม่รู้มาก่อนว่า Brendan Gregg ตอนนี้อยู่ Intel แล้ว
  https://en.wikipedia.org/wiki/Brendan_Gregg
  เขายังเป็นตัวเอกในวิดีโอไวรัล Shouting in the Data Center ด้วย
  https://www.youtube.com/watch?v=tDacjrSCeq4
  เป็นอัจฉริยะจริง ๆ

• น่าชี้ให้เห็นว่าเกือบทุกอย่างที่บทความต้นฉบับพูดถึงนั้นไม่ใช่เรื่อง latency แต่เป็นเรื่อง throughput/bandwidth ของเครือข่าย ดิสก์ I/O อื่น ๆ และ CPU
  สำหรับหลายคน performance หมายถึง throughput ก็เข้าใจได้ แต่ก็มีกรณีที่ latency สำคัญกว่า throughput มาก และถ้าจะจูน latency บน Linux ต้องใช้ชุดเครื่องมือคนละแบบ

  • เป็นข้อสังเกตที่ค่อนข้างสมเหตุสมผล อีกอย่าง การลด latency มักยากกว่าการเพิ่ม throughput มาก[1] ดังนั้นการใส่ใจเรื่อง latency จึงมักสำคัญ
    แกนอีกด้านที่ผู้คนสามารถ optimize ได้คือ performance per watt แต่จะไม่ขยายความตรงนี้
    บางครั้งการ optimize throughput ก็กลายเป็นการ optimize latency ไปด้วย เช่น ถ้าสามารถยัดโปรเซสลงในเครื่องเดียวได้มากขึ้น ระยะทางเฉลี่ยระหว่างโปรเซสกับปลายทางที่สื่อสารด้วยก็ลดลง ทำให้ latency เฉลี่ยลดลงด้วย
    สิ่งที่ชัดเจนมากเวลา optimize latency คือการเพิ่ม throughput ให้มากพอจนไม่เป็นคอขวด
    ถ้าจะ optimize latency แบบจริงจัง ผมรู้สึกว่าการจูน Linux เองไม่ได้มีมากนัก อาจจะผิดก็ได้ แต่โดยรวมเหมือนจะเน้นการ pin core, รันแบบ tickless, user-space networking และการปรับฝั่งฮาร์ดแวร์อย่างขนาดหน้าเพจ, SMT, การตั้งค่าประหยัดพลังงาน และการเลือกฮาร์ดแวร์
    [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
  • น่าจะเรียกว่า throughput มากกว่า bandwidth ถึงความหมายจะคล้ายกัน แต่การเปรียบเทียบระหว่าง throughput กับ latency เป็นเรื่องที่ถกกันมานานแล้ว
    บางครั้งอาจปรับให้ดีขึ้นได้ทั้งคู่ แต่โดยปกติแล้วเป็น trade-off
  • อยากรู้ว่ามีเครื่องมือหรือแหล่งข้อมูลอะไรที่แนะนำเกี่ยวกับ การจูน latency บ้าง
  • ถ้าเป้าหมายคือการลด latency เพื่อคุณสมบัติแบบเรียลไทม์ของระบบ ต่อให้ไปปรับ knob ต่าง ๆ มากมายบนดิสโทร Linux พื้นฐาน ก็มีโอกาสสูงที่จะยังไม่ได้ระบบที่น่าพอใจ

• การรอก็เป็นกลยุทธ์ที่ดีเหมือนกัน
  ตั้งแต่ Linux 6.5 เป็นต้นมา scheduler เข้าใจแล้วว่าเมื่อ “คอร์” SMT หนึ่งยุ่งอยู่ การวางงานบางอย่างลงบน “คอร์” อื่นอาจไม่ใช่ทางเลือกที่ดีที่สุด เพราะในทางปฏิบัติมันใกล้เคียงกับคอร์เดียวที่มีต้นทุน context switch ต่ำมาก
  ด้วยเหตุนี้งานที่ขนานมาก ๆ จึงรู้สึกได้ว่าลื่นขึ้น และเห็นได้จากกราฟการใช้ CPU
  ผลลัพธ์อาจแตกต่างกันไปเพราะปัญหา cache coherency และ NUMA

  • ในเคอร์เนลรุ่นก่อน ๆ แค่ ปิด SMT ก็ให้ความรู้สึกลื่นขึ้นได้แล้ว แถมยังป้องกันการโจมตี side-channel บางแบบ และเพิ่มประสิทธิภาพการใช้พลังงานด้วย

• บทความที่เกี่ยวข้อง:
  Linux Performance - https://news.ycombinator.com/item?id=13498485 - มกราคม 2017, 64 ความคิดเห็น
  Linux Performance - https://news.ycombinator.com/item?id=8205057 - สิงหาคม 2014, 22 ความคิดเห็น

• ถ้าใครอยากเปลี่ยน พารามิเตอร์ tunable บางตัว แต่บอกไม่ได้ว่าทำไมการเปลี่ยนนั้นถึงจะให้ผลตามที่ต้องการ หรือทำไมมันถึงถูกตั้งไว้เป็นค่านั้นตั้งแต่แรก ผมจะไม่ให้เปลี่ยนในสภาพแวดล้อม production
  น่าจะเรียกได้ว่า “พารามิเตอร์ tunable ของ Chesterton”

  • ต่อให้สามารถอธิบายเหตุผลสมมติได้ ยังไงก็ benchmark นอกสภาพแวดล้อม production ได้ไม่ใช่หรือ?

• เมื่อนึกถึงงาน eBPF ของ Brendan เนื้อหานี้จึงดูเหมือนเป็นวิธีทำให้การ monitor และประเมินในสถานการณ์ด้าน performance ต่าง ๆ ทำได้ง่ายขึ้น
  การปรับแต่งและการจูนมี trade-off และโดยปกติเมื่อ optimize สิ่งหนึ่ง ก็มักทำให้อีกด้านเสียประโยชน์
  นอกจากนี้ btop มีประโยชน์มากในฐานะ TUI แบบ all-in-one สำหรับดู performance และโหลดของระบบ แทน glances ผมสงสัยว่านักพัฒนาใช้มันกันมากแค่ไหน และมีแรงจูงใจที่จะสร้างเครื่องมือ monitoring แบบ TUI ที่ดีกว่านี้หรือไม่
  เวลาเข้าเซิร์ฟเวอร์ สิ่งแรกที่ผมทำคือเปิด tmux แล้วจัดหน้าต่างหนึ่งไว้ให้ btop

• สำหรับผม การ “จูน” performance ของ Linux เท่ากับ ปิด mitigation ของ Spectre/Meltdown
  ในกรณีนี้ compute node รันอยู่ใน VPC ที่ไม่มีการเข้าถึงอินเทอร์เน็ต ความเสี่ยงเลยดูค่อนข้างต่ำ

  • ขึ้นอยู่กับว่าใช้ CPU อะไร บน Zen 4 การปิด mitigation ไม่ได้รับการรองรับ และทำให้เกิดบั๊กหรือ crash
    crash เฉพาะกรณีนั้นดูเหมือนจะแก้แล้ว แต่ก็ยังไม่แนะนำอยู่ดี CPU รุ่นใหม่ของ AMD และ Intel ถูกออกแบบมาให้รันโดยเปิด mitigation พื้นฐานไว้เป็นอย่างน้อย

• บุ๊กมาร์กไว้แล้ว คิดว่าน่าจะมีประโยชน์กับงานที่กำลังทำอยู่เร็ว ๆ นี้
  ยังไม่ได้อ่านสไลด์ทั้งหมด แต่สงสัยว่าเคยมีใครเห็นการเพิ่มประสิทธิภาพอย่างมีนัยสำคัญจาก ตัวเลือกการบิลด์เคอร์เนล บ้างไหม
  สมัยก่อนตอนใช้ Gentoo และปรับ build flags ผมเคยแก้ Makefile ของเคอร์เนลให้ใช้ -O3 และใช้แพตช์ -march=native อยู่บ่อย ๆ พอมองย้อนกลับไป จาก benchmark ของ Phoronix ดูเหมือนว่าจะส่งผลเสียกับหลาย workload เสียมากกว่า เลยสงสัยว่าเคยเห็นกรณีตรงกันข้ามกันบ้างไหม

• เป็นไซต์ที่ดี พอเห็นแนวโน้มที่จะสรุปเรื่องประสิทธิภาพของ Linux ไม่ว่าจะเป็นการจูนหรือการมอนิเตอร์ ก็ทำให้ต้องสูดหายใจลึก ๆ
  หัวข้อนี้ลึก และเครื่องมือสำหรับสังเกตการณ์ก็มีมากมายหลายชนิด อย่างน้อยต้องรู้จัก uptime, dmesg, iostat ให้ลึก เครื่องมือเหล่านี้ช่วยกวาดดูหลายแง่มุมของระบบ เช่น load, memory, CPU และให้เบาะแสแรกในการวินิจฉัยสถานะ นี่เป็นหน้า 1 จาก 100 หน้าของเช็กลิสต์ที่ผมเรียกว่า “ลองเข้าไปดูสักหน่อย”
  ใน methodology สำหรับการวิเคราะห์ประสิทธิภาพ ควรทำ benchmark อย่างระมัดระวังเพื่อประเมินพฤติกรรมของระบบและลักษณะของ workload โดยรวม เปรียบเทียบสถานการณ์ก่อนและหลังการเปลี่ยนแปลง และเริ่มจากการเปลี่ยนแปลงเล็ก ๆ ก่อน จากนั้นค่อย ๆ รวมสิ่งที่ตัดสินแล้วว่าให้ประโยชน์เข้าด้วยกัน สภาพแวดล้อมในแล็บกับ production ไม่มีทางทำงานเหมือนกันเป๊ะ
  จากตรงนี้จะเริ่มยากขึ้น CPU profiling ด้วยเครื่องมืออย่าง perf และ visualization อย่าง flame graph ช่วยให้วิเคราะห์กิจกรรมของ CPU แบบเจาะจงได้ และเมื่อเพิ่มการติดตาม hardware events เข้าไปก็ช่วย optimize ประสิทธิภาพการคำนวณได้ ต้องรู้ให้มากกว่าระดับ “เป็นปัญหาของแอปครับ ก่อน release ล่าสุดของทีม dev ยังปกติดีอยู่”
  ในฐานะ admin เวลาคุยกับ developer จะเริ่มต้องใช้เครื่องมืออย่าง ftrace และ BPF บน Linux เพราะสามารถติดตามการทำงานของฟังก์ชันในเคอร์เนลและ system calls ได้ละเอียด ซึ่งสำคัญต่อการแก้ปัญหาและการ optimize ประสิทธิภาพ ในทางกลับกัน ถ้าเป็น developer ก็อาจต้องตรวจสอบสัญชาตญาณของ admin ด้วย อย่างที่ว่าไว้ เชื่อได้แต่ต้องตรวจสอบ
  ถ้าเป็นโค้ดของตัวเอง ก็ควรรู้จัก BPF BPF ไม่เพียงทำให้การ trace ภายในเคอร์เนลมีประสิทธิภาพ แต่ยังช่วยผลักดันการพัฒนาเครื่องมือ profiling แบบปรับแต่งขั้นสูงผ่าน bcc และ bpftrace ทำให้มองเห็นประสิทธิภาพของระบบได้ลึกขึ้น
  สุดท้าย เรื่องนี้ยากจริง ๆ การจูนคือการปรับองค์ประกอบของระบบและพารามิเตอร์เคอร์เนลจำนวนมาก ตั้งแต่ CPU และ memory ไปจนถึงการตั้งค่า network เพื่อ optimize ประสิทธิภาพและความน่าเชื่อถือสำหรับ workload ที่หลากหลาย หรือไม่ก็โทษ network ไปเลยก็ได้
  ในทางปฏิบัติ ต้องมีทัศนคติที่ดีต่อ change management การไล่ตามโค้ดหรือพารามิเตอร์เคอร์เนลอาจทำให้ทุกคนล้นมือได้ และในสถานการณ์ที่ถูกเวลาไล่กดดัน ความกดดันก็ยิ่งเพิ่มโอกาสที่มนุษย์จะทำผิดพลาดมากขึ้น