![\"Linux-Optimierung](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nWesentliche Optimierungen: <\/p>\n
- \n
- Optimierung des libreactor-Codes. Als Grundlage wurde die R18-Version aus dem Techempower-Kit verwendet, die durch das Entfernen des Codes zur Begrenzung der Anzahl genutzter CPU-Kerne optimiert wurde (dies f\u00fchrte zu einer Leistungssteigerung von 25-27%). Zudem wurde der GCC mit den Optionen \u201e-O3\u201c (Steigerung von 5-10%) und \u201e-march-native\u201c (5-10%) verwendet, die Aufrufe von read\/write durch recv\/send ersetzt (5-10%) und die Overhead-Kosten bei der Nutzung von pthreads gesenkt (2-3%). Der gesamte Leistungszuwachs nach der Code-Optimierung betrug 55%, w\u00e4hrend die Durchsatzrate von 224k req\/s auf 347k req\/s anstieg.\n
- Deaktivierung des Schutzes gegen Schwachstellen, die durch spekulative Anleitungsausf\u00fchrung verursacht werden. Die Verwendung der Boot-Parameter \u201enospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off\u201c hat die Leistung um 28 % gesteigert, w\u00e4hrend die Durchsatzrate von 347k req\/s auf 446k req\/s angestiegen ist. Der Beitrag des Parameters \u201enospectre_v1\u201c (Schutz gegen Spectre v1 + SWAPGS) betrug 1-2 %, \u201enospectre_v2\u201c (Schutz gegen Spectre v2) \u2013 15-20 %, \u201epti=off\u201c (Spectre v3\/Meltdown) \u2013 6 %, und \u201emds=off tsx_async_abort=off\u201c (MDS\/Zombieload und TSX Asynchronous Abort) \u2013 6 %. Die Einstellungen zum Schutz vor L1TF\/Foreshadow-Angriffen (l1tf=flush), iTLB Multihit, Spekulative Store Bypass und SRBDS wurden unver\u00e4ndert gelassen, da sie die Leistung nicht beeintr\u00e4chtigt haben, da sie nicht mit der getesteten Konfiguration \u00fcbereinstimmten (z. B. spezifisch f\u00fcr... KVM<\/a>, verschachtelte Virtualisierung und andere CPU-Modelle).\n
- Deaktivierung der Audit- und Blockierungsmechanismen f\u00fcr Systemaufrufe durch den Befehl \u201eauditctl -a never,task\u201c und Angabe der Option \u201e\u2014security-opt seccomp=unconfined\u201c beim Starten des Docker-Containers. Der Gesamte Leistungszuwachs betrug 11 %, und die Durchsatzrate stieg von 446k req\/s auf 495k req\/s.\n
- Deaktivierung von iptables\/netfilter durch das Entladen der zugeh\u00f6rigen Kernelmodule. Die Idee, die Firewall zu deaktivieren, die in dieser speziellen Serverl\u00f6sung nicht genutzt wurde, wurde durch Profilierungsergebnisse motiviert, die zeigten, dass 18 % der Zeit f\u00fcr die Ausf\u00fchrung der Funktion nf_hook_slow verwendet wurden. Es wird festgestellt, dass nftables effizienter als iptables arbeitet, jedoch wird in Amazon Linux weiterhin iptables verwendet. Nach der Deaktivierung von iptables betrug der Leistungszuwachs 22 %, und die Durchsatzrate stieg von 495k req\/s auf 603k req\/s.\n
- Reduzierung der Migration von Handlern zwischen verschiedenen CPU-Kernen zur Verbesserung der Nutzung des Prozessor-Caches. Die Optimierung erfolgte sowohl auf der Ebene der Prozessbindung von libreactor an die CPU-Kerne (CPU-Pinning) als auch durch die Festlegung von Netzwerk-Handler-Bindungen (Receive Side Scaling). Beispielsweise wurde irqbalance deaktiviert und die Bindungen von Warteschlangen an die CPU in \/proc\/irq\/$IRQ\/smp_affinity_list explizit festgelegt. Zur Nutzung desselben CPU-Kerns f\u00fcr die Verarbeitung des libreactor-Prozesses und der Netzwerkwarteschlange f\u00fcr eingehende Pakete wurde ein eigener BPF-Handler verwendet, der durch Setzen des Flags SO_ATTACH_REUSEPORT_CBPF beim Erstellen des Sockets angeschlossen wurde. F\u00fcr die Bindung der Warteschlangen f\u00fcr ausgehende Pakete wurden die Einstellungen in \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus ge\u00e4ndert. Der Gesamte Leistungszuwachs betrug 38%, und die Durchsatzrate stieg von 603k req\/s auf 834k req\/s.\n
- Optimierung der Interrupt-Verarbeitung und Nutzung von Polling. Die Aktivierung des adaptive-rx Modus im ENA-Treiber und Anpassungen von sysctl net.core.busy_read erm\u00f6glichten eine Leistungssteigerung von 28 % (die Bandbreite stieg von 834k req\/s auf 1,06M req\/s, w\u00e4hrend die Latenz von 361 \u00b5s auf 292 \u00b5s gesenkt wurde).\n
- Deaktivierung von Systemdiensten, die zu \u00fcberfl\u00fcssigen Blockierungen im Netzwerk-Stack f\u00fchren. Das manuelle Deaktivieren von dhclient und die entsprechende Einstellung IP-Adressen<\/a> f\u00fchrte zu einer Leistungssteigerung von 6 %, w\u00e4hrend die Bandbreite von 1,06M req\/s auf 1,12M req\/s anstieg. Der Einfluss von dhclient auf die Leistung wurde in einer Verkehrsanalytik unter Verwendung von Raw-Sockets untersucht.\n
- Bek\u00e4mpfung von Spin Locks. Der Wechsel des Netzwerkstacks in den 'noqueue'-Modus \u00fcber sysctl 'net.core.default_qdisc=noqueue' und 'tc qdisc replace dev eth0 root mq' f\u00fchrte zu einer Leistungssteigerung von 2 %, und die Bandbreite stieg von 1,12M req\/s auf 1,15M req\/s.\n
- Abschlie\u00dfende kleinere Optimierungen, wie die Deaktivierung von GRO (Generic Receive Offload) mit dem Befehl 'ethtool -K eth0 gro off' und der Wechsel des \u00dcberlastkontrollalgorithmus von cubic auf reno mittels sysctl 'net.ipv4.tcp_congestion_control=reno'. Die gesamte Leistungssteigerung betrug 4 %. Die Bandbreite stieg von 1,15M req\/s auf 1,2M req\/s. <\/ul>\n
Neben den durchgef\u00fchrten Optimierungen werden in diesem Artikel auch Methoden behandelt, die nicht zu dem erwarteten Leistungszuwachs f\u00fchrten. Beispielsweise erwiesen sich folgende Ma\u00dfnahmen als ineffektiv: <\/p>\n
- \n
- Der separate Start von libreactor zeigte keine Unterschiede in der Leistung im Vergleich zum Start in einem Container. Der Austausch von writev durch send, die Erh\u00f6hung von maxevents in epoll_wait und Experimente mit Versionen und GCC-Flags hatten keinen Einfluss (der Effekt war nur bei den Flags '-O3' und '-march-native' sichtbar).\n
- Das Update des Linux-Kernels auf die Versionen 4.19 und 5.4, die Verwendung der Scheduler SCHED_FIFO und SCHED_RR sowie Manipulationen mit sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 und clocksource=tsc hatten keinen Einfluss auf die Leistung.\n
- Im ENA-Treiber wurde die Aktivierung der Offload-Modi (Segmentierung, Scatter-Gather, Rx\/Tx-Pr\u00fcfziffer), die Kompilierung mit dem Flag «-O3» sowie die Anwendung der Parameter ena.rx_queue_size und ena.force_large_llq_header nicht beeinflusst.\n
- \u00c4nderungen im Netzwerk-Stack f\u00fchrten nicht zu einer Leistungssteigerung:\n