अनुकूलन Linux प्रति सेकेन्ड १२ लाख JSON अनुरोधहरू प्रशोधन गर्न

वातावरणलाई ट्युनिङ गर्ने विस्तृत निर्देशिका प्रकाशित भएको छ। Linux HTTP अनुरोध प्रशोधनको लागि अधिकतम कार्यसम्पादन प्राप्त गर्न। प्रस्तावित विधिहरूले हामीलाई Amazon EC2 वातावरण (4 vCPUs) मा libreactor पुस्तकालयमा आधारित JSON पार्सरको कार्यसम्पादन मानक Amazon सेटिङहरू अन्तर्गत प्रति सेकेन्ड २२४,००० API अनुरोधहरूबाट बढाउन अनुमति दियो। Linux कर्नेल ४.१४ सँग २ ले अनुकूलन पछि प्रति सेकेन्ड थ्रुपुट १२ लाख अनुरोधहरूमा वृद्धि गर्‍यो (४३६% वृद्धि), र अनुरोध प्रशोधन विलम्बतालाई पनि ७९% ले घटायो। प्रस्तावित विधिहरू libreactor को लागि विशिष्ट छैनन् र nginx, Actix, Netty, र Node.js सहित अन्य HTTP सर्भरहरूसँग काम गर्छन् (libreactor परीक्षणहरूमा प्रयोग गरिएको थियो, किनकि यसमा आधारित समाधानले राम्रो प्रदर्शन प्रदर्शन गरेको थियो)।

आधारभूत अनुकूलनहरू:

• लिब्रेक्टर कोड अप्टिमाइज गर्दै। Techempower किटबाट R18 विकल्पलाई आधारको रूपमा प्रयोग गरिएको थियो, जुन प्रयोग गरिएको CPU कोरहरूको संख्या सीमित गर्न कोड हटाएर सुधार गरिएको थियो (अप्टिमाइजेसनले 25-27% ले कामको गति बढाउन अनुमति दियो), "-O3" विकल्पहरूसँग GCC मा भेला भयो। (५-१०% को बृद्धि) र "-मार्च-नेटिभ" (५-१०%), रिड/राइट कललाई recv/send (5-10%) को साथ बदल्दै र pthreads प्रयोग गर्दा ओभरहेड घटाउँदै (5-10%) । कोड अप्टिमाइजेसन पछि समग्र प्रदर्शन वृद्धि 5% थियो, र थ्रुपुट 10k req/s बाट 2k req/s मा बढ्यो।
• निर्देशनहरूको सट्टा कार्यान्वयनको कारणले हुने कमजोरीहरू विरुद्ध सुरक्षा असक्षम गर्दै। कर्नेल बुट प्यारामिटरहरू "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" प्रयोग गर्नाले कार्यसम्पादन २८% ले बढ्यो, र थ्रुपुट ३४७k req/s बाट ४४६k req/s मा बढ्यो। व्यक्तिगत रूपमा, "nospectre_v1" प्यारामिटर (Spectre v1 + SWAPGS बाट सुरक्षा) बाट लाभ १-२%, "nospectre_v2" (Spectre v2 बाट सुरक्षा) - १५-२०%, "pti=off" (Spectre v3/Meltdown) - ६%, "mds=off tsx_async_abort=off" (MDS/Zombieload र TSX Asynchronous Abort) - ६% थियो। L1TF/Foreshadow आक्रमणहरू (l1tf=flush), iTLB multihit, Speculative Store Bypass र SRBDS विरुद्ध सुरक्षाको लागि सेटिङहरू, जसले कार्यसम्पादनलाई असर गर्दैनन्, अपरिवर्तित छोडिएका थिए, किनकि तिनीहरूले परीक्षण गरिएको कन्फिगरेसनसँग प्रतिच्छेदन गरेनन् (उदाहरणका लागि, तिनीहरू विशिष्ट छन्) KVM, नेस्टेड भर्चुअलाइजेसन र अन्य CPU मोडेलहरू)।
• "auditctl -a never,task" आदेश प्रयोग गरेर अडिटिङ र प्रणाली कल अवरुद्ध गर्ने संयन्त्रहरू असक्षम गर्दै र डकर कन्टेनर सुरु गर्दा "--security-opt seccomp=unconfined" विकल्प निर्दिष्ट गर्दै। समग्र प्रदर्शन वृद्धि 11% थियो, र थ्रुपुट 446k अनुरोध/s बाट 495k अनुरोध/सेकेन्डमा बढ्यो।
• सम्बन्धित कर्नेल मोड्युलहरू अनलोड गरेर iptables/netfilter लाई असक्षम पार्दै। कुनै विशेष सर्भर समाधानमा प्रयोग नगरिएको फायरवाललाई असक्षम पार्ने विचार प्रोफाइलिङ परिणामहरूद्वारा प्रेरित गरिएको थियो, जसले nf_hook_slow प्रकार्यले कार्यान्वयनमा १८% समय खर्च गरेको देखाएको थियो। यो उल्लेख गरिएको छ कि nftables iptables भन्दा बढी कुशल छ, तर Amazon मा Linux iptables प्रयोग गर्न जारी छ। iptables लाई असक्षम पारेपछि, कार्यसम्पादन २२% ले बढ्यो, र थ्रुपुट ४९५k req/s बाट ६०३k req/s मा बढ्यो।
• प्रोसेसर क्यास प्रयोगको दक्षता सुधार गर्न विभिन्न CPU कोरहरू बीच ह्यान्डलरहरूको कम माइग्रेसन। अप्टिमाइजेसनलाई सीपीयू कोर (सीपीयू पिनिङ) र पिनिङ कर्नेल नेटवर्क ह्यान्डलरहरू (साइड स्केलिंग प्राप्त गर्नुहोस्) मार्फत बाइन्डिङ लिब्रेक्टर प्रक्रियाहरूको स्तरमा गरिएको थियो। उदाहरणका लागि, irqbalance असक्षम पारिएको थियो र CPU लाई लामबद्धता स्पष्ट रूपमा /proc/irq/$IRQ/smp_affinity_list मा सेट गरिएको थियो। libreactor प्रक्रिया र आगमन प्याकेटहरूको नेटवर्क लाम प्रशोधन गर्न उही CPU कोर प्रयोग गर्न, सकेट सिर्जना गर्दा SO_ATTACH_REUSEPORT_CBPF फ्ल्याग सेट गरेर जडान गरिएको अनुकूलन BPF ह्यान्डलर प्रयोग गरिन्छ। CPU मा बाहिर जाने प्याकेटहरूको लामहरू बाँध्न, सेटिङहरू /sys/class/net/eth0/queues/tx- परिवर्तन गरिएको छ। /xps_cpus। समग्र प्रदर्शन वृद्धि 38% थियो, र थ्रुपुट 603k req/s बाट 834k req/s मा बढ्यो।
• अवरोध ह्यान्डलिंग र मतदान को उपयोग को अनुकूलन। ENA ड्राइभरमा adaptive-rx मोड सक्षम पार्दै र sysctl net.core.busy_read हेरफेरले 28% ले कार्यसम्पादन बढायो (थ्रुपुट 834k req/s बाट 1.06M req/s मा बढ्यो, र विलम्बता 361μs बाट 292μs मा घट्यो)।
• अनावश्यक नेटवर्क स्ट्याक लकहरू निम्त्याउने प्रणाली सेवाहरू असक्षम पार्दै। dhclient असक्षम पार्दै र स्थापना गर्दै आईपी ​​ठेगानाहरू यो कार्य म्यानुअल रूपमा गर्नाले ६% कार्यसम्पादन वृद्धि भयो, थ्रुपुट १.०६ मिलियन आवश्यकता/सेकेन्डबाट १.१२ मिलियन आवश्यकता/सेकेन्डमा बढ्यो। dhclient को कार्यसम्पादनमा प्रभावको कारण कच्चा सकेट प्रयोग गरेर ट्राफिक विश्लेषण गर्नु हो।
• स्पिन लक लड्दै। sysctl "net.core.default_qdisc=noqueue" र "tc qdisc बदल्नुहोस् dev eth0 root mq" मार्फत नेटवर्क स्ट्याकलाई "noqueue" मोडमा स्विच गर्दा 2% कार्यसम्पादन वृद्धि भयो, र थ्रुपुट 1.12M req/s बाट 1.15M मा बढ्यो। अनुरोध/से।
• "ethtool -K eth0 gro off" आदेशको साथ GRO (जेनेरिक रिसिभ अफलोड) असक्षम गर्ने र sysctl "net.ipv4.tcp_congestion_control=reno" को प्रयोग गरेर रेनोको साथ घन भीड नियन्त्रण एल्गोरिदमलाई प्रतिस्थापन गर्ने जस्ता अन्तिम साना अप्टिमाइजेसनहरू। कुल उत्पादकता वृद्धि 4% थियो। थ्रुपुट 1.15M req/s बाट 1.2M req/s मा बढ्यो।

काम गर्ने अप्टिमाइजेसनको अतिरिक्त, लेखले अपेक्षित कार्यसम्पादन वृद्धिको नेतृत्व नगर्ने विधिहरू पनि छलफल गर्दछ। उदाहरणका लागि, निम्न प्रभावकारी हुन सकेन:

• लिब्रेएक्टरलाई छुट्टै चलाउनु कन्टेनरमा चलाउनु भन्दा प्रदर्शनमा फरक थिएन। Writv लाई पठाएर प्रतिस्थापन गर्ने, epoll_wait मा maxevents बढाउने, र GCC संस्करणहरू र झण्डाहरू प्रयोग गर्दा कुनै प्रभाव परेन (प्रभाव "-O3" र "-march-native" झण्डाहरूमा मात्र देख्न सकिने थियो)।
• कर्नेल अपडेटले कार्यसम्पादनलाई असर गरेन। Linux संस्करण ४.१९ र ५.४ सम्म, SCHED_FIFO र SCHED_RR अनुसूचकहरू प्रयोग गरेर, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 र clocksource=tsc लाई हेरफेर गर्दै।
• ENA ड्राइभरमा, अफलोड मोडहरू (सेगमेन्टेसन, स्क्याटर-गदर, rx/tx चेकसम), "-O3" फ्ल्यागको साथ निर्माण, र ena.rx_queue_size र ena.force_large_llq_header मापदण्डहरू प्रयोग गर्दा कुनै प्रभाव परेन।
• नेटवर्क स्ट्याकमा परिवर्तनहरूले कार्यसम्पादन सुधार गरेन:
  • IPv6 असक्षम गर्नुहोस्: ipv6.disable=1
  • VLAN असक्षम गर्नुहोस्: modprobe -rv 8021q
  • प्याकेज स्रोत जाँच असक्षम पार्नुहोस्
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1 (नकारात्मक प्रभाव)
  • net.ipv4.tcp_sack = १
  • net.ipv4.tcp_dsack=0
  • net.ipv4.tcp_mem/tcp_wmem/tcp_rmem
  • net.core.netdev_budget
  • net.core.dev_weight
  • net.core.netdev_max_backlog
  • net.ipv4.tcp_slow_start_after_idle=0
  • net.ipv4.tcp_moderate_rcvbuf=0
  • net.ipv4.tcp_timestamps=0
  • net.ipv4.tcp_low_latency = 1
  • SO_PRIORITY
  • TCP_NODELAY

  स्रोत: opennet.ru