3 पॉइंट द्वारा GN⁺ 2023-10-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Brendan Gregg का Linux Performance पेज Linux performance जांच शुरू करते समय ज़रूरी observability, analysis, benchmarking, और tuning resources को एक जगह इकट्ठा करने वाला लिंक हब है
  • मुख्य tool flow perf, eBPF, bcc, bpftrace, Flame Graphs तक जाता है, और command examples से लेकर tracing tools और visualization तक सीधे पहुँचा जा सकता है
  • दस्तावेज़ी resources में Netflix की 2015 performance analysis post, EC2 tuning, Linux load averages, frame pointers, gdb examples, और performance पर दो किताबें शामिल हैं
  • talks की सूची स्थिति-आधारित learning paths देती है, जैसे 40-मिनट overview, 90-मिनट tool tutorial, container performance analysis, और SRE checklist
  • हर tool map की ताज़गी जाँचने के लिए इमेज के नीचे दाईं ओर दिया गया वर्ष देखना चाहिए, और integrated diagram दूसरे अलग-अलग diagrams जितना पूरा नहीं है

प्रदर्शन संसाधन हब और टूल मैप

  • यह पेज Brendan Gregg द्वारा बनाए गए Linux performance resources का लिंक हब है
  • दाईं ओर का tool map image slide deck के लिए बड़े फ़ॉन्ट में बनाया गया है, और इसे प्रिंट करके ऑफिस की दीवार पर भी लगाया जा सकता है
  • tool map Linux performance काम को नीचे दिए गए हिस्सों में बाँटकर दिखाता है
  • हर image कितनी नई है, यह देखने के लिए नीचे दाईं ओर दिया गया वर्ष देखना चाहिए
  • observability, static performance tuning, और perf-tools/bcc को मिलाकर एक high-resolution diagram भी अलग से दिया गया है
    • png
    • svg
    • यह integrated diagram दूसरे अलग-अलग diagrams जितना पूरा नहीं है

सीधे जुड़े मुख्य टूल

  • perf: perf one-liners, examples, और visualization resources
  • eBPF tools: BPF/bcc tracing tools और examples
  • perf-tools: Ftrace-आधारित perf tool collection
  • bcc: BPF/bcc performance tool collection
  • bpftrace: BPF/bpftrace performance tool collection
  • Flame Graphs: perf और दूसरे profilers के साथ Flame Graph इस्तेमाल करने का तरीका

दस्तावेज़ और सीखने की सामग्री

  • Linux Performance Analysis in 60,000 Milliseconds 2015 का Netflix resource है, जिसमें performance जांच शुरू करते समय इस्तेमाल होने वाले पहले 10 commands को व्यवस्थित किया गया है
    • संबंधित सामग्री के रूप में video और PDF उपलब्ध हैं
  • Performance Tuning Linux Instances on EC2 में Netflix द्वारा इस्तेमाल किए गए EC2 Linux tuning values शामिल हैं
  • Linux Load Averages: Solving the Mystery Linux load average के अर्थ और इसमें uninterruptible sleep state शामिल होने के कारण को समझाता है
  • The Return of the Frame Pointers frame pointers की भूमिका, प्रमुख Linux distributions में उनके फिर से लौटने के कारण, और दूसरे stack walking techniques की व्याख्या करता है
  • gdb Debugging Full Example perf/debugging tools के उपयोग सहित gdb tutorial है
  • Systems Performance: Enterprise and the Cloud, 2nd Edition performance analysis methodology और Linux tools को कवर करती है, जिनमें perf, Ftrace, और eBPF शामिल हैं
  • BPF Performance Tools 100 से अधिक eBPF performance analysis tools के साथ पारंपरिक tools का संक्षिप्त सार भी कवर करती है
    • अगर Systems Performance 2nd Edition पहला खंड है, तो यह किताब दूसरे खंड जैसी है
  • Linux में perf और eBPF के साथ Flame Graph बनाने की सामग्री भी अलग से दी गई है

eBPF, ftrace, perf पर गहन लेख

स्थिति के अनुसार सुझाए गए व्याख्यान

  • Linux Systems Performance, USENIX LISA 2019

    • 40 मिनट में Linux सिस्टम performance को observability, methodology, benchmarking, profiling, tracing और tuning के 6 पहलुओं में संक्षेपित किया गया है
    • video, youtube, slides, PDF
  • Linux Performance 2018, PerconaLive 2018

    • 2018 के Linux performance में हुए हालिया बदलावों और फीचर्स को 20 मिनट के keynote में संक्षेपित किया गया है
    • youtube, slideshare, PDF
  • Linux Performance Tools, Velocity 2015

    • 90 मिनट के tutorial में performance observability, benchmarking, tuning, static performance tuning, tracing tools और methodology, तथा live demo शामिल हैं
    • youtube playlist, slideshare, PDF
  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • performance observability की तुलना में tuning पर अधिक फोकस है, और इसमें Netflix की पृष्ठभूमि, AWS EC2 instance types और features, Linux kernel tunables, तथा observability शामिल हैं
    • youtube, slideshare
  • Container Performance Analysis, DockerCon 2017

    • host और container में bottleneck कहाँ है, इसे ढूँढने, container app को profile करने, और kernel के भीतर और गहराई तक जाने के तरीकों पर चर्चा की गई है
    • youtube, slideshare
  • Broken Linux Performance Tools, SCaLE14x 2016

    • Linux system tools, metrics, statistics, visualization, measurement overhead, benchmarking में अक्सर आने वाली समस्याएँ, और “What You Can Do” सलाह को साथ में कवर किया गया है
    • youtube, slideshare, PDF
  • Using Linux perf at Netflix, Kernel Recipes 2017

    • CPU profiling और Flame Graphs के काम करने के तरीके पर फोकस है, और perf_events की विशेषताएँ, साथ ही Java, Node.js, VM, और container profiling के दौरान stack traces और symbols से जुड़ी समस्याएँ शामिल हैं
    • 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 series में जो enhanced BPF, यानी eBPF जोड़ा गया, उसे performance analysis, observability, और debugging में कैसे इस्तेमाल किया जाए, यह बताया गया है
    • frontend एक open source project bcc है, जो BPF interface और toolset प्रदान करता है
    • youtube, slideshare, PDF
  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • ftrace और perf_events tools, और मुख्य रूप से ftrace का उपयोग करने वाले perf-tools को कवर किया गया है
    • ftrace को Linux kernel में कई वर्षों से built-in होने के बावजूद लगभग अनदेखे tracing tool के रूप में प्रस्तुत किया गया है
    • youtube, slideshare, PDF
  • Performance Checklists for SREs, SREcon 2016

    • बाद के हिस्से में Linux incident performance response के लिए checklist शामिल है, जो तात्कालिक Linux performance analysis में भी उपयोगी हो सकती है
    • 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 distributions पर लागू किया जा सकता है
  • Linux Instrumentation Ian Munsie के जून 2010 के व्याख्यान की स्लाइड्स हैं, जो विभिन्न Linux tracer का सार प्रस्तुत करती हैं
  • Julia Evans blog performance tools सहित कई विषयों पर लेख प्रदान करता है
  • Davidlohr Bueso के Linux performance posts भी अनुशंसित सामग्री में शामिल हैं

1 टिप्पणियां

 
GN⁺ 2023-10-15
Hacker News की राय
  • रियल-टाइम ऐप चलाने वाले Debian/Ubuntu VPS पर मैं tuned इस्तेमाल कर रहा हूँ और यह काफ़ी अच्छा काम करता है
    kernel parameters, यानी sysctl settings या kernel tunables को सीधे बदलने से यह आसान है
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • SAP workloads के लिए भी Tuned इस्तेमाल कर रहा हूँ और यह बहुत पसंद है
  • मुझे नहीं पता था कि Brendan Gregg अब Intel में हैं
    https://en.wikipedia.org/wiki/Brendan_Gregg
    वायरल वीडियो Shouting in the Data Center के मुख्य व्यक्ति भी वही हैं
    https://www.youtube.com/watch?v=tDacjrSCeq4
    सच में जीनियस हैं

  • यह बात ध्यान देने लायक है कि मूल लेख में चर्चा की गई लगभग सारी चीज़ें latency के बारे में नहीं, बल्कि network, disk, अन्य I/O और CPU के throughput/bandwidth के बारे में हैं
    कई लोगों के लिए performance का मतलब throughput होता है, इसलिए बात समझ आती है। लेकिन कई मामलों में latency, throughput से कहीं ज़्यादा अहम होती है, और Linux में latency tune करने के लिए अलग तरह के tools की ज़रूरत होती है

    • यह काफ़ी सही बात है। throughput बढ़ाने की तुलना में latency घटाना कहीं ज़्यादा कठिन भी है[1], इसलिए latency पर ध्यान देना कई बार ज़रूरी होता है
      एक और axis जिसे लोग optimize कर सकते हैं, वह है performance per watt, लेकिन यहाँ उस पर विस्तार से नहीं बोलूँगा
      कुछ मामलों में throughput optimization ही latency optimization बन जाता है। उदाहरण के लिए, अगर एक box पर ज़्यादा processes रखे जा सकें, तो process और उसके communication target के बीच की औसत दूरी घटती है और average latency भी कम होती है
      latency optimize करते समय एक बहुत obvious काम यह है कि throughput को इतना बढ़ा दिया जाए कि वह bottleneck न रहे
      अगर latency को aggressively optimize किया जाए, तो लगता है कि Linux tuning में खुद बहुत ज़्यादा करने को नहीं होता। मैं गलत हो सकता हूँ, लेकिन आम तौर पर core pinning, tickless execution, user-space networking, और page size·SMT·power-saving settings·hardware selection जैसी hardware-side adjustments मुख्य होती हैं
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • bandwidth की बजाय इसे throughput कहना ज़्यादा सही लगता है। मतलब मिलता-जुलता है, लेकिन throughput और latency का contrast बहुत पहले से चर्चा में रहा है
      कभी-कभी दोनों को improve किया जा सकता है, लेकिन आम तौर पर यह trade-off होता है
    • latency tuning से जुड़े recommended tools या resources जानना चाहूँगा
    • अगर लक्ष्य system की real-time characteristics के लिए latency घटाना है, तो default Linux distribution में चाहे जितने knobs tweak कर लें, satisfactory system बनने की संभावना कम है
  • इंतज़ार करना भी एक अच्छी strategy है
    Linux 6.5 से scheduler यह समझता है कि जब एक SMT “core” busy हो, तो दूसरे “core” पर कुछ schedule करना हमेशा best नहीं हो सकता। असल में वह बहुत कम context-switch cost वाले single core जैसा होता है
    इससे बहुत parallel workloads noticeably ज़्यादा responsive हुए हैं, और CPU usage graphs में भी दिखता है
    cache coherency और NUMA issues की वजह से results अलग हो सकते हैं

    • पुराने kernels में भी सिर्फ़ SMT disable करके ज़्यादा snappy effect मिल सकता है, कुछ side-channel attacks भी रुकते हैं और power efficiency भी बढ़ती है
  • संबंधित लेख:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - जनवरी 2017, 64 comments
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - अगस्त 2014, 22 comments

  • अगर कोई किसी tunable parameter को बदलना चाहता है, लेकिन यह नहीं समझा सकता कि वह change desired effect क्यों देगा, या वह value पहले से उसी तरह set क्यों है, तो मैं production environment में उसे बदलने नहीं दूँगा
    इसे “Chesterton का tunable parameter” कहा जा सकता है

    • अगर कोई hypothetical reason समझा भी सकता है, तब भी production environment के बाहर benchmark कर लेना ही ठीक नहीं है?
  • Brendan के eBPF work को देखते हुए, यह material अलग-अलग performance situations में आसानी से monitoring और evaluation करने के तरीके के रूप में समझ आता है
    adjustment और tuning में trade-offs होते हैं, और आम तौर पर एक चीज़ optimize करने पर दूसरी तरफ़ नुकसान होता है
    इसके अलावा, btop glances की जगह लेने वाला all-in-one TUI system performance/load viewer के तौर पर बहुत उपयोगी रहा। यह जानने की उत्सुकता है कि developers इसे कितना use कर रहे हैं, और क्या बेहतर TUI monitoring tools बनाने की motivation है
    server में login करते ही मैं सबसे पहले tmux खोलता हूँ और एक window btop को दे देता हूँ

  • मेरे लिए Linux performance “tuning” का मतलब Spectre/Meltdown mitigations disable करना है
    इस मामले में compute nodes बिना internet access वाले VPC के अंदर चलते हैं, इसलिए risk काफ़ी कम लगता है

    • यह इस पर निर्भर करता है कि आप कौन-सा CPU इस्तेमाल कर रहे हैं। Zen 4 पर mitigations disable करना supported नहीं था और bugs या crashes कराता था
      लगता है वह specific crash fix हो गया है, लेकिन फिर भी मैं recommend नहीं करूँगा। AMD और Intel के latest CPUs कम-से-कम default mitigations on रखकर चलने के लिए design किए गए हैं
  • बुकमार्क कर लिया। लगता है जल्द ही जिस काम पर लगा हूँ, उसमें काम आएगा
    अभी तक मैंने सभी स्लाइड्स नहीं पढ़ी हैं, लेकिन जिज्ञासा है कि क्या किसी ने kernel build options से कोई सार्थक performance improvement देखा है
    पहले Gentoo इस्तेमाल करते समय build flags से छेड़छाड़ करता था; kernel Makefile बदलकर -O3 इस्तेमाल करता और -march=native patch लगाता था। पीछे मुड़कर देखें तो Phoronix benchmarks में कई workloads पर यह उल्टा नुकसानदेह दिखता है, इसलिए जानना चाहता हूँ कि क्या किसी ने इसका उल्टा उदाहरण देखा है

  • अच्छी साइट है। Linux performance को चाहे tuning हो या monitoring, summarize करने की इसकी प्रवृत्ति है, इसलिए गहरी साँस लेनी पड़ती है
    यह विषय गहरा है, और observability tools की किस्में भी बहुत ज़्यादा हैं। कम-से-कम uptime, dmesg, iostat को गहराई से जानना चाहिए। ये tools load, memory, CPU जैसे system के कई पहलुओं पर नज़र डालते हैं और health diagnosis का पहला सुराग देते हैं। मेरी “जरा एक बार देख लेते हैं” checklist के 100 पन्नों में यह पहला पन्ना है
    performance analysis methodology में system behavior और workload characteristics का समग्र मूल्यांकन करने के लिए सावधानी से benchmark करने की सलाह दी जाती है। बदलाव से पहले और बाद के scenarios की तुलना करें, पहले छोटे बदलाव करें और फिर जिनमें फायदा दिखे उन्हें धीरे-धीरे मिलाएँ। lab और production environment कभी भी बिल्कुल एक जैसा व्यवहार नहीं करते
    यहीं से मामला पेचीदा हो जाता है। perf जैसे tools से की जाने वाली CPU profiling और flame graph जैसी visualizations CPU activity का targeted analysis करने देती हैं, और hardware event tracing जोड़कर computational efficiency को optimize किया जा सकता है। “ऐप की दिक्कत है, dev team के latest release से पहले सब ठीक था” से ज़्यादा समझना पड़ेगा
    administrator के रूप में developers से बात करते समय Linux में ftrace और BPF जैसे tools की ज़रूरत पड़ती है। ये kernel function execution और system calls को detail में trace कर सकते हैं, इसलिए troubleshooting और performance optimization के लिए अहम हैं। उल्टा, अगर आप developer हैं तो administrator की intuition को verify करना पड़ सकता है। कहावत की तरह, भरोसा करें लेकिन verify भी करें
    अगर यह आपका अपना code है, तो BPF जानना चाहिए। BPF न सिर्फ efficient in-kernel tracing को संभव बनाता है, बल्कि bcc और bpftrace के जरिए advanced custom profiling tools बनाने को भी बढ़ावा देता है, और system performance को और गहराई से देखने में मदद करता है
    आख़िर में, यह सचमुच मुश्किल है। tuning का मतलब CPU और memory से लेकर network settings तक अनेक system components और kernel parameters को adjust करना है, ताकि अलग-अलग workloads में performance और reliability optimize हो सके। या फिर सारा दोष network पर डाल दीजिए
    असल में बदलाव प्रबंधन के प्रति अच्छा रवैया चाहिए। code या kernel parameters के पीछे भागना सबको overwhelm कर सकता है, और time pressure वाली स्थिति में दबाव इंसानी गलती की संभावना और बढ़ा देता है