In detaillearre hantlieding is publisearre oer it ôfstimmen fan de Linux-omjouwing om maksimale prestaasjes te berikken foar it ferwurkjen fan HTTP-oanfragen. De foarstelde metoaden makken it mooglik om de prestaasjes fan 'e JSON-prosessor te ferheegjen op basis fan' e libreactor-bibleteek yn 'e Amazon EC2-omjouwing (4 vCPU) fan 224 tûzen API-oanfragen per sekonde mei standertynstellingen fan Amazon Linux 2 mei kernel 4.14 oant 1.2 miljoen oanfragen per sekonde twadde nei optimalisaasje (in tanimming fan 436%), en late ek ta in fermindering fan fertragingen yn ferwurkjen fersiken mei 79%. De foarstelde metoaden binne net spesifyk foar libreactor en wurkje by it brûken fan oare http-tsjinners, ynklusyf nginx, Actix, Netty en Node.js (libreactor waard brûkt yn tests omdat de oplossing basearre op it toande bettere prestaasjes).
Basis optimisaasjes:
- Libreactor-koade optimalisearje. De R18-opsje fan 'e Techempower-kit waard brûkt as basis, dy't waard ferbettere troch koade te ferwiderjen om it oantal brûkte CPU-kearnen te beheinen (optimalisaasje tastien it wurk te fersnellen mei 25-27%), gearstalling yn GCC mei de "-O3" opsjes (in ferheging fan 5-10%) en "-march-native" (5-10%), it ferfangen fan lês-/skriuwoproppen mei recv/ferstjoere (5-10%) en it ferminderjen fan overhead by it brûken fan pthreads (2-3%) . De totale prestaasjesferheging nei koadeoptimalisaasje wie 55%, en trochstreaming ferhege fan 224k req / s nei 347k req / s.
- Skeakelje beskerming tsjin spekulative eksekúsje kwetsberens. Mei help fan de parameters "nospectre_v1 nospectre_v2 pti = off mds = off tsx_async_abort = off" by it laden fan de kearn tastien te fergrutsjen prestaasjes mei 28%, en trochfier ferhege fan 347k req / s nei 446k req / s. Apart wie de ferheging fan 'e parameter "nospectre_v1" (beskerming tsjin Spectre v1 + SWAPGS) 1-2%, "nospectre_v2" (beskerming tsjin Spectre v2) - 15-20%, "pti=off" (Spectre v3 / Meltdown) - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload en TSX Asynchronous Abort) - 6%. De ynstellings foar beskerming tsjin L1TF / Foreshadow (l1tf = flush), iTLB multihit, Speculative Store Bypass en SRBDS oanfallen waarden ûnferoare litten, dy't gjin ynfloed op prestaasjes, om't se net krústen mei de teste konfiguraasje (bygelyks spesifyk foar KVM, nested virtualisaasje en oare CPU-modellen).
- It útskeakeljen fan kontrôle- en systeemopropblokkearjende meganismen mei it kommando "auditctl -a never,task" en spesifisearje de opsje "--security-opt seccomp=unconfined" by it starten fan de docker-kontener. De totale prestaasjeferheging wie 11%, en trochset ferhege fan 446k req / s nei 495k req / s.
- Iptables/netfilter útskeakelje troch assosjearre kernelmodules út te laden. It idee om de firewall út te skeakeljen, dy't net brûkt waard yn in spesifike serveroplossing, waard frege troch profilearjen fan resultaten, te beoardieljen wêrfan de nf_hook_slow-funksje 18% fan 'e tiid naam om út te fieren. It wurdt opmurken dat nftables effisjinter wurket dan iptables, mar Amazon Linux bliuwt iptables te brûken. Nei it útskeakeljen fan iptables wie de prestaasjeferheging 22%, en trochfier ferhege fan 495k req/s nei 603k req/s.
- Fermindere migraasje fan handlers tusken ferskate CPU-kearnen om de effisjinsje fan prosessor-cache-gebrûk te ferbetterjen. Optimalisaasje waard útfierd sawol op it nivo fan binende libreactor-prosessen oan CPU-kearnen (CPU Pinning) en troch pinning fan kernel-netwurkhannelers (Receive Side Scaling). Bygelyks, irqbalance wie útskeakele en wachtrige affiniteit foar de CPU waard eksplisyt ynsteld yn /proc/irq/$IRQ/smp_affinity_list. Om deselde CPU-kearn te brûken om it libreactor-proses en de netwurkwachtrige fan ynkommende pakketten te ferwurkjen, wurdt in oanpaste BPF-hanneler brûkt, ferbûn troch it ynstellen fan de SO_ATTACH_REUSEPORT_CBPF-flagge by it meitsjen fan de socket. Om wachtrijen fan útgeande pakketten oan de CPU te binen, binne de ynstellings /sys/class/net/eth0/queues/tx- feroare /xps_cpus. De totale prestaasjeferheging wie 38%, en trochset ferhege fan 603k req / s nei 834k req / s.
- Optimalisaasje fan ûnderbrekkingsôfhanneling en gebrûk fan polling. It ynskeakeljen fan de adaptive-rx-modus yn 'e ENA-bestjoerder en it manipulearjen fan sysctl net.core.busy_read ferhege prestaasjes mei 28% (trochput ferhege fan 834k req / s nei 1.06M req / s, en latency fermindere fan 361μs nei 292μs).
- Systeemtsjinsten útskeakelje dy't liede ta ûnnedige blokkearjen yn 'e netwurkstapel. It útskeakeljen fan dhclient en it manuell ynstellen fan it IP-adres resultearre yn in prestaasjesferheging fan 6% en trochfier ferhege fan 1.06M req/s nei 1.12M req/s. De reden dat dhclient de prestaasjes beynfloedet is yn ferkearsanalyse mei in rau socket.
- Fighting Spin Slot. It wikseljen fan de netwurkstapel nei "noqueue" modus fia sysctl "net.core.default_qdisc = noqueue" en "tc qdisc ferfange dev eth0 root mq" late ta in 2% prestaasjesferheging, en trochfier ferhege fan 1.12M req / s nei 1.15M req/s.
- Finale lytse optimisaasjes, lykas it útskeakeljen fan GRO (Generic Receive Offload) mei it kommando "ethtool -K eth0 gro off" en it ferfangen fan it kubike oerlêstkontrôlealgoritme mei reno mei sysctl "net.ipv4.tcp_congestion_control = reno". De totale produktiviteitsferheging wie 4%. Trochfier ferhege fan 1.15M req / s nei 1.2M req / s.
Neist de optimalisaasjes dy't wurken, besprekt it artikel ek metoaden dy't net liede ta de ferwachte prestaasjesferheging. Bygelyks, it folgjende die bliken net effektyf te wêzen:
- It útfieren fan libreactor apart wie net oars yn prestaasjes fan it útfieren yn in kontener. It ferfangen fan writev mei send, tanimmende maxevents yn epoll_wait, en eksperimintearjen mei GCC ferzjes en flaggen hie gjin effekt (it effekt wie merkber allinnich foar de "-O3" en "-march-native" flaggen).
- It opwurdearjen fan de Linux-kern nei ferzjes 4.19 en 5.4, mei help fan de SCHED_FIFO en SCHED_RR planners, manipulearjende sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=t clock hat notsource = 1 en klok hat gjin ynfloed op prestaasjes.
- Yn de ENA-bestjoerder, it ynskeakeljen fan Offload-modi (segmentaasje, scatter-gather, rx / tx checksum), bouwen mei de "-O3" flagge, en it brûken fan de parameters ena.rx_queue_size en ena.force_large_llq_header hie gjin effekt.
- Feroarings yn 'e netwurkstapel hawwe de prestaasjes net ferbettere:
- Utskeakelje IPv6: ipv6.disable=1
- VLAN útskeakelje: modprobe -rv 8021q
- Skeakelje kontrôle fan pakketboarne út
- net.ipv4.conf.all.rp_filter=0
- net.ipv4.conf.eth0.rp_filter=0
- net.ipv4.conf.all.accept_local=1 (negatyf effekt)
- 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
Boarne: opennet.ru