Yksityiskohtainen opas on julkaistu Linux-ympäristön virittämisestä HTTP-pyyntöjen käsittelyn maksimaalisen suorituskyvyn saavuttamiseksi. Ehdotetut menetelmät mahdollistivat libreactor-kirjastoon perustuvan JSON-prosessorin suorituskyvyn lisäämisen Amazon EC2 -ympäristössä (4 vCPU:ta) 224 tuhannesta API-pyynnöstä sekunnissa Amazon Linux 2:n ytimen 4.14 vakioasetuksella 1.2 miljoonaan pyyntöön per sekunti. toinen optimoinnin jälkeen (lisäys 436 %), ja se johti myös pyyntöjen käsittelyn viiveiden vähenemiseen 79 %. Ehdotetut menetelmät eivät ole libreactor-spesifisiä ja toimivat käytettäessä muita http-palvelimia, mukaan lukien nginx, Actix, Netty ja Node.js (libreactoria käytettiin testeissä, koska siihen perustuva ratkaisu osoitti parempaa suorituskykyä).
Perusoptimoinnit:
- Libractor-koodin optimointi. Pohjaksi käytettiin Techempower-sarjan R18-vaihtoehtoa, jota parannettiin poistamalla koodia käytettävien prosessoriytimien määrän rajoittamiseksi (optimointi mahdollisti työskentelyn nopeuttamisen 25-27%), kokoamalla GCC:hen "-O3"-vaihtoehdoilla. (lisäys 5-10 %) ja "-march-native" (5-10 %), korvaamalla luku-/kirjoituspuhelut vastaanotolla/lähetyksellä (5-10 %) ja vähentämällä lisäkustannuksia käytettäessä p-säikeitä (2-3 %) . Suorituskyvyn kokonaislisäys koodin optimoinnin jälkeen oli 55 %, ja suorituskyky kasvoi 224 347 rekv/s:sta XNUMX XNUMX rekv/s:iin.
- Poista suojaus spekulatiivisten suoritusten haavoittuvuuksia vastaan. Parametrien "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" käyttö ytimen latauksen aikana lisäsi suorituskykyä 28 % ja suorituskyky kasvoi 347 446 req/s:sta 1 1 req/s. Erikseen lisäys parametrista "nospectre_v1" (suojaus Spectre v2:ltä + SWAPGS) oli 2-2%, "nospectre_v15" (suojaus Spectre v20:lta) - 3-6%, "pti=off" (Spectre v6/Meltdown) - 1 %, "mds=off tsx_async_abort=off" (MDS/Zombieload ja TSX Asynchronous Abort) - 1%. LXNUMXTF/Foreshadow- (lXNUMXtf=flush), iTLB-multihit-, Speculative Store Bypass- ja SRBDS-hyökkäyksien suojausasetukset jätettiin ennalleen, mikä ei vaikuttanut suorituskykyyn, koska ne eivät risteä testatun kokoonpanon kanssa (esimerkiksi KVM-kohtaiset, sisäkkäiset). virtualisointi ja muut CPU-mallit).
- Valvonta- ja järjestelmäkutsujen estomekanismien poistaminen käytöstä käyttämällä "auditctl -a never,task" -komentoa ja määrittämällä "--security-opt seccomp=unconfined" telakointisäilöä käynnistettäessä. Suorituskyvyn kokonaislisäys oli 11 %, ja suorituskyky kasvoi 446 tk/s:sta 495 XNUMX rekv/s:iin.
- Iptables/netfilter poistetaan käytöstä poistamalla siihen liittyvät ydinmoduulit. Ajatus palomuurin käytöstä poistamisesta, jota ei käytetty tietyssä palvelinratkaisussa, sai alkunsa profiloinnin tuloksista, joiden perusteella nf_hook_slow-funktion suorittamiseen kului 18 % ajasta. On huomattava, että nftables toimii tehokkaammin kuin iptables, mutta Amazon Linux käyttää edelleen iptablesia. Kun iptables oli poistettu käytöstä, suorituskyky kasvoi 22 %, ja suorituskyky kasvoi 495 603 rekv/s:sta XNUMX XNUMX rekv/s.
- Vähentynyt käsittelijöiden siirtyminen eri prosessoriytimien välillä prosessorin välimuistin käytön tehostamiseksi. Optimointi suoritettiin sekä libreactor-prosessien sitomisen CPU-ytimiin (CPU Pinning) että ytimen verkkokäsittelijöiden kiinnityksen (Receive Side Scaling) tasolla. Esimerkiksi irqbalance poistettiin käytöstä ja jonoaffiniteetti suorittimeen oli asetettu nimenomaisesti tiedostossa /proc/irq/$IRQ/smp_affinity_list. Jos haluat käyttää samaa CPU-ydintä libreactor-prosessin ja saapuvien pakettien verkkojonon käsittelemiseen, käytetään mukautettua BPF-käsittelijää, joka yhdistetään asettamalla SO_ATTACH_REUSEPORT_CBPF-lippu vastaketta luotaessa. Lähtevien pakettien jonojen sitomiseksi prosessoriin asetuksia /sys/class/net/eth0/queues/tx- on muutettu /xps_cpus. Suorituskyvyn kokonaislisäys oli 38 %, ja suorituskyky kasvoi 603 tk/s:sta 834 XNUMX rekv/s:iin.
- Keskeytyksen käsittelyn ja kyselyn käytön optimointi. Adaptive-rx-tilan käyttöönotto ENA-ohjaimessa ja sysctl net.core.busy_read -tiedoston käsittely paransivat suorituskykyä 28 % (suorituskyky kasvoi 834 1.06 req/s:sta 361 M req/s:iin ja latenssi väheni 292 µs:sta XNUMX µs:iin).
- Järjestelmäpalvelujen poistaminen käytöstä, jotka johtavat tarpeettomaan verkkopinon tukkoon. Dhclientin poistaminen käytöstä ja IP-osoitteen manuaalinen asettaminen johtivat 6 %:n suorituskyvyn kasvuun ja suorituskyvyn kasvu 1.06 miljoonasta rekv/s:sta 1.12 miljoonaan req/s. Syy, miksi dhclient vaikuttaa suorituskykyyn, on liikenneanalyysissä raaka-socketin avulla.
- Fighting Spin Lock. Verkkopinon vaihtaminen "noqueue"-tilaan sysctl:n "net.core.default_qdisc=noqueue" ja "tc qdisc korvaa dev eth0 root mq" kautta johti 2 %:n suorituskyvyn kasvuun, ja suorituskyky kasvoi 1.12 miljoonasta req/s 1.15 miljoonaan. vaati/s.
- Viimeiset pienet optimoinnit, kuten GRO:n (Generic Receive Offload) poistaminen käytöstä komennolla "ethtool -K eth0 gro off" ja kuutioisen ruuhkanhallintaalgoritmin korvaaminen renolla käyttämällä sysctl:tä "net.ipv4.tcp_congestion_control=reno". Kokonaistuottavuuden kasvu oli 4 %. Suorituskyky kasvoi 1.15 miljoonasta rekv/s 1.2 miljoonaan rekv/s.
Toimineiden optimointien lisäksi artikkelissa käsitellään myös menetelmiä, jotka eivät johtaneet odotettuun suorituskyvyn kasvuun. Esimerkiksi seuraava osoittautui tehottomaksi:
- Libreactorin suorittaminen erikseen ei eronnut suorituskyvyltään sen suorittamisesta säilössä. Writev:n korvaaminen sendillä, maxevents-arvojen lisääminen epoll_waitissa ja GCC-versioiden ja lippujen kokeileminen eivät vaikuttaneet (vaikutus oli havaittavissa vain "-O3"- ja "-march-native"-lippujen kohdalla).
- Linux-ytimen päivittäminen versioihin 4.19 ja 5.4, SCHED_FIFO- ja SCHED_RR-ajastimien avulla, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=ts ja skew_tick=ts ei vaikuttaneet.
- ENA-ohjaimessa offload-tilojen käyttöönotolla (segmentointi, sirontakeräys, rx/tx-tarkistussumma), rakentaminen "-O3"-lipulla ja parametrien ena.rx_queue_size ja ena.force_large_llq_header käyttäminen ei vaikuttanut.
- Verkkopinon muutokset eivät parantaneet suorituskykyä:
- Poista IPv6 käytöstä: ipv6.disable=1
- Poista VLAN käytöstä: modprobe -rv 8021q
- Poista paketin lähteen tarkistus käytöstä
- net.ipv4.conf.all.rp_filter=0
- net.ipv4.conf.eth0.rp_filter=0
- net.ipv4.conf.all.accept_local=1 (negatiivinen vaikutus)
- 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
Lähde: opennet.ru