បង្កើនប្រសិទ្ធភាព Linux ដើម្បីដោះស្រាយសំណើ 1.2 លាន JSON ក្នុងមួយវិនាទី

មគ្គុទ្ទេសក៍លម្អិតត្រូវបានបោះពុម្ពផ្សាយលើការកែសម្រួលបរិយាកាសលីនុច ដើម្បីសម្រេចបាននូវប្រតិបត្តិការអតិបរមាសម្រាប់ដំណើរការសំណើ HTTP ។ វិធីសាស្រ្តដែលបានស្នើឡើងបានធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីបង្កើនដំណើរការនៃដំណើរការ JSON ដោយផ្អែកលើបណ្ណាល័យ libreactor នៅក្នុងបរិស្ថាន Amazon EC2 (4 vCPU) ពី 224 ពាន់សំណើ API ក្នុងមួយវិនាទីជាមួយនឹងការកំណត់ស្តង់ដារនៃ Amazon Linux 2 ជាមួយខឺណែល 4.14 ទៅ 1.2 លានសំណើក្នុងមួយ ទីពីរបន្ទាប់ពីការបង្កើនប្រសិទ្ធភាព (ការកើនឡើង 436%) ហើយក៏នាំឱ្យមានការកាត់បន្ថយការពន្យារពេលក្នុងការដំណើរការសំណើ 79% ។ វិធីសាស្រ្តដែលបានស្នើឡើងគឺមិនជាក់លាក់ចំពោះ libreactor និងដំណើរការនៅពេលប្រើម៉ាស៊ីនមេ http ផ្សេងទៀត រួមទាំង nginx, Actix, Netty និង Node.js (libreactor ត្រូវបានប្រើក្នុងការធ្វើតេស្តព្រោះដំណោះស្រាយផ្អែកលើវាបង្ហាញពីដំណើរការប្រសើរជាងមុន)។

ការបង្កើនប្រសិទ្ធភាពជាមូលដ្ឋាន៖

• បង្កើនប្រសិទ្ធភាពកូដអ្នកសរសេរកម្មវិធី។ ជម្រើស R18 ពីឧបករណ៍ Techempower ត្រូវបានប្រើជាមូលដ្ឋាន ដែលត្រូវបានកែលម្អដោយការដកកូដចេញដើម្បីកំណត់ចំនួនស្នូលស៊ីភីយូដែលបានប្រើ (ការបង្កើនប្រសិទ្ធភាពអនុញ្ញាតឱ្យបង្កើនល្បឿនការងារ 25-27%) ដោយប្រមូលផ្តុំនៅក្នុង GCC ជាមួយនឹងជម្រើស "-O3" (ការកើនឡើងពី 5-10%) និង "-march-native" (5-10%) ជំនួសការហៅទូរសព្ទដែលអាន/សរសេរដោយ recv/send (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” (ការការពារពី Spectre v1 + SWAPGS) គឺ 1-2%, “nospectre_v2” (ការការពារពី Spectre 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 Bypass និងការវាយប្រហារ SRBDS មិនត្រូវបានផ្លាស់ប្តូរ ដែលមិនប៉ះពាល់ដល់ដំណើរការចាប់តាំងពីពួកគេមិនបានប្រសព្វជាមួយការកំណត់រចនាសម្ព័ន្ធដែលបានសាកល្បង (ឧទាហរណ៍ ជាក់លាក់ចំពោះ KVM បានដាក់សំបុក និម្មិតនិងគំរូស៊ីភីយូផ្សេងទៀត) ។
• ការបិទដំណើរការសវនកម្ម និងយន្តការទប់ស្កាត់ការហៅជាប្រព័ន្ធដោយប្រើពាក្យបញ្ជា "auditctl -a never,task" និងបញ្ជាក់ជម្រើស "--security-opt seccomp=unconfined" នៅពេលចាប់ផ្តើមធុង docker ។ ការកើនឡើងនៃការអនុវត្តសរុបគឺ 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 ។
• កាត់បន្ថយការធ្វើចំណាកស្រុករបស់ឧបករណ៍ដោះស្រាយរវាងស្នូលស៊ីភីយូផ្សេងៗគ្នា ដើម្បីបង្កើនប្រសិទ្ធភាពនៃការប្រើប្រាស់ឃ្លាំងសម្ងាត់របស់ខួរក្បាល។ ការបង្កើនប្រសិទ្ធភាពត្រូវបានអនុវត្តទាំងនៅកម្រិតនៃដំណើរការ libreactor ចងភ្ជាប់ទៅស្នូល CPU (CPU Pinning) និងតាមរយៈការ pinning network handlers (Receive Side Scaling)។ ឧទាហរណ៍ irqbalance ត្រូវ​បាន​បិទ ហើយ​ភាព​ទាក់​ទង​ជួរ​ទៅ​នឹង CPU ត្រូវ​បាន​កំណត់​យ៉ាង​ច្បាស់​នៅ​ក្នុង /proc/irq/$IRQ/smp_affinity_list ។ ដើម្បីប្រើស្នូលស៊ីភីយូដូចគ្នាដើម្បីដំណើរការដំណើរការ libreactor និងជួរបណ្តាញនៃកញ្ចប់ព័ត៌មានចូល ឧបករណ៍ដោះស្រាយ BPF ផ្ទាល់ខ្លួនត្រូវបានប្រើដែលភ្ជាប់ដោយការកំណត់ទង់ SO_ATTACH_REUSEPORT_CBPF នៅពេលបង្កើតរន្ធ។ ដើម្បីចងជួរនៃកញ្ចប់ព័ត៌មានចេញទៅកាន់ CPU ការកំណត់ /sys/class/net/eth0/queues/tx- ត្រូវបានផ្លាស់ប្តូរ /xps_cpu ។ ការកើនឡើងនៃការអនុវត្តសរុបគឺ 38% ហើយដំណើរការកើនឡើងពី 603k req/s ដល់ 834k req/s ។
• ការបង្កើនប្រសិទ្ធភាពនៃការគ្រប់គ្រងរំខាន និងការប្រើប្រាស់ការបោះឆ្នោត។ ការបើកដំណើរការរបៀប adaptive-rx នៅក្នុងកម្មវិធីបញ្ជា 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 ប៉ះពាល់ដល់ការអនុវត្តគឺនៅក្នុងការវិភាគចរាចរណ៍ដោយប្រើរន្ធឆៅ។
• ប្រយុទ្ធប្រឆាំងនឹងការចាក់សោរបង្វិល។ ការប្តូរជង់បណ្តាញទៅជារបៀប "noqueue" តាមរយៈ sysctl "net.core.default_qdisc=noqueue" និង "tc qdisc ជំនួស dev eth0 root mq" បាននាំឱ្យមានការកើនឡើងនៃការអនុវត្ត 2% ហើយការបញ្ជូនបន្តកើនឡើងពី 1.12M req/s ដល់ 1.15M req/s ។
• ការបង្កើនប្រសិទ្ធភាពអនីតិជនចុងក្រោយ ដូចជាការបិទ GRO (Generic Receive Offload) ដោយប្រើពាក្យបញ្ជា “ethtool -K eth0 gro off” និងការជំនួសក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះគូបជាមួយ reno ដោយប្រើ sysctl “net.ipv4.tcp_congestion_control=reno”។ ការកើនឡើងផលិតភាពសរុបគឺ 4% ។ លំហូរចូលបានកើនឡើងពី 1.15M req/s ទៅ 1.2M req/s ។

បន្ថែមពីលើការបង្កើនប្រសិទ្ធភាពដែលបានដំណើរការ អត្ថបទក៏ពិភាក្សាអំពីវិធីសាស្រ្តដែលមិននាំទៅរកការកើនឡើងនៃការអនុវត្តដែលរំពឹងទុក។ ឧទាហរណ៍ ខាងក្រោមនេះបានប្រែជាគ្មានប្រសិទ្ធភាព៖

• ការដំណើរការ libreactor ដោយឡែកពីគ្នាមិនមានភាពខុសប្លែកគ្នាក្នុងការអនុវត្តពីការដំណើរការវានៅក្នុងកុងតឺន័រនោះទេ។ ការជំនួស writev ជាមួយនឹងការផ្ញើ ការបង្កើនអតិបរមានៅក្នុង epoll_wait និងការពិសោធន៍ជាមួយកំណែ និងទង់របស់ GCC មិនមានផលប៉ះពាល់ទេ (ឥទ្ធិពលគឺគួរឱ្យកត់សម្គាល់សម្រាប់ទង់ "-O3" និង "-march-native" ប៉ុណ្ណោះ) ។
• ការអាប់ដេតខឺណែលលីនុចទៅកំណែ 4.19 និង 5.4 ដោយប្រើកម្មវិធីកំណត់ពេល SCHED_FIFO និង SCHED_RR រៀបចំ sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=clocktever, noteffects.
• នៅក្នុងកម្មវិធីបញ្ជា ENA ការបើកដំណើរការ Offload modes (segmentation, scatter-gather, rx/tx checksum) ការកសាងជាមួយទង់ “-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 = ១
  • SO_PRIORITY
  • TCP_NODELAY

  ប្រភព: opennet.ru