Linux नेटवर्क परफॉर्मेंस पैरामीटर

 (github.com/leandromoreira)
4 पॉइंट द्वारा GN⁺ 2023-09-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux नेटवर्क फ्लो के भीतर अक्सर इस्तेमाल होने वाले sysctl/network parameters कहाँ स्थित होते हैं, यह दिखाने वाला एक छोटा ट्यूटोरियल
  • हर स्थिति में एक साथ उच्च throughput और कम latency देने वाले cargo cult values व्यावहारिक नहीं हैं, और नए kernel versions में defaults आमतौर पर अच्छी तरह tuned होते हैं; defaults बदलना परफॉर्मेंस को नुकसान पहुँचा सकता है
  • receive path को NIC के MAC/FCS सत्यापन, DMA, receive ring buffer, hard IRQ, NAPI, soft IRQ, ingress qdisc, netfilter, TCP state machine, tcp_rmem आधारित receive buffer, और application read तक के फ्लो के रूप में व्यवस्थित किया गया है
  • transmit path को application sendmsg, skb_buff allocation, tcp_wmem आधारित socket write buffer, TCP/IP header processing, netfilter, txqueuelen आधारित output qdisc, transmit ring buffer, DMA, और NIC transmission complete IRQ तक के फ्लो के रूप में व्यवस्थित किया गया है
  • मुख्य tuning items burst handling, CPU usage, latency, और drop observation से जुड़े हैं
    • rx, tx ring buffer ऐसे queue हैं जो connection burst को बिना drop के प्राप्त करने के लिए होते हैं; इन्हें बढ़ाने पर latency बढ़ सकती है
    • rx-usecs, tx-usecs, rx-frames, tx-frames hard IRQ होने से पहले की प्रतीक्षा अवधि और frame count को दर्शाते हैं; ये CPU usage और hard IRQ को कम कर सकते हैं और latency की कीमत पर throughput बढ़ा सकते हैं
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog NAPI polling cycle और ingress qdisc throughput से संबंधित हैं
    • txqueuelen और default_qdisc OUTPUT side queue और default queuing discipline से संबंधित हैं
  • जाँच, बदलाव और monitoring मुख्य रूप से ethtool, sysctl, ip, tc, और /proc files पर आधारित हैं
    • उदाहरण: ring buffer जाँच ethtool -g ethX, बदलाव ethtool -G ethX rx value tx value
    • उदाहरण: net.core.netdev_budget_usecs जाँच sysctl net.core.netdev_budget_usecs, बदलाव sysctl -w net.core.netdev_budget_usecs value
    • उदाहरण: default_qdisc जाँच sysctl net.core.default_qdisc, monitoring tc -s qdisc ls dev ethX
  • TCP buffer items में tcp_rmem, tcp_wmem, tcp_moderate_rcvbuf शामिल हैं, और tcp_moderate_rcvbuf सेट होने पर TCP receive buffer size को अपने-आप adjust करने की कोशिश करता है
  • TCP state और congestion control से जुड़े items के रूप में net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies, tcp_slow_start_after_idle को भी साथ में व्यवस्थित किया गया है
  • Linux के अंदरूनी नेटवर्क tracing को perf से देखा जा सकता है, और उदाहरण कमांड का रूप perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null है
  • testing और monitoring tools के रूप में iperf3, vegeta, netdata, prometheus + grafana + node exporter full dashboard के संयोजन का सुझाव दिया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-07
Hacker News की राय

  • Ubuntu Linux के default में net.ipv4.tcp_rmem करीब 6MB है, जबकि net.core.rmem_max करीब 1MB है, जिससे अजीब स्थिति बनती है
    default TCP socket जरूरत पड़ने पर TCP receive window को 6MB तक बढ़ा सकता है, लेकिन user-space app अगर setsockopt SO_RCVBUF कॉल करे, तो जो socket पहले से 6MB तक जा सकता था वह भी अधिकतम 1MB तक सीमित हो जाता है
    6MB से 4MB पर घटाने की कोशिश करें तो भी नतीजा 1MB हो जाता है—यह बहुत अजीब लगता है, और यही बात SO_SNDBUF/wmem पर भी लागू होती है
    ऐसा लगता है कि Linux इन options की priority को लेकर उलझा हुआ है; समझ नहीं आता कि core.rmem_max को बड़ा रखकर उसे authoritative निर्देश क्यों नहीं बनाया जाता, क्या इसके पीछे कोई ऐतिहासिक वजह है

    • अगर मकसद जरूरत से ज्यादा buffered data की मात्रा सीमित करना है, तो SO_SNDBUF/wmem के बजाय TCP_NOTSENT_LOWAT को कम किया जा सकता है
      यह bandwidth-delay product (BDP) के लिए जरूरी मात्रा से ऊपर अतिरिक्त buffer होने वाली मात्रा को सीमित करता है
    • net.ipv4.tcp_rmem का maximum kernel द्वारा की जाने वाली auto tuning की सीमा है
      जैसे ही आप SO_RCVBUF सेट करते हैं, उस socket में auto tuning हट जाती है, और net.core.rmem_max maximum बन जाता है
      Documentation/networking/ip-sysctl.rst में यह काफी साफ तौर पर documented है

  • यह बेहतरीन है, खासकर इसलिए कि इसमें packet के NIC में आने के बाद user space तक पहुंचने के सभी चरण दिखाए गए हैं
    network performance के बारे में एक बात और जोड़नी हो तो, कई CPUs वाले system में बड़े servers में आम NUMA allocation को जरूर check करना चाहिए
    अगर network card एक CPU की तरफ है और application दूसरे CPU पर चल रहा है, तो performance पर असर पड़ सकता है

  • Linux के default congestion control net.ipv4.tcp_congestion_control को सिर्फ bbr में बदल देने से भी कुछ स्थितियों में जबरदस्त फर्क पड़ता है
    शायद दूरी, बीच-बीच में packet loss और jitter, और encapsulation होने पर यह खास तौर पर सच लगता है
    पिछले 1 साल में मैंने client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host flow की समस्या debug की; औसतन theoretical maximum throughput के 20% से ऊपर जाना मुश्किल था, और समय बीतने पर connection लगभग रुक-सा जाने जितना धीमा हो जाता था
    connection को बार-बार जबरन बंद करने जैसे temporary workaround इस्तेमाल कर रहा था, फिर congestion control को bbr में बदलने पर theoretical maximum के करीब throughput और stable connection मिला, और यह बदलाव Wireguard के दोनों सिरों पर जरूरी था

    • BBR अलग है क्योंकि यह loss को congestion signal के रूप में इस्तेमाल नहीं करता
      ज्यादातर TCP stacks पहली बार loss दिखते ही sending window को आधा या काफी कम कर देते हैं, इसलिए अगर VPN में loss है, या 10Mb/s VPN uplink पर 1Gb/s से बड़ा burst भेजा जाए, तो TCP loss देखकर बहुत पीछे हट जाता है
      BBR bottleneck bandwidth खोजने की कोशिश करता है; यह round-trip time मापता है और RTT बढ़ने तक transmission rate बढ़ाता है
      RTT बढ़ने पर यह मानता है कि path के सबसे संकरे हिस्से में queue जमा हो रही है, फिर queue खाली होकर RTT normal होने तक transmission rate घटाता है, कुछ समय तक उसी speed से भेजता है, और फिर थोड़ा बढ़ाकर फिर से देखता है
      कुछ साल पहले 10Mb/s cable uplink से 1Gb/s symmetric fiber line पर जाने के बावजूद company VPN upload करीब 5Mb/s पर ही अटका रहा और यह खीझ पैदा कर रहा था; FreeBSD में RACK TCP या BBR पर बदलने से यह VPN limit के करीब, यानी लगभग 40Mb/s तक, करीब 8 गुना बढ़ गया
    • BBRv1 टूटा हुआ है, इसलिए इसे public internet पर इस्तेमाल नहीं करना चाहिए
      किसी एक जादुई value को सेट कर देने से सब बेहतर हो जाएगा—ऐसी copy-paste cargo-cult performance tuning मूल लेख जो कहना चाहता है उसके ठीक उलट है
      अच्छी बात है कि Google BBRv3 को upstream कर रहा है, इसलिए जल्द ही स्थिति बेहतर होगी
    • congestion control data भेजने वाली side से receive करने वाली side की दिशा में काम करता है
      अगर आप सिर्फ एक direction की performance सुधारना चाहते हैं, तो Wireguard के दोनों ends बदलना जरूरी नहीं है
      BBRv1 को लेकर मैं बाकी comments से सहमत हूं, और Linux kernel का cubic implementation ज्यादातर applications में काफी अच्छा काम करता है

  • सोच रहा हूँ कि Wi‑Fi adapters पर भी performance tuning का मतलब बनता है या नहीं
    desktop पर सिर्फ features बंद करने के अलावा i210 और i225 Ethernet issues को ठीक करने का कोई तरीका है या नहीं, यह भी जानना चाहता हूँ
    आजकल सबसे common NIC शायद ये दोनों ही लगते हैं, लेकिन common network hardware और drivers में इतनी खामियाँ क्यों हैं, यह समझ नहीं आता
    RISC-V में मेरी काफ़ी रुचि है, लेकिन क्या पूरी तरह open और सही NIC से शुरुआत करना बेहतर नहीं होगा?
    अगर वह i210 से सस्ता हुआ तो आखिरकार लोग उसे शामिल करेंगे, हालांकि शायद यह असंभव भी हो सकता है

    • अगर आप maximum local network throughput का 10–20% sacrifice कर सकते हैं, तो Wi‑Fi fairness को काफ़ी बढ़ा सकते हैं, ping time बेहतर कर सकते हैं और bufferbloat घटा सकते हैं
      हालांकि Wi‑Fi में random ping spikes फिर भी होते रहते हैं
      https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... पर AQM enable करने और tuning, throughput व latency के बीच trade-off पर एक बड़ा thread है
    • i225 तो बस खराब चीज़ है, लेकिन i210 पर performance शानदार मिलती है
      उसी दौर के CPU पर 1Gb कोई बहुत मुश्किल स्तर भी नहीं है, और i210 4 queues देता है
      i210 को लेकर शिकायत क्या है, यह जानना चाहूँगा
    • मैं i225 onboard वाले motherboard का इस्तेमाल कर रहा था, लेकिन PCIe I350 खरीदकर समस्या हल कर ली

  • चित्रों में समझाया गया Linux network queues का overview इतना अच्छा है कि मन करता है इसे कहीं दीवार पर चिपका दूँ
    Brendan की Systems Performance किताब भी Linux network performance आदि को अच्छे से cover करती है, और इसका 2nd edition भी आ चुका है
    दोनों editions बेहतरीन हैं, लेकिन 2nd edition मुख्य रूप से Linux पर focus करता है, जबकि 1st edition में Solaris भी शामिल है
    हाल में उसी author की BPF Performance Tools किताब भी आई है
    [1] Systems Performance: Enterprise and the Cloud, 2nd Edition (2020)
    https://www.brendangregg.com/systems-performance-2nd-edition...
    [2] BPF Performance Tools:
    https://www.brendangregg.com/bpf-performance-tools-book.html

  • लेख को सरसरी तौर पर पढ़ना भी मज़ेदार था, और research व structure बहुत अच्छे थे
    हालांकि सोचता हूँ कि Linux network parameters को नियमित रूप से tune करने वाले लोग असल में कौन हैं

  • इस document में कहीं साफ़ तौर पर TCP लिखना चाहिए लगता है
    content बहुत ज़्यादा TCP-related concerns पर केंद्रित है, और लोग मुख्य रूप से TCP इस्तेमाल करते हैं, इसलिए यह उपयोगी तो है
    लेकिन default UDP tuning values बेहद कम हैं, और वह हिस्सा साफ़ तौर पर missing है

    • UDP tuning के लिए कोई अच्छी resource है क्या, यह जानना चाहूँगा

  • इसी तरह की चीज़ों को cover करने वाले videos या series की recommendation चाहिए
    सामान्य networking resources बहुत हैं, लेकिन Linux के specific implementation को cover करने वाली सामग्री ढूँढना मुश्किल रहा

    • microcontroller perspective से भी ऐसी ही material चाहिए
      microcontroller के लिए एक simple TCP echo server बनाकर देखना चाहता हूँ, लेकिन ज़्यादातर examples सिर्फ vendor की अपनी TCP library इस्तेमाल करते हैं और router से सीधे connection setup और establish करने की process लगभग समझाते ही नहीं