प्रति सेकंद 1.2 दशलक्ष JSON विनंत्या हाताळण्यासाठी Linux ऑप्टिमाइझ करत आहे

HTTP विनंत्यांची प्रक्रिया करण्यासाठी जास्तीत जास्त कार्यप्रदर्शन साध्य करण्यासाठी Linux वातावरण ट्यूनिंग करण्यावर तपशीलवार मार्गदर्शक प्रकाशित केले आहे. प्रस्तावित पद्धतींमुळे Amazon EC2 वातावरणात (4 vCPU) libreactor लायब्ररीवर आधारित JSON प्रोसेसरचे कार्यप्रदर्शन 224 हजार API विनंत्या प्रति सेकंद वरून Amazon Linux 2 च्या मानक सेटिंग्जसह कर्नल 4.14 ते 1.2 दशलक्ष विनंत्या प्रति सेकंद वाढवणे शक्य झाले. ऑप्टिमायझेशन नंतर दुसरे (436% ची वाढ), आणि विनंत्यांवर प्रक्रिया करताना 79% ने विलंब कमी केला. प्रस्तावित पद्धती libreactor साठी विशिष्ट नाहीत आणि nginx, Actix, Netty आणि Node.js सह इतर HTTP सर्व्हर वापरताना कार्य करतात (लिब्रेएक्टर चाचण्यांमध्ये वापरला गेला कारण त्यावर आधारित सोल्यूशनने चांगली कार्यक्षमता दर्शविली).

मूलभूत ऑप्टिमायझेशन:

• लिब्रेक्टर कोड ऑप्टिमाइझ करत आहे. टेकमपॉवर किटमधील R18 पर्यायाचा आधार म्हणून वापर केला गेला, जो वापरलेल्या CPU कोरची संख्या मर्यादित करण्यासाठी कोड काढून सुधारित करण्यात आला (ऑप्टिमायझेशनमुळे कामाला 25-27% ने गती मिळू शकते), GCC मध्ये “-O3” पर्यायांसह एकत्र करून (5-10% ची वाढ) आणि "-मार्च-नेटिव्ह" (5-10%), रिड/राइट कॉलच्या जागी recv/सेंड (5-10%) आणि pthreads वापरताना ओव्हरहेड कमी करणे (2-3%) . कोड ऑप्टिमायझेशन नंतर एकूण कामगिरी वाढ 55% होती, आणि थ्रूपुट 224k req/s वरून 347k req/s पर्यंत वाढला.
• सट्टा अंमलबजावणी असुरक्षांविरूद्ध संरक्षण अक्षम करा. कर्नल लोड करताना "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" पॅरामीटर्स वापरल्याने कार्यक्षमता 28% ने वाढू शकते आणि थ्रूपुट 347k req/s वरून 446k req/s पर्यंत वाढू शकते. स्वतंत्रपणे, पॅरामीटर पासून वाढ “nospectre_v1” (Sspecter v1 + SWAPGS पासून संरक्षण) 1-2% होती, “nospectre_v2” (स्पेक्टर v2 पासून संरक्षण) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload आणि TSX Asynchronous Abort) - 6%. L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store बायपास आणि SRBDS हल्ल्यांपासून संरक्षणासाठी सेटिंग्ज अपरिवर्तित ठेवल्या गेल्या, ज्याने चाचणी केलेल्या कॉन्फिगरेशनला छेद न दिल्याने कामगिरीवर परिणाम झाला नाही (उदाहरणार्थ, KVM साठी विशिष्ट, नेस्टेड आभासीकरण आणि इतर CPU मॉडेल्स).
• "auditctl -a never,task" कमांड वापरून ऑडिटिंग आणि सिस्टम कॉल ब्लॉकिंग यंत्रणा अक्षम करणे आणि डॉकर कंटेनर सुरू करताना "--security-opt seccomp=unconfined" पर्याय निर्दिष्ट करणे. एकूण कामगिरी वाढ 11% होती, आणि थ्रूपुट 446k req/s वरून 495k req/s पर्यंत वाढला.
• संबंधित कर्नल मॉड्यूल्स अनलोड करून iptables/netfilter अक्षम करणे. फायरवॉल अक्षम करण्याची कल्पना, जी विशिष्ट सर्व्हर सोल्यूशनमध्ये वापरली जात नव्हती, परिणाम प्रोफाइलिंगद्वारे सूचित केली गेली होती, ज्यानुसार nf_hook_slow फंक्शन कार्यान्वित होण्यासाठी 18% वेळ लागला. हे लक्षात घेतले आहे की nftables iptables पेक्षा अधिक कार्यक्षमतेने कार्य करते, परंतु Amazon Linux iptables वापरणे सुरू ठेवते. iptables अक्षम केल्यानंतर, कार्यप्रदर्शन वाढ 22% होती, आणि थ्रूपुट 495k req/s वरून 603k req/s पर्यंत वाढले.
• प्रोसेसर कॅशे वापरण्याची कार्यक्षमता सुधारण्यासाठी वेगवेगळ्या CPU कोर दरम्यान हँडलरचे स्थलांतर कमी केले. ऑप्टिमायझेशन सीपीयू कोर (CPU पिनिंग) आणि पिनिंग कर्नल नेटवर्क हँडलर्स (रिसीव्ह साइड स्केलिंग) द्वारे बंधनकारक लिब्रेएक्टर प्रक्रियेच्या दोन्ही स्तरांवर केले गेले. उदाहरणार्थ, irqbalance अक्षम केले होते आणि /proc/irq/$IRQ/smp_affinity_list मध्ये CPU साठी रांगेतील संबंध स्पष्टपणे सेट केले होते. लिब्रेएक्टर प्रक्रिया आणि इनकमिंग पॅकेट्सच्या नेटवर्क रांगेवर प्रक्रिया करण्यासाठी समान CPU कोर वापरण्यासाठी, सॉकेट तयार करताना SO_ATTACH_REUSEPORT_CBPF ध्वज सेट करून एक सानुकूल BPF हँडलर वापरला जातो. CPU ला आउटगोइंग पॅकेट्सच्या रांगा बांधण्यासाठी, सेटिंग्ज /sys/class/net/eth0/queues/tx- बदलल्या आहेत. /xps_cpus. एकूण कामगिरी वाढ 38% होती, आणि थ्रूपुट 603k req/s वरून 834k req/s पर्यंत वाढले.
• व्यत्यय हाताळणी आणि मतदानाचा वापर ऑप्टिमायझेशन. ENA ड्रायव्हरमध्ये अ‍ॅडॉप्टिव्ह-आरएक्स मोड सक्षम केल्याने आणि sysctl net.core.busy_read हाताळणीमुळे कार्यक्षमता 28% वाढली (थ्रूपुट 834k req/s वरून 1.06M req/s पर्यंत वाढला, आणि लेटन्सी 361μs वरून 292μs पर्यंत कमी झाली).
• नेटवर्क स्टॅकमध्ये अनावश्यक ब्लॉकिंग होऊ देणार्‍या सिस्टम सेवा अक्षम करणे. dhclient अक्षम केल्याने आणि IP पत्ता व्यक्तिचलितपणे सेट केल्याने 6% कामगिरी वाढली आणि थ्रूपुट 1.06M req/s वरून 1.12M req/s पर्यंत वाढले. कच्च्या सॉकेटचा वापर करून ट्रॅफिक विश्लेषणामध्ये 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 पर्यंत वाढले.

कार्य केलेल्या ऑप्टिमायझेशन व्यतिरिक्त, लेखात अशा पद्धतींची देखील चर्चा केली आहे ज्यामुळे अपेक्षित कामगिरी वाढली नाही. उदाहरणार्थ, खालील कुचकामी ठरले:

• लिब्रेएक्टर स्वतंत्रपणे चालवणे हे कंटेनरमध्ये चालवण्यापेक्षा कार्यक्षमतेत भिन्न नव्हते. writev ला पाठवण्याने बदलणे, epoll_wait मधील maxevents वाढवणे आणि GCC आवृत्त्या आणि ध्वजांसह प्रयोग करण्याचा कोणताही परिणाम झाला नाही (प्रभाव फक्त “-O3” आणि “-march-native” ध्वजांसाठी लक्षात येण्याजोगा होता).
• SCHED_FIFO आणि SCHED_RR शेड्यूलर्सचा वापर करून, लिनक्स कर्नलला आवृत्ती 4.19 आणि 5.4 वर श्रेणीसुधारित करणे, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never,tskew=tskew=1 कार्यप्रदर्शन प्रभावित झाले नाही.
• 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 (नकारात्मक प्रभाव)
  • नेट.ipv4.tcp_sack = 0
  • 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