Bol publikovaný podrobný návod na ladenie prostredia. Linux dosiahnuť maximálny výkon pri spracovaní HTTP požiadaviek. Navrhované metódy nám umožnili zvýšiť výkon analyzátora JSON založeného na knižnici libreactor v prostredí Amazon EC2 (4 vCPU) z 224 000 požiadaviek API za sekundu pri štandardných nastaveniach Amazonu. Linux Verzia 2 s jadrom 4.14 po optimalizácii zvýšila priepustnosť na 1.2 milióna požiadaviek za sekundu (nárast o 436 %) a tiež znížila latenciu spracovania požiadaviek o 79 %. Navrhované metódy nie sú špecifické pre libreactor a fungujú s inými HTTP servermi vrátane nginx, Actix, Netty a Node.js (libreactor bol použitý v testoch, pretože riešenie založené na ňom preukázalo lepší výkon).
Základné optimalizácie:
- Optimalizácia kódu Libreactor. Ako základ bola použitá možnosť R18 zo súpravy Techempower, ktorá bola vylepšená odstránením kódu na obmedzenie počtu použitých jadier CPU (optimalizácia umožnila zrýchlenie práce o 25-27%), zostavením v GCC s možnosťami „-O3“ (nárast o 5 – 10 % ) a „-march-native“ (5 – 10 %), čím sa nahrádzajú hovory na čítanie/zápis za hovory recv/send (5 – 10 %) a znižuje sa réžia pri použití pthreads (2 – 3 %) . Celkový nárast výkonu po optimalizácii kódu bol 55 % a priepustnosť sa zvýšila z 224 347 req/s na XNUMX XNUMX req/s.
- Vypnutie ochrany pred zraniteľnosťami spôsobenými špekulatívnym vykonávaním inštrukcií. Použitie parametrov zavádzania jadra „nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off“ zvýšilo výkon o 28 % a priepustnosť sa zvýšila z 347 kB/s na 446 kB/s. Jednotlivo bol zisk z parametra „nospectre_v1“ (ochrana pred Spectre v1 + SWAPGS) 1 – 2 %, „nospectre_v2“ (ochrana pred Spectre v2) – 15 – 20 %, „pti=off“ (Spectre v3/Meltdown) – 6 %, „mds=off tsx_async_abort=off“ (MDS/Zombieload a TSX Asynchrónne prerušenie) – 6 %. Nastavenia ochrany pred útokmi L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass a SRBDS, ktoré neovplyvnili výkon, zostali nezmenené, pretože sa neprelínali s testovanou konfiguráciou (napríklad sú špecifické pre KVM, vnorená virtualizácia a iné modely CPU).
- Zakázanie mechanizmov auditovania a blokovania systémových volaní pomocou príkazu "auditctl -a never,task" a zadaním možnosti "--security-opt seccomp=unconfined" pri spustení kontajnera docker. Celkový nárast výkonu bol 11 % a priepustnosť sa zvýšila zo 446 495 req/s na XNUMX XNUMX req/s.
- Zakázanie iptables/netfilter uvoľnením pridružených modulov jadra. Nápad zakázať firewall, ktorý sa nepoužíval v konkrétnom serverovom riešení, vznikol na základe výsledkov profilovania, ktoré ukázali, že funkcia nf_hook_slow strávila vykonávaním 18 % času. Je potrebné poznamenať, že nftables je efektívnejší ako iptables, ale na Amazone... Linux iptables sa naďalej používa. Po vypnutí iptables sa výkon zvýšil o 22 % a priepustnosť sa zvýšila zo 495 kB/s na 603 kB/s.
- Znížená migrácia obslužných programov medzi rôznymi jadrami CPU na zlepšenie efektívnosti využívania vyrovnávacej pamäte procesora. Optimalizácia bola vykonaná tak na úrovni viazania procesov libreactor na jadrá CPU (CPU Pinning), ako aj prostredníctvom pripájacích obslužných programov jadra (Receive Side Scaling). Napríklad irqbalance bola zakázaná a afinita frontu k CPU bola explicitne nastavená v /proc/irq/$IRQ/smp_affinity_list. Na použitie rovnakého jadra CPU na spracovanie procesu libreactor a sieťovej fronty prichádzajúcich paketov sa používa vlastný BPF handler, ktorý sa pripojí nastavením príznaku SO_ATTACH_REUSEPORT_CBPF pri vytváraní soketu. Aby sa fronty odchádzajúcich paketov naviazali na CPU, nastavenia /sys/class/net/eth0/queues/tx- boli zmenené /xps_cpus. Celkový nárast výkonu bol 38 % a priepustnosť sa zvýšila z 603 834 req/s na XNUMX XNUMX req/s.
- Optimalizácia manipulácie s prerušením a využívania pollingu. Povolenie režimu adaptive-rx v ovládači ENA a manipulácia so sysctl net.core.busy_read zvýšili výkon o 28 % (priepustnosť sa zvýšila z 834 1.06 req/s na 361 292 XNUMX req/s a latencia sa znížila z XNUMX μs na XNUMX μs).
- Zakázanie systémových služieb, ktoré spôsobujú zbytočné uzamknutia sieťového zásobníka. Zakázanie dhclient a inštalácia IP adresy Manuálne vykonanie tejto úlohy viedlo k 6% zvýšeniu výkonu, pričom priepustnosť sa zvýšila z 1.06 M požiadaviek/s na 1.12 M požiadaviek/s. Dôvodom vplyvu dhclient na výkon je analýza prevádzky pomocou surového soketu.
- Boj proti Spin Lock. Prepnutie sieťového zásobníka do režimu „noqueue“ prostredníctvom sysctl „net.core.default_qdisc=noqueue“ a „tc qdisc nahradiť dev eth0 root mq“ viedlo k zvýšeniu výkonu o 2 % a priepustnosti sa zvýšila z 1.12 milióna req/s na 1.15 milióna požiadavka/s.
- Posledné menšie optimalizácie, ako je zakázanie GRO (Generic Receive Offload) pomocou príkazu „ethtool -K eth0 gro off“ a nahradenie algoritmu riadenia kubického preťaženia reno pomocou sysctl „net.ipv4.tcp_congestion_control=reno“. Celkový nárast produktivity bol 4 %. Priepustnosť sa zvýšila z 1.15 milióna požiadaviek/s na 1.2 milióna požiadaviek/s.
Okrem optimalizácií, ktoré sa osvedčili, sa článok venuje aj metódam, ktoré neviedli k očakávanému zvýšeniu výkonu. Napríklad nasledovné sa ukázalo ako neúčinné:
- Samostatne spustený libreactor sa výkonom nelíšil od spustenia v kontajneri. Nahradenie writev send, zvýšenie maxeventov v epoll_wait a experimentovanie s verziami a príznakmi GCC nemalo žiadny účinok (účinok bol badateľný len pri príznakoch „-O3“ a „-march-native“).
- Aktualizácia jadra neovplyvnila výkon. Linux až po verzie 4.19 a 5.4, s použitím plánovačov SCHED_FIFO a SCHED_RR, manipuláciou so sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 a clocksource=tsc.
- V ovládači ENA nemalo povolenie režimov znižovania záťaže (segmentácia, zhromažďovanie bodov, kontrolný súčet rx/tx), vytváranie s príznakom „-O3“ a používanie parametrov ena.rx_queue_size a ena.force_large_llq_header žiadny účinok.
- Zmeny v sieťovom zásobníku nezlepšili výkon:
- Zakázať IPv6: ipv6.disable=1
- Zakázať VLAN: modprobe -rv 8021q
- Zakázať kontrolu zdroja balíka
- net.ipv4.conf.all.rp_filter=0
- net.ipv4.conf.eth0.rp_filter=0
- net.ipv4.conf.all.accept_local=1 (negatívny účinok)
- 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
Zdroj: opennet.ru
