ઑપ્ટિમાઇઝેશન Linux પ્રતિ સેકન્ડ 1.2 મિલિયન JSON વિનંતીઓ પર પ્રક્રિયા કરવા માટે

પર્યાવરણને સુમેળ બનાવવા માટેની વિગતવાર માર્ગદર્શિકા પ્રકાશિત કરવામાં આવી છે. Linux HTTP વિનંતી પ્રક્રિયા માટે મહત્તમ કામગીરી પ્રાપ્ત કરવા માટે. પ્રસ્તાવિત પદ્ધતિઓએ અમને એમેઝોન EC2 પર્યાવરણ (4 vCPUs) માં લિબ્રેક્ટર લાઇબ્રેરી પર આધારિત JSON પાર્સરનું પ્રદર્શન પ્રમાણભૂત એમેઝોન સેટિંગ્સ હેઠળ પ્રતિ સેકન્ડ 224 API વિનંતીઓથી વધારવાની મંજૂરી આપી. Linux કર્નલ 4.14 સાથે 2 એ ઑપ્ટિમાઇઝેશન પછી થ્રુપુટને પ્રતિ સેકન્ડ 1.2 મિલિયન વિનંતીઓ સુધી વધાર્યો (436% વધારો), અને વિનંતી પ્રક્રિયા વિલંબમાં 79% ઘટાડો કર્યો. પ્રસ્તાવિત પદ્ધતિઓ લિબ્રેક્ટર માટે વિશિષ્ટ નથી અને nginx, Actix, Netty અને Node.js સહિત અન્ય HTTP સર્વર્સ સાથે કામ કરે છે (લિબ્રેક્ટરનો ઉપયોગ પરીક્ષણોમાં કરવામાં આવ્યો હતો, કારણ કે તેના પર આધારિત ઉકેલ વધુ સારું પ્રદર્શન દર્શાવે છે).

મૂળભૂત ઑપ્ટિમાઇઝેશન:

• લિબ્રેક્ટર કોડને ઑપ્ટિમાઇઝ કરી રહ્યું છે. ટેકમપાવર કીટમાંથી R18 વિકલ્પનો ઉપયોગ એક આધાર તરીકે કરવામાં આવ્યો હતો, જે ઉપયોગમાં લેવાતા CPU કોરોની સંખ્યાને મર્યાદિત કરવા માટે કોડને દૂર કરીને સુધારવામાં આવ્યો હતો (ઓપ્ટિમાઇઝેશન 25-27% દ્વારા કાર્યને ઝડપી બનાવવાની મંજૂરી આપે છે), "-O3" વિકલ્પો સાથે GCC માં એસેમ્બલ થાય છે. (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" પેરામીટર (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 અસિંક્રોનસ એબોર્ટ) - 6% હતો. L1TF/ફોરશેડો હુમલાઓ (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% સમય એક્ઝિક્યુટ કરવામાં વિતાવે છે. એ નોંધ્યું છે કે nftables iptables કરતાં વધુ કાર્યક્ષમ છે, પરંતુ એમેઝોન પર Linux iptables નો ઉપયોગ ચાલુ રહે છે. iptables ને અક્ષમ કર્યા પછી, કામગીરીમાં 22% નો વધારો થયો, અને થ્રુપુટ 495k req/s થી વધીને 603k req/s થયો.
• પ્રોસેસર કેશના ઉપયોગની કાર્યક્ષમતામાં સુધારો કરવા માટે વિવિધ CPU કોરો વચ્ચે હેન્ડલરનું સ્થળાંતર ઘટાડ્યું. ઓપ્ટિમાઇઝેશન સીપીયુ કોરો (સીપીયુ પિનિંગ) અને પિનિંગ કર્નલ નેટવર્ક હેન્ડલર્સ (રિસીવ સાઇડ સ્કેલિંગ) દ્વારા લિબ્રેએક્ટર પ્રક્રિયાઓને બંધનકર્તા સ્તરે બંને રીતે હાથ ધરવામાં આવ્યું હતું. ઉદાહરણ તરીકે, irqbalance અક્ષમ કરવામાં આવ્યું હતું અને /proc/irq/$IRQ/smp_affinity_list માં CPU સાથે કતારની એફિનિટી સ્પષ્ટપણે સેટ કરવામાં આવી હતી. લિબ્રેએક્ટર પ્રક્રિયા અને ઇનકમિંગ પેકેટોની નેટવર્ક કતાર પર પ્રક્રિયા કરવા માટે સમાન CPU કોરનો ઉપયોગ કરવા માટે, કસ્ટમ BPF હેન્ડલરનો ઉપયોગ કરવામાં આવે છે, જે સોકેટ બનાવતી વખતે SO_ATTACH_REUSEPORT_CBPF ફ્લેગ સેટ કરીને જોડાયેલ છે. આઉટગોઇંગ પેકેટોની કતારોને CPU સાથે જોડવા માટે, સેટિંગ્સ /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.06 મિલિયન રેક્યુ/સેકન્ડથી વધીને 1.12 મિલિયન રેક્યુ/સેકન્ડ થયો. 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 માં મહત્તમ ઇવેન્ટ્સ વધારવી, અને GCC સંસ્કરણો અને ફ્લેગ્સ સાથે પ્રયોગ કરવાથી કોઈ અસર થઈ નથી (અસર ફક્ત "-O3" અને "-માર્ચ-નેટિવ" ફ્લેગો માટે જ નોંધનીય હતી).
• કર્નલ અપડેટથી કામગીરી પર કોઈ અસર થઈ નથી. Linux SCHED_FIFO અને SCHED_RR શેડ્યૂલર્સનો ઉપયોગ કરીને, વર્ઝન 4.19 અને 5.4 સુધી, 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 = 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