Avaldatud on üksikasjalik juhend Linuxi keskkonna häälestamiseks HTTP-päringute töötlemise maksimaalse jõudluse saavutamiseks. Kavandatud meetodid võimaldasid tõsta Amazon EC2 keskkonnas (4 vCPU) libreactori teegil põhineva JSON-protsessori jõudlust 224 tuhandelt API päringult sekundis Amazon Linux 2 standardseadetega koos tuumaga 4.14 kuni 1.2 miljoni päringuni. teine pärast optimeerimist (kasv 436%) ning viis ka taotluste töötlemise viivituste vähenemiseni 79%. Pakutud meetodid ei ole libreactorile omased ja töötavad teiste http-serverite, sh nginx, Actix, Netty ja Node.js kasutamisel (testides kasutati libreactorit, kuna sellel põhinev lahendus näitas paremat jõudlust).
Põhilised optimeerimised:
- libreactori koodi optimeerimine. Aluseks võeti Techempower komplekti R18 variant, mida täiustati koodi eemaldamisega, et piirata kasutatavate protsessorituumade arvu (optimeerimine võimaldas tööd kiirendada 25-27%), monteerides GCC-s valikutega “-O3” (kasv 5-10% ) ja "-march-native" (5-10%), asendades lugemise/kirjutamise kõned vastuvõtmise/saatmisega (5-10%) ja vähendades üldkulusid pthreadide kasutamisel (2-3%) . Üldine jõudluse kasv pärast koodi optimeerimist oli 55% ja läbilaskevõime suurenes 224 347 req/s-lt XNUMX XNUMX req/s-le.
- Keela kaitse spekulatiivse täitmise haavatavuste eest. Parameetrite “nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off” kasutamine kerneli laadimisel võimaldas jõudlust suurendada 28% ja läbilaskevõime suurenes 347 446 req/s-lt 1 1 req/s-ni. Eraldi suurenes parameetrist “nospectre_v1” (kaitse Spectre v2 eest + SWAPGS) 2–2%, “nospectre_v15” (kaitse Spectre v20 eest) – 3–6%, „pti=off” (Spectre v6/Meltdown) - 1%, "mds=off tsx_async_abort=off" (MDS/Zombieload ja TSX asünkroonne katkestamine) - 1%. LXNUMXTF/Foreshadow (lXNUMXtf=flush), iTLB multihit, Speculative Store Bypass ja SRBDS rünnakute vastase kaitse sätted jäeti muutmata, mis ei mõjutanud jõudlust, kuna need ei ristunud testitud konfiguratsiooniga (näiteks KVM-i spetsiifilised, pesastatud virtualiseerimine ja muud CPU mudelid).
- Auditeerimise ja süsteemikõnede blokeerimise mehhanismide keelamine, kasutades käsku "auditctl -a never,task" ja dokkimiskonteineri käivitamisel suvandi "--security-opt seccomp=unconfined" määramine. Üldine jõudluse kasv oli 11% ja läbilaskevõime kasvas 446 495 req/s-lt XNUMX XNUMX req/s-le.
- iptablesi/netfiltri keelamine, laadides maha seotud kerneli moodulid. Idee keelata tulemüür, mida konkreetses serverilahenduses ei kasutatud, ajendas profileerimise tulemused, mille põhjal otsustades võttis funktsiooni nf_hook_slow täitmine 18% ajast. Märgitakse, et nftables töötab tõhusamalt kui iptables, kuid Amazon Linux jätkab iptablesi kasutamist. Pärast iptablesi keelamist kasvas jõudlus 22% ja läbilaskevõime suurenes 495 603 req/s-lt XNUMX XNUMX req/s-ni.
- Käsitlejate vähendatud migratsioon erinevate CPU tuumade vahel, et parandada protsessori vahemälu kasutamise tõhusust. Optimeerimine viidi läbi nii libreactor-protsesside sidumise tasemel CPU tuumadega (CPU Pinning) kui ka kerneli võrguhaldurite kinnitamise (Receive Side Scaling) kaudu. Näiteks oli irqbalance keelatud ja järjekorra afiinsus CPU-ga määrati selgelt jaotises /proc/irq/$IRQ/smp_affinity_list. Sama protsessori tuuma kasutamiseks libreactori protsessi ja sissetulevate pakettide võrgujärjekorra töötlemiseks kasutatakse kohandatud BPF-käsitlejat, mis on ühendatud pistikupesa loomisel lipu SO_ATTACH_REUSEPORT_CBPF seadistamisega. Väljuvate pakettide järjekordade sidumiseks protsessoriga on muudetud sätteid /sys/class/net/eth0/queues/tx- /xps_cpus. Üldine jõudluse kasv oli 38% ja läbilaskevõime kasvas 603 834 req/s-lt XNUMX XNUMX req/s-le.
- Katkestuste haldamise ja pollimise kasutamise optimeerimine. Adaptive-rx režiimi lubamine ENA draiveris ja sysctl net.core.busy_read manipuleerimine suurendas jõudlust 28% (läbilaskvus suurenes 834 1.06 req/s-lt 361 M req/s-le ja latentsus vähenes 292 μs-lt XNUMX μs-le).
- Süsteemiteenuste keelamine, mis põhjustavad võrguvirnas tarbetut blokeerimist. Dhclienti keelamine ja IP-aadressi käsitsi seadistamine suurendas jõudlust 6% ja läbilaskevõime suurenes 1.06 miljonilt req/s-lt 1.12 miljoni req/s-ni. Põhjus, miks dhclient toimivust mõjutab, on liiklusanalüüsis töötlemata sokli abil.
- Spin Lockiga võitlemine. Võrgupinu lülitamine režiimile "noqueue" läbi sysctl "net.core.default_qdisc=noqueue" ja "tc qdisc asenda dev eth0 root mq" tõi kaasa 2% jõudluse kasvu ja läbilaskevõime suurenes 1.12 miljonilt req/s-lt 1.15 miljonile nõud/s.
- Viimased väiksemad optimeerimised, näiteks GRO (Generic Receive Offload) keelamine käsuga "ethtool -K eth0 gro off" ja kuubikujulise ummikukontrolli algoritmi asendamine renoga, kasutades sysctl "net.ipv4.tcp_congestion_control=reno". Üldine tootlikkuse kasv oli 4%. Läbilaskevõime kasvas 1.15 miljonilt req/s-lt 1.2 miljonile req/s-le.
Lisaks toiminud optimeerimistele käsitletakse artiklis ka meetodeid, mis ei toonud kaasa oodatud jõudluse kasvu. Näiteks osutus ebaefektiivseks järgmine:
- Libreactori eraldi käivitamine ei erinenud jõudluse poolest selle konteineris käitamisest. Writev asendamine sendiga, maxeventsi suurendamine epoll_waitis ning GCC versioonide ja lippudega katsetamine ei avaldanud mingit mõju (mõju oli märgatav ainult lippude “-O3” ja “-march-native” puhul).
- Linuxi kerneli uuendamine versioonidele 4.19 ja 5.4, kasutades SCHED_FIFO ja SCHED_RR planeerijaid, manipuleerides sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=ts ja ei mõjutanud jõudlust.
- ENA draiveris ei avaldanud offload-režiimide lubamine (segmenteerimine, hajumine, rx/tx kontrollsumma), lipuga "-O3" ehitamine ning parameetrite ena.rx_queue_size ja ena.force_large_llq_header kasutamine mingit mõju.
- Muudatused võrgupinus ei parandanud jõudlust:
- Keela IPv6: ipv6.disable=1
- Keela VLAN: modprobe -rv 8021q
- Keela paketi allika kontrollimine
- net.ipv4.conf.all.rp_filter=0
- net.ipv4.conf.eth0.rp_filter=0
- net.ipv4.conf.all.accept_local=1 (negatiivne mõju)
- 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
Allikas: opennet.ru