வினாடிக்கு 1.2 மில்லியன் JSON கோரிக்கைகளைக் கையாள லினக்ஸ் மேம்படுத்தல்

HTTP கோரிக்கைகளைச் செயலாக்குவதற்கான அதிகபட்ச செயல்திறனை அடைய லினக்ஸ் சூழலைச் சரிசெய்வது குறித்த விரிவான வழிகாட்டி வெளியிடப்பட்டுள்ளது. முன்மொழியப்பட்ட முறைகள், Amazon EC2 சூழலில் (4 vCPU) லைப்ரேக்டர் நூலகத்தை அடிப்படையாகக் கொண்ட JSON செயலியின் செயல்திறனை ஒரு நொடிக்கு 224 ஆயிரம் API கோரிக்கைகளிலிருந்து Amazon Linux 2 இன் நிலையான அமைப்புகளுடன் கர்னல் 4.14 முதல் 1.2 மில்லியன் கோரிக்கைகளிலிருந்து அதிகரிக்கச் செய்தது. தேர்வுமுறைக்குப் பிறகு இரண்டாவது (436% அதிகரிப்பு), மேலும் கோரிக்கைகளை செயலாக்குவதில் தாமதம் 79% குறைக்கப்பட்டது. முன்மொழியப்பட்ட முறைகள் nginx, Actix, Netty மற்றும் Node.js உள்ளிட்ட பிற http சேவையகங்களைப் பயன்படுத்தும் போது libreactor மற்றும் வேலை செய்ய குறிப்பிட்டவை அல்ல.

அடிப்படை மேம்படுத்தல்கள்:

• லிப்ரேக்டர் குறியீட்டை மேம்படுத்துதல். Techempower kit இலிருந்து R18 விருப்பம் ஒரு அடிப்படையாகப் பயன்படுத்தப்பட்டது, இது பயன்படுத்தப்பட்ட CPU கோர்களின் எண்ணிக்கையைக் கட்டுப்படுத்த குறியீட்டை அகற்றுவதன் மூலம் மேம்படுத்தப்பட்டது (உகப்பாக்கம் வேலையை 25-27% வரை வேகப்படுத்த அனுமதித்தது), GCC இல் “-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” (ஸ்பெக்டர் 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 மல்டிஹிட், ஸ்பெகுலேட்டிவ் ஸ்டோர் பைபாஸ் மற்றும் SRBDS தாக்குதல்களுக்கு எதிரான பாதுகாப்பிற்கான அமைப்புகள் மாறாமல் விடப்பட்டன, அவை சோதனை செய்யப்பட்ட உள்ளமைவுடன் (உதாரணமாக, KVM க்கு குறிப்பிட்ட, உள்ளமைக்கப்பட்ட) குறுக்கிடாததால் செயல்திறனை பாதிக்கவில்லை. மெய்நிகராக்கம் மற்றும் பிற CPU மாதிரிகள்).
• "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 ஆக அதிகரித்தது.
• செயலி கேச் பயன்பாட்டின் செயல்திறனை மேம்படுத்த வெவ்வேறு CPU கோர்களுக்கு இடையே கையாளுபவர்களின் இடம்பெயர்வு குறைக்கப்பட்டது. லிப்ரேக்டர் செயல்முறைகளை CPU கோர்களுடன் பிணைக்கும் நிலையிலும் (CPU பின்னிங்) மற்றும் பின்னிங் கர்னல் நெட்வொர்க் ஹேண்ட்லர்கள் மூலமாகவும் (ரிசீவ் சைட் ஸ்கேலிங்) மேம்படுத்துதல் மேற்கொள்ளப்பட்டது. எடுத்துக்காட்டாக, irqbalance முடக்கப்பட்டது மற்றும் CPU உடனான வரிசை இணைப்பு வெளிப்படையாக /proc/irq/$IRQ/smp_affinity_list இல் அமைக்கப்பட்டது. லிப்ரேக்டர் செயல்முறை மற்றும் உள்வரும் பாக்கெட்டுகளின் பிணைய வரிசையைச் செயல்படுத்த அதே CPU மையத்தைப் பயன்படுத்த, தனிப்பயன் BPF ஹேண்ட்லர் பயன்படுத்தப்படுகிறது, சாக்கெட்டை உருவாக்கும் போது SO_ATTACH_REUSEPORT_CBPF கொடியை அமைப்பதன் மூலம் இணைக்கப்பட்டுள்ளது. வெளிச்செல்லும் பாக்கெட்டுகளின் வரிசைகளை 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 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" ஐப் பயன்படுத்தி க்யூபிக் நெரிசல் கட்டுப்பாட்டு அல்காரிதத்தை ரெனோவுடன் மாற்றுவது போன்ற இறுதி சிறிய மேம்படுத்தல்கள். ஒட்டுமொத்த உற்பத்தித்திறன் அதிகரிப்பு 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