Linuxi optimeerimine, et töödelda 1,2 miljonit JSON-i päringut sekundis

Avaldati üksikasjalik juhend Linuxi keskkonna tuuninguks HTTP-päringute maksimaalse tõhususe saavutamiseks. Pakutud meetodid võimaldasid tõsta JSON-i töötleja, mis põhines libreactor-raamatukogul, jõudlust Amazon EC2 (4 vCPU) keskkonnas 224 000 API-päringult sekundis Amazon Linux 2 vaikeseadetes 4.14 tuumaga 1,2 miljoni päringuni sekundis pärast optimeerimist (kasvu 436%), ning vähendada päringute töötlemise viivitusi 79%. Pakutud meetodid ei ole spetsiifilised libreactorile ja töötavad ka teiste http-serverite, sealhulgas nginx, Actix, Netty ja Node.js, puhul (libreactorit kasutati testides, kuna selle põhine lahendus näitas parimat jõudlust).

Peamised optimeerimised:

• libreactori koodi optimeerimine. Aluseks kasutati Techempoweri R18 erinevust, millel eemaldati kood CPU tuumade arvu piiramise jaoks (optimeerimine võimaldas kiirus tõsta 25-27%), GCC kogumine valikutega „-O3” (kasv 5-10%) ja „-march-native” (5-10%), read/write kutsete asendamine recv/send kutsega (5-10%) ning pthreadide kasutamisega seotud kulude vähendamine (2-3%). Kode optimeerimise pärast üldine tõus jõudluses oli 55%, ja läbilaskevõime tõusis 224k req/s-st 347k req/s-ni.
• Spetsulatuslike täideviimise kaitse funktsioonide keelamine. YTWR-i laadimisparameetrite kasutamine „nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off” võimaldas jõudlust tõsta 28%, ja läbilaskevõime tõusis 347k req/s-st 446k req/s-ni. Üksikutest parameetritest „nospectre_v1” (Spectre v1 + SWAPGS kaitse) tõus oli 1-2%, „nospectre_v2” (Spectre v2 kaitse) tõusis 15-20%, „pti=off” (Spectre v3/Meltdown) - 6%, „mds=off tsx_async_abort=off” (MDS/Zombieload ja TSX Asynchronous Abort) - 6%. Loodud konfiguratsiooniga sobimatud ja jõudlusele mitte mõju avaldavad L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass ja SRBDS kaitse seadistused jäid muutmata. KVM, sisemiste virtualiseerimise ja teiste CPU mudelite korral.
• Auditmehhanismide ja süsteemi kutsete blokeerimise keelamine käsuga „auditctl -a never,task” ning docker konteineri käivitamisel valiku „—security-opt seccomp=unconfined” määramine. Üldine jõudluse tõus oli 11%, ja läbilaskevõime tõusis 446k req/s-st 495k req/s-ni.
• Iptables/netfilter'i keelamine seotud tuumamoodulite laadimise kaudu. Ideed tulemüüri välja lülitamiseks, mida ei kasutatud spetsiifilises serverilahenduses, toetas profiilimise tulemused, mille kohaselt kulus nf_hook_slow funktsiooni täitmiseks 18% ajast. Tähendatud on, et nftables töötab efektiivsemalt kui iptables, kuid Amazon Linuxis kasutatakse endiselt iptables'i. Iptables'i keelamise järel kasvas jõudlus 22%, samas kui läbilaskevõime suurenes 495k req/s-lt 603k req/s-le.
• Migratsiooni vähendamine erinevate CPU tuumade vahel, et tõsta protsessori vahemälu efektiivset kasutamist. Optimeerimine viidi läbi nii protsesside libreactor tuumadele kinnitamise (CPU Pinning) kui ka tuuma võrgu töötlejate kinnitamise (Receive Side Scaling) tasandil. Näiteks keelati irqbalance ja kinnitati järjekordade seosed ühele tuumale /proc/irq/$IRQ/smp_affinity_list failis. Protsessi libreactor ja sissetuleva võrgu pakettide töötlemiseks kasutati sama CPU tuuma jaoks oma BPF töötlejat, mis aktiveeriti SO_ATTACH_REUSEPORT_CBPF lipu seadistamise kaudu soketi loomisel. Väljuvate pakettide järjekordade kinnitamiseks CPU-le muudeti seadistusi /sys/class/net/eth0/queues/tx-<n>/xps_cpus. Üldine jõudluse tõus oli 38%, samas kui läbilaskevõime suurenes 603k req/s-lt 834k req/s-le.
• Katkestuste töötlemise ja poleerimise (polling) optimeerimine. Adaptivse RX režiimi aktiveerimine ENA draiveris ja sysctl net.core.busy_read seadistamine aitas tõsta jõudlust 28% (läbilaskevõime suurenes 834k req/s-lt 1.06M req/s-le, ja latentsus langes 361μs-lt 292μs-le).
• Süsteemiteenuste keelamine, mis põhjustavad liigseid blokeeringuid võrgu stack'is. dhclient'i keelamine ja seadistamine IP-aadressid käsitsi tõi kaasa jõudluse kasvu 6%, samas kui läbilaskevõime suurenes 1.06M req/s-lt 1.12M req/s-le. dhclient'i mõju jõudlusele selgub toorme soketi abil liikluse analüüsimisel.
• Spin Lock'iga võitlemine. Võrgustiku stack'i üleviimine "noqueue" režiimi läbi sysctl "net.core.default_qdisc=noqueue" ja "tc qdisc replace dev eth0 root mq" tõi kaasa 2% jõudluse kasvu, samas kui läbilaskevõime suurenes 1.12M req/s-lt 1.15M req/s-le.
• Lõplikud väiksed optimeerimised, nagu GRO (Generic Receive Offload) väljalülitamine käsuga «ethtool -K eth0 gro off» ja kontrolli algoritmi vahetamine cubicilt renole sysctl abil «net.ipv4.tcp_congestion_control=reno». Üldine jõudluse kasv oli 4%. Läbivus suurenes 1.15M req/s-lt 1.2M req/s-le.

Lisaks rakendatud optimeerimistele käsitleb artikkel ka meetodeid, mis ei toonud oodatud jõudluse kasvu. Näiteks osutusid ebaefektiivseteks:

• Erinev libreactori käivitamine ei erinenud konteineris käitamisest jõudluse poolest. Kirjutamise asendamine sendiga, maxevents suurendamine epoll_wait-is, GCC versioonide ja lippude katsetamine ei avaldanud mõju (efekt oli märgatav ainult lippude «-O3» ja «-march-native» puhul).
• Linuxi tuuma uuendamine versioonidele 4.19 ja 5.4 ei mõjutanud jõudlust, samas kui SCHED_FIFO ja SCHED_RR planeerijate kasutamine, sysctl muutujaid nagu kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 ja clocksource=tsc manipuleerimine ei avaldanud mõju.
• ENA draiveris ei avaldanud Offload-režiimide (segmenteerimine, scatter-gather, rx/tx checksum) lubamine, -O3 lipu kasutamine ja parameetrite ena.rx_queue_size ning ena.force_large_llq_header rakendamine mõju.
• Võrgu hunniku muudatused ei toonud kaasa jõudluse tõusu:
  • IPv6 väljalülitamine: ipv6.disable=1
  • VLAN-i väljalülitamine: modprobe -rv 8021q
  • Paketi allika kontrollimise väljalülitamine
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1 (negatiivne efekt)
  • 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