![\"Optimering](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nHuvudoptimeringar: <\/p>\n
- \n
- Optimering av koden f\u00f6r libreactor. R18-versionen fr\u00e5n Techempower anv\u00e4ndes som grund och f\u00f6rb\u00e4ttrades genom att ta bort kod f\u00f6r att begr\u00e4nsa antalet anv\u00e4nda CPU-k\u00e4rnor (denna optimering \u00f6kade hastigheten med 25-27%), byggen i GCC med alternativen '-O3' (\u00f6kningsgrad 5-10%) och '-march-native' (5-10%), ers\u00e4ttning av read\/write-anrop med recv\/send (5-10%) och minskning av overhead vid anv\u00e4ndning av pthreads (2-3%). Den totala prestandaf\u00f6rb\u00e4ttringen efter kodoptimeringen var 55%, och genomstr\u00f6mningen \u00f6kade fr\u00e5n 224k req\/s till 347k req\/s.\n
- Inaktivering av skydd mot s\u00e5rbarheter orsakade av spekulativ exekvering av instruktioner. Anv\u00e4ndning av parametrarna vid k\u00e4rnladdning 'nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off' resulterade i en prestanda\u00f6kning p\u00e5 28%, och genomstr\u00f6mningen \u00f6kade fr\u00e5n 347k req\/s till 446k req\/s. Separat \u00f6kade parametern 'nospectre_v1' (skydd mot Spectre v1 + SWAPGS) med 1-2%, 'nospectre_v2' (skydd mot Spectre v2) med 15-20%, 'pti=off' (Spectre v3\/Meltdown) med 6%, och 'mds=off tsx_async_abort=off' (MDS\/Zombieload och TSX Asynchronous Abort) med 6%. Inst\u00e4llningarna f\u00f6r skydd mot L1TF\/Foreshadow-attacker (l1tf=flush), iTLB multihit, Speculative Store Bypass och SRBDS l\u00e4mnades of\u00f6r\u00e4ndrade, d\u00e5 de inte p\u00e5verkade prestandan eftersom de inte \u00f6verlappade med den testade konfigurationen (exempelvis specifika f\u00f6r) KVM<\/a>, inb\u00e4ddad virtualisering och andra CPU-modeller).\n
- Inaktivering av \u00f6vervaknings- och l\u00e5sning av systemanrop genom kommandot 'auditctl -a never,task' och angivande av alternativet '--security-opt seccomp=unconfined' vid start av Docker-kontainern. Den totala prestandaf\u00f6rb\u00e4ttringen var 11%, och genomstr\u00f6mningen \u00f6kade fr\u00e5n 446k req\/s till 495k req\/s.\n
- Avaktivering av iptables\/netfilter genom att avl\u00e4gsna de relaterade k\u00e4rnmodulerna. Id\u00e9n att st\u00e4nga av brandv\u00e4ggen, som inte anv\u00e4ndes i en specifik serverl\u00f6sning, kom fr\u00e5n profileringsresultat som visade att funktionen nf_hook_slow anv\u00e4nde 18% av tiden. Det noteras att nftables fungerar mer effektivt \u00e4n iptables, men iptables forts\u00e4tter att anv\u00e4ndas i Amazon Linux. Efter att ha st\u00e4ngt av iptables \u00f6kade prestandan med 22%, och kapaciteten steg fr\u00e5n 495k req\/s till 603k req\/s.\n
- Minskning av migreringen av hanterare mellan olika CPU-k\u00e4rnor f\u00f6r att \u00f6ka effektiviteten i anv\u00e4ndningen av processorcache. Optimering har genomf\u00f6rts b\u00e5de p\u00e5 niv\u00e5n av processbinding med libreactor till CPU-k\u00e4rnor (CPU Pinning) och genom att binda n\u00e4tverksbehandlare p\u00e5 k\u00e4rnniv\u00e5 (Receive Side Scaling). Till exempel har irqbalance st\u00e4ngts av och k\u00f6ernas kopplingar har st\u00e4llts in i \/proc\/irq\/$IRQ\/smp_affinity_list. F\u00f6r att anv\u00e4nda samma CPU-k\u00e4rna f\u00f6r att hantera libreactor-processen och n\u00e4tverksk\u00f6n av inkommande paket har en egen BPF-behandlare anv\u00e4nts, ansluten genom att s\u00e4tta flaggan SO_ATTACH_REUSEPORT_CBPF vid skapandet av sockeln. F\u00f6r att binda utg\u00e5ende paketk\u00f6er till CPU har inst\u00e4llningarna i \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus \u00e4ndrats. Den totala prestanda\u00f6kningen var 38%, och kapaciteten steg fr\u00e5n 603k req\/s till 834k req\/s.\n
- Optimering av avbrottshantering och anv\u00e4ndning av polling. Aktivering av l\u00e4get adaptive-rx i ENA-drivrutinen och manipulations av sysctl net.core.busy_read resulterade i en prestanda\u00f6kning p\u00e5 28% (genomstr\u00f6mningen \u00f6kade fr\u00e5n 834k req\/s till 1.06M req\/s, och f\u00f6rdr\u00f6jningarna minskade fr\u00e5n 361\u00b5s till 292\u00b5s).\n
- Avaktivering av systemtj\u00e4nster som orsakar on\u00f6diga blockeringar i n\u00e4tverksstacken. St\u00e4ngning av dhclient och installation IP-adresser<\/a> manuellt ledde till en prestanda\u00f6kning p\u00e5 6%, och kapaciteten \u00f6kade fr\u00e5n 1.06M req\/s till 1.12M req\/s. Orsaken till dhclients p\u00e5verkan p\u00e5 prestanda i trafikanalysen med hj\u00e4lp av raw-socket.\n
- Bek\u00e4mpning av Spin Lock. \u00d6verf\u00f6ring av n\u00e4tverksstacken till l\u00e4get 'noqueue' via sysctl 'net.core.default_qdisc=noqueue' och 'tc qdisc replace dev eth0 root mq' ledde till en prestanda\u00f6kning p\u00e5 2%, och genomstr\u00f6mningen \u00f6kade fr\u00e5n 1.12M req\/s till 1.15M req\/s.\n
- Slutliga sm\u00e5 optimeringar, s\u00e5som att st\u00e4nga av GRO (Generic Receive Offload) med kommandot «ethtool -K eth0 gro off» och byta algoritm f\u00f6r \u00f6verbelastningskontroll fr\u00e5n cubic till reno med hj\u00e4lp av sysctl «net.ipv4.tcp_congestion_control=reno». Den totala prestanda\u00f6kningen var 4%. Genomstr\u00f6mningen \u00f6kade fr\u00e5n 1.15M req\/s till 1.2M req\/s. <\/ul>\n
F\u00f6rutom de framg\u00e5ngsrika optimeringarna diskuteras i artikeln ocks\u00e5 metoder som inte ledde till den f\u00f6rv\u00e4ntade prestanda\u00f6kningen. Till exempel visade sig f\u00f6ljande vara ineffektiva: <\/p>\n
- \n
- En separat k\u00f6rning av libreactor visade ingen skillnad i prestanda j\u00e4mf\u00f6rt med k\u00f6rning i en container. Bytet fr\u00e5n writev till send, \u00f6kningen av maxevents i epoll_wait, och experimenteringar med versioner och flaggor i GCC p\u00e5verkade inte resultatet (effekten var m\u00e4rkbar endast f\u00f6r flaggorna «-O3» och «-march-native»).\n
- Uppdatering av Linux-k\u00e4rnan till versioner 4.19 och 5.4, anv\u00e4ndning av schemal\u00e4ggarna SCHED_FIFO och SCHED_RR, samt manipulationer med sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 och clocksource=tsc p\u00e5verkade inte prestandan.\n
- Aktivering av Offload-l\u00e4gen (segmentation, scatter-gather, rx\/tx checksum) hade ingen p\u00e5verkan i ENA-drivrutinen, inte heller byggandet med flaggan «-O3» och anv\u00e4ndning av parametrarna ena.rx_queue_size och ena.force_large_llq_header.\n
- \u00c4ndringar i n\u00e4tverksstacken ledde inte till en \u00f6kning av prestandan:\n