Avaldati üksikasjalik juhend Linuxi keskkonna timimise kohta, et saavutada maksimaalne HTTP päringute töötlemise tulemuslikkus. Pakutud meetodid võimaldasid tõsta JSON-i töötleja jõudlust, mis põhineb libreactor raamatukogul Amazon EC2 (4 vCPU) keskkonnas 224 000 API päringuni sekundis Amazon Linux 2 vaikeseadetega (kernel 4.14) 1,2 miljoni päringuni sekundis pärast optimeerimist (tõus 436%), samuti vähendada päringute töötlemise viivitusi 79%. Pakutud meetodid ei ole spetsiifilised libreactorile ja toimivad ka muude HTTP serveritega, sealhulgas nginx, Actix, Netty ja Node.js (libreactorit kasutati testides, kuna sellel põhinev lahendus näitas parimat jõudlust).
Peamised optimeerimised:
- libreactor'i koodi optimeerimine. Aluseks oli Techempoweri komplekti R18 versioon, mida on täiustatud CPU tuumade arvu piiramiseks mõeldud koodi eemaldamisega (see optimeerimine kiirus tõstis 25-27%), GCC-s kokkupanek valikutega "-O3" (kasv 5-10%) ja "-march-native" (5-10%), read/write üleskutsete asendamisega recv/send'ga (5-10%) ning pthreadide kasutamisel kulude vähendamisega (2-3%). Koodi optimeerimise järel oli kogu jõudluse kasvu 55%, ja läbilaskevõime tõusis 224k req/s-lt 347k req/s-le.
- Spekulatiivsete käskude täitmise haavatavuste kaitse väljalülitamine. Kogemus, kasutades järgmisi tuuma käivitamise parameetreid: «nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off», tõstis jõudlust 28% ning läbilaskevõime suurenes 347k req/s-st 446k req/s-ni. Eraldi parameetri «nospectre_v1» (Spectre v1 kaitse + SWAPGS) tõus oli 1-2%, «nospectre_v2» (Spectre v2 kaitse) — 15-20%, «pti=off» (Spectre v3/Meltdown) — 6%, «mds=off tsx_async_abort=off» (MDS/Zombieload ja TSX asünkroonne abort) — 6%. Lätku kaitsesätete muutmata jätmine L1TF/Foreshadow (l1tf=flush), iTLB multihit, spekulatiivne salvestusvahe ja SRBDS eest, mis ei mõjutanud jõudlust, kuna need ei olnud seotud testitud konfiguratsiooniga (nt spetsiifilised KVM, sisemise virtualiseerimise ja teiste CPU mudelite jaoks).
- Auditimehhanismide ja süsteemi kõnede blokeerimise väljalülitamine käsu abil «auditctl -a never,task» ning «—security-opt seccomp=unconfined» valiku määramine docker-konteineri käivitamisel. Üldine jõudluse tõus oli 11%, ja läbilaskevõime suurenes 446k req/s-st 495k req/s-ni.
- Iptables/netfilter'i deaktiveerimine tuuma seotud moodulite laadimise kaudu. Mõte väljalülitamisest, mis ei olnud konkreetse serverilahenduse puhul kasutusel, sai inspiratsiooni profiilimise tulemustest, mille kohaselt kulus nf_hook_slow funktsiooni täitmiseks 18% ajast. Täheldatakse, et nftables töötab tõhusamalt võrreldes iptables'iga, kuid Amazon Linuxis kasutatakse endiselt iptables'i. Iptables'i väljalülitamisega saavutati 22% jõudluse kasvu ja läbilaskevõime kasvas 495k req/s-lt 603k req/s-le.
- Erghe mälukäitlejate vahel erinevate CPU tuumade vahel on vähenenud, et suurendada protsessorikühvli kasutamise efektiivsust. Optimeerimist tehti nii libreactor protsesside tuumadele (CPU Pinning) sidumise tasemel kui ka tuumade võrgukäitlejate (Receive Side Scaling) kinnitamise kaudu. Näiteks keelati irqbalance ja seati järjekordade sidumised selgelt CPU-dele failis /proc/irq/$IRQ/smp_affinity_list. Ühe ja sama CPU tuuma kasutamiseks libreactor protsessi ja sissetulevate pakettide võrgurea töötlemiseks kasutati kohandatud BPF töötlejat, mis ühendati SO_ATTACH_REUSEPORT_CBPF lipu seadistamise kaudu soketi loomisel. Väljaminevate pakettide järjekordade sidumiseks CPU-dega muudetakse seadeid failis /sys/class/net/eth0/queues/tx-<n>/xps_cpus. Üksik muita tõus 38%, samas kui läbilööki tõusis 603k req/s pealt 834k req/s peale.
- Katkestuste töötlemise ja polling'i (polling) optimeerimine. Adaptive-rx režiimi sisselülitamine ENA draiveris ja sysctl net.core.busy_read manipuleerimine võimaldas suurendada tootlikkust 28% (läbilööki tõusis 834k req/s pealt 1.06M req/s peale, samas kui latentsus vähenes 361μs pealt 292μs peale).
- Süsteemiteenuste, mis põhjustavad liialt blokeeringut võrgu virnas, keelamine. dhclient'i keelamine ja käsitsi seadistamine IP-aadressid parandas jõudlust 6% võrra ning läbilaskevõime tõusis 1,06 M req/s-lt 1,12 M req/s-le. dhclient'i mõju jõudlusele on analüüsitud raw-socket'i liikluse jälgimise abil.
- Spin Lock'i vastu võitlemine. Võrgu virna ümberseadmine «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 ning läbilaskevõime tõusis 1,12 M req/s-lt 1,15 M req/s-le.
- Viimased väiksed optimiseerimised, nagu GRO (Generic Receive Offload) keelamine käsuga «ethtool -K eth0 gro off» ja ülekoormuse kontrollimise algoritmi vahetamine cubic'lt reno'le läbi sysctl «net.ipv4.tcp_congestion_control=reno». Üldine jõudluse kasvu saadi 4%. Läbilaskevõime tõusis 1,15 M req/s-lt 1,2 M req/s-le.
Lisaks käideldud optimiseerimistele käsitleb artikkel ka meetodeid, mis ei toonud oodatud jõudluse kasvu. Näiteks osutusid ebaefektiivseks:
- Erakordne libreactor'i käivitamine ei erine jõudluselt konteineris käivitamisest. Writev asendamine send-iga, maxevents suurendamine epoll_wait kannab mõju, samuti erinevate versioonide ja GCC-lippude katsetamine (efekt oli märgatav vaid lipu "-O3" ja "-march-native" puhul).
- Linuxi tuuma versioonide 4.19 ja 5.4 uuendamine ei avaldanud jõudlusele mõju, samuti SCHED_FIFO ja SCHED_RR ajakavad, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 ja clocksource=tsc manipuleerimine.
- ENA draiveris ei mõjutanud Offload režiimide (segmenteerimine, scatter-gather, rx/tx checksum) lubamine, -O3 lipuga kompileerimine ja parameetrite rakendamine ena.rx_queue_size ja ena.force_large_llq_header.
- Muudatused võrgu kuhjas ei suurendanud jõudlust:
- IPv6 keelamine: ipv6.disable=1
- VLAN-i keelamine: modprobe -rv 8021q
- Pakumi allika kontrollimise keelamine
- 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
