Linux नेटवर्क प्रदर्शन की अंतिम गाइड

 (ntk148v.github.io)
5 पॉइंट द्वारा GN⁺ 2024-07-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux नेटवर्क performance tuning का मतलब packet के NIC ring buffer, IRQ, NAPI, softIRQ, qdisc, TCP buffer से होकर application socket तक जाने वाले flow को bottleneck के हिसाब से समझना है
  • receive path में NIC DMA के ज़रिए packet को RAM में लिखता है और HardIRQ generate करता है; driver NAPI को schedule करता है ताकि NET_RX_SOFTIRQ में ring buffer खाली करने के बाद उसे IP/TCP layer और socket receive buffer तक भेजा जा सके
  • ethtool, /proc/net/softnet_stat, ss, netstat, sysctl observation और tuning के शुरुआती tools हैं; interrupt coalescing, IRQ affinity, RSS/RPS/RFS/aRFS, netdev_budget, netdev_max_backlog, txqueuelen, TCP read/write buffers मुख्य tuning axes हैं
  • सभी systems पर लागू होने वाली कोई single setting नहीं है; ring buffer बढ़ाने से drops कम हो सकते हैं लेकिन latency बढ़ सकती है, और interrupt coalescing CPU usage व HardIRQ को घटाता है लेकिन latency cost ला सकता है
  • high-performance packet processing PACKET_MMAP, DPDK, PF_RING, XDP/AF_XDP जैसे options तक expand होती है, लेकिन kernel bypass, zero-copy और in-kernel fast path—हर तरीके में hardware dependency, CPU occupancy और kernel version requirements अलग होते हैं

Linux receive path: NIC से socket तक

  • network device packet arrival बताने के लिए IRQ generate करता है, और Linux की IRQ mapping /proc/interrupts में stored होती है
  • IRQ handler बहुत high priority पर चलता है और कभी-कभी additional IRQ generation को रोकता है, इसलिए driver लंबे कामों को IRQ context के बाहर defer करता है
  • इस deferred processing में softIRQ इस्तेमाल होता है, और network receive processing में हर CPU के लिए ksoftirqd/<cpu-number> kernel thread, softnet_data, poll_list बनाए जाते हैं
  • net_dev_init NET_RX_SOFTIRQ को softIRQ system में register करता है, और उसका handler net_rx_action होता है

  • packet arrival और NAPI processing

    • NIC network से मिले data को DMA के ज़रिए RAM के ring buffer में लिखता है
    • कुछ NIC कई ring buffers वाले multiqueue NIC होते हैं
    • जब NIC HardIRQ generate करता है, तो driver का IRQ handler चलता है
    • driver NIC का IRQ clear करता है और napi_schedule call करके NAPI softIRQ poll loop शुरू करता है
    • napi_schedule driver के NAPI poll structure को current CPU की poll_list में जोड़ता है और softIRQ pending bit set करता है
    • जब ksoftirqd __do_softirq call करता है, तो pending NET_RX_SOFTIRQ का handler net_rx_action execute होता है

  • GRO और protocol stack में entry

    • net_rx_action NAPI poll list check करता है, और budget व elapsed time को जांचता है ताकि softIRQ CPU को monopolize न करे
    • driver का poll function RAM के ring buffer से packets harvest करता है
    • packets napi_gro_receive को दिए जाते हैं
    • GRO(Generic Receive Offloading) software-based offloading technique है, जो छोटे packets को बड़े packets में reassemble करके application को process करने वाले packets की संख्या घटाती है
    • अगर GRO packet को hold नहीं करता, तो वह netif_receive_skb के ज़रिए protocol stack में ऊपर जाता है

  • RPS enabled है या नहीं, उसके आधार पर branch

    • जब RPS disabled हो:
      • netif_receive_skb data को __netif_receive_core तक भेजता है
      • __netif_receive_core data को tap और registered protocol layer handlers तक भेजता है
    • जब RPS enabled हो:
      • netif_receive_skb data को enqueue_to_backlog तक भेजता है
      • packet per-CPU input queue में जाता है
      • remote CPU का NAPI structure उस CPU की poll_list में जोड़ा जाता है, और IPI queue होता है जो remote CPU के softIRQ thread को जगाता है
      • remote CPU का ksoftirqd process_backlog poll function के ज़रिए CPU input queue से packets harvest करता है

  • IP, TCP, socket receive buffer

    • packet IPv4 layer में ip_rcv से receive होता है और netfilter व routing optimization से गुजरता है
    • current system के लिए destined data UDP या TCP जैसे upper protocol layers को भेजा जाता है
    • TCP receive path में tcp_v4_rcv, TCP finite state machine और socket lookup के बाद data receive buffer में जाता है
    • receive buffer size tcp_rmem rules follow करता है
    • अगर tcp_moderate_rcvbuf enabled हो, तो kernel receive buffer को automatically tune करता है
    • tcp_rmem में TCP socket receive buffer के minimum, default और maximum values होती हैं
    • SO_RCVBUF इस्तेमाल करने पर उस socket के receive buffer की automatic tuning disabled हो जाती है
    • net.core.rmem_max TCP receive buffer size की upper limit है; larger window ACK भेजने से पहले ज्यादा data transmit करवाकर latency घटा सकती है और throughput बढ़ा सकती है

Linux transmit path: application से NIC तक

  • transmit path receive से सरल है, लेकिन qdisc, TCP write buffer, DMA और IRQ इसमें शामिल होते हैं
  • जब application sendmsg जैसी call से message भेजती है, तो TCP transmit path skb_buff allocate करता है
  • packet tcp_wmem size के socket write buffer में जाता है
    • tcp_wmem में TCP socket transmit buffer के minimum, default और maximum values होती हैं
    • kernel TCP transmit buffer size को minimum और maximum के बीच dynamically tune करता है
    • SO_SNDBUF इस्तेमाल करने पर उस socket के transmit buffer की automatic tuning disabled हो जाती है
    • net.core.wmem_max TCP transmit buffer size की upper limit है
  • TCP header और IP header बनाए जाते हैं, फिर LOCAL_OUT, routing, POST_ROUTING, fragmentation से गुजरने के बाद dev_queue_xmit से L2 transmit function call होता है
  • output qdisc txqueuelen length और default_qdisc algorithm का इस्तेमाल करता है
  • driver packet को TX ring buffer में डालता है, और tx-usecs timeout या tx-frames के बाद NET_TX_SOFTIRQ perform करता है
  • NIC DMA के ज़रिए RAM से packet लाकर transmit करता है, और transmit complete होने के बाद HardIRQ generate करता है
  • driver इस IRQ को process करता है और RAM free करने के लिए NAPI poll system को schedule करता है

अवलोकन टूल और बुनियादी जाँच बिंदु

  • /proc/net/softnet_stat

    • /proc/net/softnet_stat की हर लाइन एक CPU कोर को दर्शाती है और CPU0 से शुरू होती है
    • हर कॉलम के आँकड़े hexadecimal में दिए जाते हैं
    • पहला कॉलम interrupt handler द्वारा प्राप्त frames की संख्या है
    • दूसरा कॉलम netdev_max_backlog से अधिक होने के कारण drop हुए frames की संख्या है
    • तीसरा कॉलम उन बारों की संख्या है जब प्रोसेस करने का काम बाकी था, लेकिन ksoftirqd ने netdev_budget या CPU समय खत्म कर दिया
    • बाकी कॉलम Linux version के अनुसार बदल सकते हैं

  • /proc/net/sockstat और ss

    • /proc/net/sockstat में mem field देखें
    • यह मान सभी sockets के sk_buff->truesize को जोड़कर निकाला जाता है
    • ss socket statistics dump करने का टूल है, और netstat जैसी जानकारी के साथ अधिक TCP और state जानकारी दिखा सकता है
    • ss -tm का उपयोग TCP sockets की memory usage जाँचने के लिए किया जाता है
    • rmem_alloc: received packets के लिए allocated memory
    • rcv_buf: received packets के लिए allocate की जा सकने वाली कुल memory
    • wmem_alloc: layer 3 को पहले ही भेजे जा चुके outgoing packets में उपयोग हुई memory
    • snd_buf: outgoing packets के लिए allocate की जा सकने वाली कुल memory
    • wmem_queued: अभी layer 3 को नहीं भेजे गए outgoing packets के लिए allocated memory
    • sock_drop: socket तक demultiplex होने से पहले drop हुए packets की संख्या

  • netstat और sysctl

    • netstat एक command-line tool है जो open network connections और protocol stack statistics output करता है, और /proc/net/ file system से जानकारी लाता है
    • /proc/net/dev: device information
    • /proc/net/tcp: TCP socket information
    • /proc/net/unix: Unix domain socket information
    • sysctl, /proc file system में सीधे values लिखने के बजाय system और network settings बदलने की command है
    • sysctl -w variable=value temporary changes के लिए उपयोग करें, और permanent changes के लिए /etc/sysctl.conf को modify करने के बाद sysctl -p से apply करें

NIC ring buffer और interrupt tuning

  • NIC ring buffer

    • RX ring buffer RAM में स्थित fixed-size FIFO circular buffer है
    • ring buffer खुद packet data नहीं रखता, बल्कि DMA के जरिए RAM में आए skb की ओर इशारा करने वाले descriptors रखता है
    • अगर drops या overrun दिखें तो queue size बढ़ाया जा सकता है, लेकिन side effect के तौर पर latency बढ़ सकती है
    • कई मामलों में receive buffer size बढ़ाने मात्र से packet drops रोके जा सकते हैं, और kernel को buffer खाली करने के लिए थोड़ा और समय मिल जाता है
    • जाँच और बदलाव ethtool से किए जाते हैं
    • ethtool -g eth3: मौजूदा RX/TX ring size और maximum value देखें
    • ethtool -G eth3 rx 8192 tx 8192: RX/TX buffers को maximum value तक बढ़ाएँ
    • ethtool -S eth3 और err, drop, over, miss, timeout, reset, collis जैसे counters से monitor करें

  • hardware interrupt coalescing

    • NIC, rx-usecs timeout या rx-frames condition तक RX ring buffer में packet references जमा करने के बाद HardIRQ generate कर सकता है; इसे Interrupt coalescence कहा जाता है
    • बहुत जल्दी interrupts होने पर kernel के चल रहे काम बार-बार रुकते हैं, जिससे system performance खराब होती है
    • बहुत देर से interrupts होने पर NIC traffic को पर्याप्त तेजी से खाली नहीं कर पाता, जिससे overwrite और traffic loss हो सकता है
    • interrupt coalescing tuning CPU usage और HardIRQ को घटाकर throughput बढ़ा सकती है, लेकिन latency cost आ सकती है
    • ethtool -c eth3 से coalesce parameters देखें, और ethtool -C eth3 adaptive-rx off rx-usecs 0 rx-frames 0 की तरह बदल सकते हैं
    • adaptive mode में card traffic pattern और kernel receive pattern देखकर coalescing settings को dynamically estimate करता है

IRQ affinity और CPUs के बीच load balancing

  • IRQ affinity

    • IRQ में smp_affinity property होती है, जो उन CPU cores को define करती है जो उस IRQ का ISR चला सकते हैं
    • interrupt affinity और application thread affinity को किसी खास CPU core से match करने पर cache line sharing के कारण application performance बेहतर हो सकती है
    • default रूप से इसे irqbalance daemon control करता है
    • manual tuning से पहले irqbalance को रोकना चाहिए
    • /proc/irq/<IRQ_NUMBER>/smp_affinity में CPU cores को दर्शाने वाला hexadecimal bitmask store होता है
    • 4-core server में default value f का मतलब है कि सभी CPUs IRQ process कर सकते हैं
    • echo 1 > /proc/irq/32/smp_affinity केवल CPU0 का उपयोग कराता है
    • 32 cores से अधिक वाले systems में comma से 32-bit groups अलग किए जाते हैं
    • IRQ affinity केवल बहुत specific configurations और पहले से defined workloads में ही performance बढ़ा सकती है, और दो धार वाली तलवार हो सकती है

  • RSS

    • तेज NIC पर single queue और single CPU से ही packets receive करने पर एक core data processing की पूरी जिम्मेदारी उठा सकता है और बाकी cores idle रह सकते हैं
    • RSS(Receive-side scaling) एक NIC technology है, जिससे NIC traffic को कई receive/transmit queues में distribute करता है
    • NIC source/destination IP और TCP/UDP source/destination port के आधार पर hash calculate करता है, एक ही flow के packets को एक single queue में assign करता है, और flows को queues में समान रूप से distribute करता है
    • RSS multiprocessing environment में parallel receive processing का लाभ देता है
    • Linux kernel documentation के अनुसार, RSS को तब enable करना चाहिए जब latency महत्वपूर्ण हो या receive interrupt processing bottleneck हो; low-latency networking में system CPU count के बराबर queues allocate करने वाली setting optimal होती है

  • RPS, RFS, aRFS

    • RPS(Receive Packet Steering) RSS के software implementation के करीब है
    • जहाँ RSS hardware interrupt handler चलाने के लिए queue और CPU चुनता है, वहीं RPS interrupt handler के ऊपर protocol processing करने वाला CPU चुनता है
    • CONFIG_RPS जरूरी है और SMP में default रूप से enabled होता है
    • configuration /sys/class/net/<dev>/queues/rx-<n>/rps_cpus के CPU bitmap से किया जाता है
    • अगर RSS मौजूद है तो यह अनावश्यक हो सकता है, लेकिन CPU count queue count से अधिक हो तो उपयोगी हो सकता है
    • RFS(Receive Flow Steering) RPS को application locality तक extend करता है
    • RPS flow-based तरीके से packets distribute करता है, लेकिन user-space application किस CPU पर चल रही है, इसे consider नहीं करता
    • RFS global flow-to-CPU table rps_sock_flow_table maintain करता है
    • net.core.rps_sock_flow_entries से table size tune किया जा सकता है
    • per-queue rps_dev_flow_table का उपयोग scheduler द्वारा application को नए CPU पर move करने पर बचे हुए packets के कारण order बिगड़ने की समस्या घटाने के लिए किया जाता है
    • aRFS(Accelerated RFS) RFS के लिए hardware-accelerated load balancing mechanism है
    • यह packets को data consume करने वाले thread के पास वाले CPU पर सीधे भेजता है, इसलिए RFS से बेहतर performance दे सकता है
    • NIC का ndo_rx_flow_steer, ntuple filtering, CONFIG_RFS_ACCEL जरूरी है
    • CPU और queue की mapping हर receive queue की IRQ affinity से automatically derived होती है, इसलिए extra configuration की जरूरत नहीं होती

softIRQ, qdisc, TCP buffer tuning

  • softIRQ budget

    • NAPI polling routine को netdev_budget_usecs, netdev_budget, dev_weight से सीमित किया जाता है ताकि softIRQ CPU पर पूरी तरह कब्ज़ा न कर ले
    • net.core.netdev_budget का default value 300 है, जिसका मतलब है कि softIRQ process के CPU से हटने से पहले NIC से 300 messages खाली किए जाते हैं
    • net.core.netdev_budget_usecs एक NAPI polling cycle के अधिकतम microseconds की संख्या है
    • net.core.dev_weight NAPI interrupt में kernel द्वारा process किए जा सकने वाले प्रति-CPU अधिकतम packets की संख्या है
    • /proc/net/softnet_stat में पहले column के अलावा दूसरे columns बढ़ें तो budget बदलने की ज़रूरत हो सकती है, हालांकि छोटी बढ़ोतरी सामान्य हो सकती है

  • ingress qdisc और netdev_max_backlog

    • netdev_max_backlog kernel की internal queue है जहां NIC से receive होने के बाद IP/TCP जैसे protocol stack processing से पहले traffic रखा जाता है
    • हर CPU core के लिए एक backlog queue होती है
    • अगर interface kernel की processing speed से तेज़ packets receive करता है, तो INPUT-side queue netdev_max_backlog तक भर जाती है, और उससे अधिक होने पर packets drop हो जाते हैं
    • default value 1000 है, जो कई 1Gbps interfaces या एक 10Gbps interface के लिए कम पड़ सकती है
    • /proc/net/softnet_stat का दूसरा column backlog queue overflow से बढ़ने वाला counter है
    • value बदलने के लिए sysctl -w net.core.netdev_max_backlog <value> का उपयोग करें

  • egress qdisc, txqueuelen, default_qdisc

    • txqueuelen network interface device की kernel transmit queue में अनुमति दिए गए packets की संख्या set करता है
    • default value interface driver के अनुसार 1000 हो सकती है
    • इसे ifconfig <interface> txqueuelen value से बदलें, और ip -s link में RX/TX dropped जांचें
    • default_qdisc network device पर उपयोग होने वाली default queuing discipline है
    • pfifo_fast की जगह sfq, codel, fq_codel जैसे विकल्प specify किए जा सकते हैं
    • tc -s qdisc ls dev <interface> में dropped, overlimits, requeues जैसे metrics देखें

  • TCP read/write buffer और connection queues

    • tcp_rmem और tcp_wmem क्रमशः TCP receive और send buffers के minimum, default, maximum values define करते हैं
    • बदलाव इस तरह करें
      • sysctl -w net.ipv4.tcp_rmem="min default max"
      • sysctl -w net.ipv4.tcp_wmem="min default max"
    • buffer usage status देखने के लिए /proc/net/sockstat का उपयोग करें
    • Accept queue और SYN queue net.core.somaxconn और net.ipv4.tcp_max_syn_backlog से प्रभावित होती हैं
    • net.core.somaxconn listen() के backlog parameter की upper limit है, और इस value को बदलने पर application को भी compatible value पर बदलना होगा
    • net.ipv4.tcp_syncookies SYN flood attack protection के लिए उपयोगी SYN cookie को on या off करता है
    • net.ipv4.tcp_congestion_control नई connections के लिए इस्तेमाल होने वाला congestion control algorithm set करता है

NUMA और network performance

  • NUMA(Non-uniform memory access) ऐसी memory architecture है जिसमें processor local memory को non-local memory की तुलना में तेज़ access कर सकता है
  • network processing में CPU को ring buffer memory access करनी होती है, इसलिए NUMA locality network performance को प्रभावित कर सकती है
  • NUMA CPU, memory और devices को कई nodes में बांटता है, और तेज़ interconnect तथा common OS वाले कई छोटे computers की तरह काम करता है
  • NUMA systems में tuning का लक्ष्य device के interrupts को उसी single node के CPU cores पर collect करना होता है जिससे वह device संबंधित है
  • हालांकि NUMA systems real-time applications के साथ ठीक से interact नहीं कर सकते और अप्रत्याशित event delays पैदा कर सकते हैं
  • NUMA node को /sys/devices/system/node/node* से जांचें
  • device locality को /sys/class/net/<interface>/device/numa_node से जांचें
    • -1 का मतलब है कि hardware platform वास्तविक NUMA नहीं है, या kernel NUMA का अनुकरण कर रहा है, या device में NUMA locality नहीं है
  • Linux kernel 2.5 से NUMA support करता है, और RedHat व Debian-based distributions numactl, numad provide करते हैं
  • numad system topology और resource usage monitor करता है, और पर्याप्त बड़ी memory तथा CPU load वाले processes को efficient NUMA locality में place करने की कोशिश करता है

तेज़ पैकेट प्रोसेसिंग के विकल्प

  • AF_PACKET v4 और PACKET_MMAP

    • AF_PACKET v4 Linux का तेज़ packet interface है, जो data path में system call हटाता है और मूल रूप से copy-mode का उपयोग करता है
    • PACKET_ZEROCOPY का उपयोग करने पर DMA packet buffer को user space में map करने वाला true zero-copy mode इस्तेमाल किया जा सकता है
    • सामान्य file read के बाद socket send path में user mode और kernel mode के बीच context switch और कई बार data copy की ज़रूरत होती है
    • zero-copy redundant data copy हटाकर performance बढ़ाता है
    • PACKET_MMAP तेज़ packet sniffing के लिए Linux API है
    • यह user space और kernel द्वारा साझा किया गया mmapped ring buffer देता है
    • send/receive packets में system call और user space·kernel के बीच copy को कम करता है

  • DPDK

    • DPDK(Data Plane Development Kit) तेज़ packet processing के लिए user-space libraries और driver framework है
    • इसका लक्ष्य NIC और user application के बीच network packets को native speed पर भेजना-प्राप्त करना है
    • इसका target 10Gb या 40Gb NIC हैं, और speed सबसे महत्वपूर्ण मानदंड है
    • यह network stack नहीं, बल्कि packet forwarding पर focus करता है
    • जब DPDK NIC को control करता है, तो सारा traffic kernel को bypass करता है, और वह NIC kernel में दिखाई नहीं देता
    • port को Linux kernel driver से unbind किया जाता है और vfio_pci, igb_uio, uio_pci_generic जैसे drivers से manage किया जाता है
    • इसके बाद application और NIC के बीच communication DPDK PMD संभालता है
    • बड़े memory chunk allocate करने के लिए DPDK में hugepages configuration की ज़रूरत होती है
    • मुख्य components:
      • EAL: environment differences को छिपाने वाला generic interface
      • librte_ring: lockless multi-producer, multi-consumer FIFO API
      • librte_mempool: memory object pool allocation
      • librte_mbuf: network packets रखने वाले buffers बनाना·modify करना
      • librte_timer: asynchronous function execution के लिए timer service
      • PMD: ऐसा driver जिसमें interrupt के बजाय CPU लगातार NIC को poll करता है
    • limitations:
      • hardware dependency अधिक है
      • PMD चलाने के लिए CPU core dedicated allocate करना पड़ता है और यह 100% CPU उपयोग करता है

  • PF_RING

    • PF_RING एक Linux kernel module और user-space framework है, जो high speed पर packets process करता है और packet-processing applications को consistent API देता है
    • PF_RING Linux NAPI से NIC पर packets poll करता है
    • NAPI NIC से PF_RING circular buffer में packets copy करता है, और user-space application ring से packets पढ़ता है
    • इस structure में application और NAPI नाम के दो poller होते हैं, इसलिए CPU cycles polling में खर्च होते हैं
    • फायदा यह है कि incoming packets को एक साथ कई rings में distribute किया जा सकता है
    • modular structure के कारण ZC module, FPGA-based card module, Stack module, Timeline module, Sysdig module जैसे additional components इस्तेमाल किए जा सकते हैं
    • PF_RING ने packet capture और userland forwarding की cost घटाई है, लेकिन kernel द्वारा NIC से ring में copy करने और userland द्वारा ring से पढ़कर process करने वाली two-actor structure के कारण optimal performance की एक सीमा है
    • PF_RING 7.5 से AF_XDP adapter support शामिल करता है

  • XDP और AF_XDP

    • XDP(eXpress Data Path) Linux network data path में packets को शुरुआती चरण में intercept करने वाली eBPF implementation है
    • XDP, SKB allocation से पहले, device driver RX function के अंदर RX packet page को directly process करता है
    • eBPF kernel में चलने वाला user-defined sandboxed bytecode है
    • यह 11 64-bit registers और 512-byte stack का उपयोग करता है
    • LLVM backend से C, Lua, Go, P4, Rust आदि से eBPF में compile किया जा सकता है
    • यह in-kernel verifier और JIT compiler देता है, और map, tail call, helper जैसी सुविधाएँ support करता है
    • XDP use cases:
      • DoS mitigation के लिए pre-stack filtering
      • forwarding और load balancing
      • GRO जैसी batching techniques
      • flow sampling और monitoring
      • ULP processing
    • XDP kernel bypass नहीं है, बल्कि kernel stack के अंदर fast path है, और TCP/IP stack को replace नहीं करता
    • dedicated hardware की ज़रूरत नहीं है, लेकिन multi-queue NIC, TX/RX checksum offload, RSS, TSO जैसी requirements होती हैं
    • DPDK की तुलना में XDP के फायदे:
      • busy polling या interrupt driven networking में से चुना जा सकता है
      • huge pages की ज़रूरत नहीं होती
      • special hardware requirements नहीं हैं
      • dedicated CPU अनिवार्य नहीं है
      • 3rd party userspace application से packets को kernel में फिर से inject करने की ज़रूरत नहीं होती
      • network hardware access के लिए नए security model की ज़रूरत नहीं होती
      • 3rd party code/licensing की ज़रूरत नहीं होती
    • AF_XDP Linux 4.18 में पेश किया गया नया socket type है
    • kernel को पूरी तरह bypass किए बिना kernel functions का उपयोग करके DPDK या AF_PACKET जैसी structure बनाई जा सकती है
    • XDP program eBPF से frame को user-space memory buffer में redirect कर सकता है
    • DMA transfer user-space memory का उपयोग करके zero-copy support करता है
    • AF_PACKET की तुलना में 3~20 गुना performance improvement हासिल किया जा सकता है
    • limitations:
      • यह अपेक्षाकृत नया project है
      • पूरी support के लिए Linux kernel 5.4 या उससे ऊपर की ज़रूरत होती है

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

1 टिप्पणियां

 
GN⁺ 2024-07-29
Hacker News की राय

  • अगर यह सामग्री कुछ हफ्ते पहले देख ली होती, तो शायद बहुत काम आती
    डेटा सेंटरों के बीच L2 लिंक एन्क्रिप्शन करने के लिए कई vendors से hardware appliance के quotes लिए थे, लेकिन लागत बहुत ज्यादा लगी, इसलिए खुद बनाकर देखा
    सामान्य-purpose hardware पर WireGuard overlay network के ऊपर Ethernet frames चलाकर 10Gbps देने जैसा setup बनाया, और करीब दस दिन के काम के बाद सबसे सस्ते प्रस्ताव से लगभग 70% और सबसे महंगे प्रस्ताव से लगभग 95% सस्ते में लागू कर लिया, लेकिन इसके लिए काफी बारीक documentation पढ़ना और experiments करने पड़े
    इस लेख की सामग्री से मैं अपनी समझ सही है या नहीं validate करना चाहता हूं, और पहली नजर में यह promising और comprehensive लगता है

    • जिज्ञासा है कि use case क्या था, जिसमें L3 tunnel पर्याप्त नहीं था
    • अगर code share कर सकें तो देखना चाहूंगा। यह implementation कैसे किया, इसे लेकर बहुत उत्सुक हूं

  • अगर tune किए जा सकने वाले values इतने ज्यादा हैं, तो लगता है auto-tuning software बनाने लायक बात हो सकती है
    whitelist में मौजूद parameters में से random चुनकर allowed range के भीतर थोड़ा ऊपर या नीचे करना, कुछ समय तक performance मापना, फिर खराब हो तो rollback और बेहतर हो तो और adjust करना—gradient descent जैसी approach संभव लगती है

  • दिलचस्प तो है, लेकिन software engineer के तौर पर लेख में दिए commands को सच में चलाने का मौका बहुत कम मिलता है
    systems ज्यादातर किसी Linux के slimmed-down container में चलते हैं, production systems में shell access नहीं होता, और development या QA environments load वगैरह के मामले में production से इतने अलग होते हैं कि bug reproduce करना आम तौर पर ज्यादा मददगार नहीं होता
    आखिरकार लेख के commands आजमाने का मौका अपने personal system से छेड़छाड़ करते समय ही मिलता है, और अगर platform engineer के रूप में काम करते हों तो यह उपयोगी लगेगा

    • low-level features में से ज्यादातर शायद वैसे भी काम नहीं करेंगे या बेकार होंगे। container network interface implementation आम तौर पर veth pairs से निपटने को मजबूर करता है, और user space में तरह-तरह की अजीब processing करता है
      Kubernetes में जो चीजें मुझे खास पसंद नहीं हैं, उनमें से एक इसका networking model है। यह मानकर चलता है कि केवल एक network card है, और applications इतनी simple हैं कि उन्हें उसके नीचे की layers की जानकारी की जरूरत नहीं
      पूरा networking model simplification और सुधार के लिए 2020s-style में बड़े बदलाव की गुंजाइश रखता दिखता है
    • अगर production से जितना हो सके उतना मिलता-जुलता staging environment हो, तो access वाले production-like environment में experiment और analysis किया जा सकता है, इसलिए स्थिति के हिसाब से मदद मिल सकती है

  • net.core.wmem_max को TCP send buffer size की upper limit बताया गया है, और net.ipv4.tcp_wmem भी है, इसलिए दो बातें जाननी हैं

    1. IPv6 के लिए corresponding value क्यों नहीं है, 2. net.core.wmem_max से इसका अंतर क्या है
    • net.core.wmem_max नाम के मुताबिक maximum value है
      net.ipv4.tcp_wmem तीन values वाला tuple है—minimum, default, maximum—और इसमें specified maximum पहले वाले net.core.wmem_max से अधिक नहीं हो सकता
      TCP एक ऐसा protocol होना चाहिए जो IPv4 पर carry हो या IPv6 पर, समान रहता है
      उदाहरण: https://docs.redhat.com/en/documentation/red_hat_data_grid/7...

  • यहां जो थोड़ा छूट गया है, वह 100Gbps से अधिक throughput की debugging और tuning है
    उस scale पर HTTP serve करते समय आम तौर पर पहला bottleneck memory bandwidth होता है, इसलिए अक्सर kTLS की जरूरत पड़ती है
    AMD μProf जैसे tools debugging में बहुत उपयोगी होते हैं, और kernel व user space में ठीक-ठीक क्या हो रहा है यह समझने के लिए eBPF-based continuous profiling भी मददगार होती है

  • काफी शानदार लगता है। अब तक मेरे career में जब भी performance की जरूरत पड़ी, आम तौर पर शुरुआत kernel bypass से ही की