![\"Optimalisatie](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nBelangrijkste optimalisaties: <\/p>\n
- \n
- Optimalisatie van de libreactor-code. De basis was versie R18 uit de Techempower-set, die is verbeterd door code te verwijderen die het aantal gebruikte CPU-kernen beperkte (de optimalisatie versnelde de werking met 25-27%), het compileren in GCC met de opties '-O3' (een verbetering van 5-10%) en '-march-native' (5-10%), het vervangen van read\/write door recv\/send (5-10%) en het verlagen van overhead bij het gebruik van pthreads (2-3%). De algehele prestatieverbetering na de code-optimalisatie was 55%, terwijl de doorvoer steeg van 224k req\/s naar 347k req\/s.\n
- Het uitschakelen van bescherming tegen kwetsbaarheden door speculatieve uitvoering van instructies. Het gebruik van parameters bij het opstarten van de kernel 'nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off' resulteerde in een prestatieverbetering van 28%, terwijl de doorvoer steeg van 347k req\/s naar 446k req\/s. De afzonderlijke verbetering van de parameter 'nospectre_v1' (bescherming tegen Spectre v1 + SWAPGS) was 1-2%, 'nospectre_v2' (bescherming tegen Spectre v2) \u2014 15-20%, 'pti=off' (Spectre v3\/Meltdown) \u2014 6%, 'mds=off tsx_async_abort=off' (MDS\/Zombieload en TSX Asynchronous Abort) \u2014 6%. De instellingen voor bescherming tegen L1TF\/Foreshadow-aanvallen (l1tf=flush), iTLB multihit, Speculative Store Bypass en SRBDS zijn ongewijzigd gelaten, aangezien ze geen invloed hadden op de prestaties doordat ze niet overlapten met de geteste configuratie (bijvoorbeeld specifiek voor KVM<\/a>, geneste virtualisatie en andere CPU-modellen).\n
- Het uitschakelen van auditmechanismen en het blokkeren van systeemaanroepen met het commando 'auditctl -a never,task' en de optie '--security-opt seccomp=unconfined' bij het starten van de docker-container. De algehele prestatieverbetering was 11%, terwijl de doorvoer steeg van 446k req\/s naar 495k req\/s.\n
- Uitschakelen van iptables\/netfilter door het uitladen van de bijbehorende kernelmodules. De gedachte om de firewall uit te schakelen, die niet werd gebruikt in de specifieke serveroplossing, werd gestimuleerd door profielen die aangaven dat het uitvoeren van de functie nf_hook_slow 18% van de tijd in beslag nam. Het wordt opgemerkt dat nftables effici\u00ebnter werkt dan iptables, maar iptables blijft nog steeds gebruikt in Amazon Linux. Na het uitschakelen van iptables was er een prestatieverbetering van 22%, en de doorvoer nam toe van 495k req\/s naar 603k req\/s.\n
- Vermindering van migratie van verwerkers tussen verschillende CPU-cores om de effici\u00ebntie van de gebruik van de processork cache te verhogen. De optimalisatie werd uitgevoerd op zowel het niveau van procesbinding van libreactor aan CPU-cores (CPU Pinning) als via het vastleggen van netwerkinvoerverwerkers (Receive Side Scaling). Bijvoorbeeld, irqbalance is uitgeschakeld en de bindngen van wachtrijen aan de CPU zijn expliciet ingesteld in \/proc\/irq\/$IRQ\/smp_affinity_list. Voor het gebruik van dezelfde CPU-core voor het verwerken van libreactor-processen en de netwerkwachtrij van inkomende pakketten is een eigen BPF-handler ingezet, verbonden via het instellen van de SO_ATTACH_REUSEPORT_CBPF-vlag bij het maken van de socket. Voor de binding van de CPU aan uitgaande pakketwachtrijen zijn de instellingen in \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus gewijzigd. De totale prestatieverbetering was 38%, en de doorvoer steeg van 603k req\/s naar 834k req\/s.\n
- Optimalisatie van interruptverwerking en gebruik van polling. Het inschakelen van de adaptive-rx-modus in de ENA-driver en manipulatie van sysctl net.core.busy_read resulteerde in een prestatieverbetering van 28% (de doorvoer steeg van 834k req\/s naar 1.06M req\/s, terwijl de vertragingen daalden van 361\u00b5s naar 292\u00b5s).\n
- Uitschakelen van systeemdiensten die leiden tot onnodige blokkades in de netwerkstack. Het uitschakelen van dhclient en handmatige instelling IP-adressen<\/a> leidde tot een prestatieverbetering van 6%, en de doorvoer steeg van 1.06M req\/s naar 1.12M req\/s. De reden voor de impact van dhclient op de prestaties is geanalyseerd met behulp van raw-socket traffic.\n
- Bestrijding van Spin Lock. Het overzetten van de netwerkstack naar de 'noqueue'-modus via sysctl 'net.core.default_qdisc=noqueue' en 'tc qdisc replace dev eth0 root mq' leidde tot een prestatieverbetering van 2%, terwijl de doorvoer steeg van 1.12M req\/s naar 1.15M req\/s.\n
- Eindoptimalisaties zoals het uitschakelen van GRO (Generic Receive Offload) met het commando «ethtool -K eth0 gro off» en het vervangen van het congestie-algoritme cubic door reno met sysctl «net.ipv4.tcp_congestion_control=reno». De totale prestatiewinst was 4%. De doorvoersnelheid steeg van 1,15M req\/s naar 1,2M req\/s. <\/ul>\n
Naast de werkende optimalisaties worden in het artikel ook methoden besproken die niet hebben geleid tot de verwachte prestatieverbetering. Bijvoorbeeld, de volgende bleken ineffectief: <\/p>\n
- \n
- Een aparte uitvoering van libreactor had qua prestaties geen verschil met uitvoering in de container. Het vervangen van writev door send, het verhogen van maxevents in epoll_wait, en experimenten met versies en vlaggen van GCC hadden geen invloed (het effect was alleen merkbaar voor de vlaggen «-O3» en «-march-native»).\n
- De prestatie werd niet be\u00efnvloed door de update van de Linux-kernel naar versies 4.19 en 5.4, het gebruik van de planningsstrategie\u00ebn SCHED_FIFO en SCHED_RR, manipulaties met sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 en clocksource=tsc.\n
- In de ENA-driver had het inschakelen van Offload-modus (segmentation, scatter-gather, rx\/tx checksum), het bouwen met de vlag «-O3» en het toepassen van de parameters ena.rx_queue_size en ena.force_large_llq_header geen effect.\n
- De wijzigingen in de netwerkmiddleware leidden niet tot prestatieverbeteringen:\n