സെക്കൻഡിൽ 1.2 ദശലക്ഷം JSON അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ Linux ഒപ്റ്റിമൈസ് ചെയ്യുന്നു

HTTP അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള പരമാവധി പ്രകടനം നേടുന്നതിന് Linux എൻവയോൺമെൻ്റ് ട്യൂൺ ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള വിശദമായ ഒരു ഗൈഡ് പ്രസിദ്ധീകരിച്ചു. ആമസോൺ ഇസി2 എൻവയോൺമെൻ്റിലെ (4 വിസിപിയു) ലിബ്രെക്റ്റർ ലൈബ്രറിയെ അടിസ്ഥാനമാക്കിയുള്ള ജെഎസ്ഒഎൻ പ്രൊസസറിൻ്റെ പ്രകടനം സെക്കൻഡിൽ 224 ആയിരം എപിഐ അഭ്യർത്ഥനകളിൽ നിന്ന് ആമസോൺ ലിനക്സ് 2-ൻ്റെ സ്റ്റാൻഡേർഡ് സെറ്റിംഗുകൾ ഉപയോഗിച്ച് കേർണൽ 4.14-ഓരോന്നും 1.2 ദശലക്ഷം അഭ്യർത്ഥനകളോ വർദ്ധിപ്പിക്കാൻ നിർദ്ദിഷ്ട രീതികൾ സാധ്യമാക്കി. ഒപ്റ്റിമൈസേഷനുശേഷം രണ്ടാമത്തേത് (436% വർദ്ധനവ്), കൂടാതെ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിലെ കാലതാമസം 79% കുറയ്ക്കുന്നതിനും കാരണമായി. nginx, Actix, Netty, Node.js എന്നിവയുൾപ്പെടെയുള്ള മറ്റ് http സെർവറുകൾ ഉപയോഗിക്കുമ്പോൾ നിർദ്ദിഷ്ട രീതികൾ libreactor-ന് പ്രത്യേകം അല്ല പ്രവർത്തിക്കുന്നു (libreactor ടെസ്റ്റുകളിൽ ഉപയോഗിച്ചത്, കാരണം അതിനെ അടിസ്ഥാനമാക്കിയുള്ള പരിഹാരം മികച്ച പ്രകടനം കാണിക്കുന്നു).

അടിസ്ഥാന ഒപ്റ്റിമൈസേഷനുകൾ:

• ലിബ്രക്റ്റർ കോഡ് ഒപ്റ്റിമൈസ് ചെയ്യുന്നു. ടെക്ംപവർ കിറ്റിൽ നിന്നുള്ള R18 ഓപ്ഷൻ ഒരു അടിസ്ഥാനമായി ഉപയോഗിച്ചു, ഉപയോഗിച്ച CPU കോറുകളുടെ എണ്ണം പരിമിതപ്പെടുത്താൻ കോഡ് നീക്കം ചെയ്തുകൊണ്ട് മെച്ചപ്പെടുത്തി (ഒപ്റ്റിമൈസേഷൻ 25-27% വരെ ജോലി വേഗത്തിലാക്കാൻ അനുവദിച്ചു), "-O3" ഓപ്‌ഷനുകൾക്കൊപ്പം ജിസിസിയിൽ കൂട്ടിച്ചേർക്കുന്നു. (5-10% വർദ്ധനവ് ) കൂടാതെ "-മാർച്ച്-നേറ്റീവ്" (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” (Specter v1 + SWAPGS-ൽ നിന്നുള്ള സംരക്ഷണം) എന്ന പാരാമീറ്ററിൽ നിന്നുള്ള വർദ്ധനവ് 1-2%, “nospectre_v2” (Specter v2-ൽ നിന്നുള്ള സംരക്ഷണം) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload, TSX അസിൻക്രണസ് അബോർട്ട്) - 6%. L1TF/Foreshadow (l1tf=flush), iTLB മൾട്ടിഹിറ്റ്, ഊഹക്കച്ചവട സ്റ്റോർ ബൈപാസ്, SRBDS ആക്രമണങ്ങൾ എന്നിവയ്‌ക്കെതിരായ പരിരക്ഷയ്‌ക്കായുള്ള ക്രമീകരണങ്ങൾ മാറ്റമില്ലാതെ അവശേഷിക്കുന്നു, ഇത് പരീക്ഷിച്ച കോൺഫിഗറേഷനുമായി വിഭജിക്കാത്തതിനാൽ പ്രകടനത്തെ ബാധിച്ചില്ല (ഉദാഹരണത്തിന്, KVM-ന് പ്രത്യേകം, നെസ്റ്റഡ് വെർച്വലൈസേഷനും മറ്റ് സിപിയു മോഡലുകളും).
• "auditctl -a never,task" കമാൻഡ് ഉപയോഗിച്ച് ഓഡിറ്റിംഗും സിസ്റ്റം കോൾ ബ്ലോക്കിംഗ് മെക്കാനിസങ്ങളും പ്രവർത്തനരഹിതമാക്കുകയും ഡോക്കർ കണ്ടെയ്‌നർ ആരംഭിക്കുമ്പോൾ "--security-opt seccomp=unconfined" ഓപ്ഷൻ വ്യക്തമാക്കുകയും ചെയ്യുന്നു. മൊത്തത്തിലുള്ള പ്രകടന വർദ്ധനവ് 11% ആയിരുന്നു, ത്രൂപുട്ട് 446k req/s ൽ നിന്ന് 495k req/s ആയി വർദ്ധിച്ചു.
• ബന്ധപ്പെട്ട കേർണൽ മൊഡ്യൂളുകൾ അൺലോഡ് ചെയ്തുകൊണ്ട് iptables/netfilter പ്രവർത്തനരഹിതമാക്കുന്നു. ഒരു നിർദ്ദിഷ്‌ട സെർവർ സൊല്യൂഷനിൽ ഉപയോഗിക്കാത്ത ഫയർവാൾ പ്രവർത്തനരഹിതമാക്കാനുള്ള ആശയം, പ്രൊഫൈലിംഗ് ഫലങ്ങൾ വഴി പ്രേരിപ്പിച്ചു, nf_hook_slow ഫംഗ്‌ഷൻ എക്‌സിക്യൂട്ട് ചെയ്യുന്നതിന് 18% സമയമെടുത്തു. iptables-നെ അപേക്ഷിച്ച് nftables കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നുവെന്നത് ശ്രദ്ധേയമാണ്, എന്നാൽ Amazon Linux iptables ഉപയോഗിക്കുന്നത് തുടരുന്നു. iptables പ്രവർത്തനരഹിതമാക്കിയതിന് ശേഷം, പ്രകടന വർദ്ധനവ് 22% ആയിരുന്നു, ത്രൂപുട്ട് 495k req/s ൽ നിന്ന് 603k req/s ആയി വർദ്ധിച്ചു.
• പ്രോസസ്സർ കാഷെ ഉപയോഗത്തിൻ്റെ കാര്യക്ഷമത മെച്ചപ്പെടുത്തുന്നതിനായി വ്യത്യസ്ത സിപിയു കോറുകൾക്കിടയിൽ ഹാൻഡ്‌ലറുകളുടെ മൈഗ്രേഷൻ കുറച്ചു. സിപിയു കോറുകൾ (സിപിയു പിൻ ചെയ്യൽ) ബൈൻഡിംഗ് ലിബ്രെക്റ്റർ പ്രക്രിയകളുടെ തലത്തിലും കേർണൽ നെറ്റ്‌വർക്ക് ഹാൻഡ്‌ലറുകൾ പിൻ ചെയ്യുന്നതിലൂടെയും (സൈഡ് സ്കെയിലിംഗ് സ്വീകരിക്കുക) ഒപ്റ്റിമൈസേഷൻ നടപ്പിലാക്കി. ഉദാഹരണത്തിന്, irqbalance പ്രവർത്തനരഹിതമാക്കുകയും CPU-യുമായുള്ള ക്യൂ അഫിനിറ്റി /proc/irq/$IRQ/smp_affinity_list എന്നതിൽ വ്യക്തമായി സജ്ജീകരിക്കുകയും ചെയ്തു. ലിബ്രെക്‌ടർ പ്രോസസും ഇൻകമിംഗ് പാക്കറ്റുകളുടെ നെറ്റ്‌വർക്ക് ക്യൂവും പ്രോസസ്സ് ചെയ്യുന്നതിന് ഒരേ സിപിയു കോർ ഉപയോഗിക്കുന്നതിന്, സോക്കറ്റ് സൃഷ്‌ടിക്കുമ്പോൾ SO_ATTACH_REUSEPORT_CBPF ഫ്ലാഗ് സജ്ജീകരിച്ച് ബന്ധിപ്പിച്ച ഒരു ഇഷ്‌ടാനുസൃത BPF ഹാൻഡ്‌ലർ ഉപയോഗിക്കുന്നു. ഔട്ട്‌ഗോയിംഗ് പാക്കറ്റുകളുടെ ക്യൂകൾ സിപിയുവിലേക്ക് ബന്ധിപ്പിക്കുന്നതിന്, /sys/class/net/eth0/queues/tx- എന്ന ക്രമീകരണങ്ങൾ മാറ്റി. /xps_cpus. മൊത്തത്തിലുള്ള പ്രകടന വർദ്ധനവ് 38% ആയിരുന്നു, ത്രൂപുട്ട് 603k req/s ൽ നിന്ന് 834k req/s ആയി വർദ്ധിച്ചു.
• ഇൻ്ററപ്റ്റ് കൈകാര്യം ചെയ്യലിൻ്റെയും പോളിംഗിൻ്റെ ഉപയോഗത്തിൻ്റെയും ഒപ്റ്റിമൈസേഷൻ. ENA ഡ്രൈവറിൽ അഡാപ്റ്റീവ്-rx മോഡ് പ്രവർത്തനക്ഷമമാക്കുന്നതും 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 replace dev eth0 root mq” എന്നിവ വഴി നെറ്റ്‌വർക്ക് സ്റ്റാക്ക് “noqueue” മോഡിലേക്ക് മാറ്റുന്നത് 2% പ്രകടന വർദ്ധനവിന് കാരണമായി, കൂടാതെ ത്രൂപുട്ട് 1.12M req/s-ൽ നിന്ന് 1.15M ആയി വർദ്ധിച്ചു. req/s.
• "ethtool -K eth0 gro off" എന്ന കമാൻഡ് ഉപയോഗിച്ച് GRO (Generic Receive Offload) പ്രവർത്തനരഹിതമാക്കുന്നതും sysctl "net.ipv4.tcp_congestion_control=reno" ഉപയോഗിച്ച് reno ഉപയോഗിച്ച് ക്യൂബിക് കൺജഷൻ കൺട്രോൾ അൽഗോരിതം മാറ്റിസ്ഥാപിക്കുന്നതും പോലുള്ള അവസാന ചെറിയ ഒപ്റ്റിമൈസേഷനുകൾ. മൊത്തത്തിലുള്ള ഉൽപ്പാദനക്ഷമത 4% ആണ്. ത്രൂപുട്ട് 1.15M req/s-ൽ നിന്ന് 1.2M req/s ആയി വർദ്ധിച്ചു.

പ്രവർത്തിച്ച ഒപ്റ്റിമൈസേഷനുകൾക്ക് പുറമേ, പ്രതീക്ഷിച്ച പ്രകടന വർദ്ധനവിന് കാരണമാകാത്ത രീതികളും ലേഖനം ചർച്ചചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഇനിപ്പറയുന്നവ ഫലപ്രദമല്ലെന്ന് തെളിഞ്ഞു:

• ഒരു കണ്ടെയ്‌നറിൽ പ്രവർത്തിപ്പിക്കുന്നതിൽ നിന്ന് പ്രത്യേകമായി ലിബ്രെക്‌ടർ പ്രവർത്തിപ്പിക്കുന്നത് പ്രകടനത്തിൽ വ്യത്യാസപ്പെട്ടില്ല. റൈറ്റിനെ പകരം അയക്കുക, epoll_wait-ൽ maxevents വർദ്ധിപ്പിക്കുക, GCC പതിപ്പുകളും ഫ്ലാഗുകളും ഉപയോഗിച്ച് പരീക്ഷിച്ചിട്ടും ഫലമുണ്ടായില്ല ("-O3", "-march-native" ഫ്ലാഗുകൾക്ക് മാത്രമേ ഈ പ്രഭാവം ശ്രദ്ധേയമായിരുന്നു).
• ലിനക്സ് കേർണൽ 4.19, 5.4 പതിപ്പുകളിലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുന്നു, SCHED_FIFO, SCHED_RR ഷെഡ്യൂളറുകൾ ഉപയോഗിച്ച്, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns എന്നിവ കൈകാര്യം ചെയ്യുന്നു, transparent_clock=hugets did not affect.
• 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 = 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