Lösung 1:
Ehrlich gesagt würde ich Ubuntu dafür nicht verwenden ... aber es gibt Optionen, die auf jede Linux-Variante angewendet werden können.
Sie sollten Ihre Netzwerk-Stack-Puffer neu erstellen:
net.core.rmem_default = 10000000
net.core.wmem_default = 10000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
Wenn die Anwendung auf die Festplatte schreibt, wäre möglicherweise eine Änderung des Planers/Aufzugs erforderlich (z. B. die deadline
Aufzug).
Auf Serverebene können Sie den CPU-Governor und das Energie- und CPU-Frequenzmanagement (P-States, C-States) ändern.
Auf Betriebssystemebene können Sie die Echtzeitpriorität Ihrer Anwendung ändern (chrt
), Optimierung zur Reduzierung von Interrupts, Fixierung an eine CPU oder eine Gruppe von CPUs (taskset
) und Stoppen aller unnötigen Dienste oder Daemons.
Einige Vorschläge finden Sie auch unter:Fehlerbehebung bei Latenz zwischen zwei Linux-Hosts
Es ist schwierig, genauere Angaben zu machen, ohne die beteiligte Hardware oder Netzwerkausrüstung zu kennen.
Lösung 2:
Wenn Sie den Weg der hohen Leistung gehen, sollten Sie normalerweise so wenige andere (geplante) Prozesse wie möglich ausführen, da diese Ihre Anwendung beeinträchtigen.
Linux ist wie die klassischen UNIX-Betriebssysteme darauf ausgelegt, mehrere Anwendungen gleichzeitig auf faire Weise auszuführen, und versucht, Ressourcenverknappung zu verhindern, und Sie werden das Gegenteil anstreben und alles andere außer Ihrer Anwendung aushungern. Einfache Schritte auf Betriebssystemebene ändern das Nice-Level und die Echtzeitpriorität Ihrer Anwendung, ändern den Scheduler oder wählen einen Echtzeit-Kernel.
TCP/IP ist in der Regel darauf abgestimmt, Verbindungsabbrüche zu verhindern und die verfügbare Bandbreite effizient zu nutzen. Um die geringstmögliche Latenz aus einer sehr schnellen Verbindung herauszuholen, anstatt die höchstmögliche Bandbreite aus einer Verbindung herauszuholen, bei der einige Zwischenverbindungen stärker eingeschränkt sind, werden Sie die Abstimmung des Netzwerkstapels anpassen.
sysctl -a
zeigt Ihnen eine Vielzahl von Kernel-Einstellungen, die Sie anpassen können. Die Einstellungen hängen davon ab, ob Sie IPv4 oder IPv6 verwenden oder nicht, und was genau Sie bereits in Ihrer Anwendung tun, was aber von Interesse sein könnte:
net.ipv4.tcp_window_scaling=1
RFC 1323 – Unterstützung für IPV4-TCP-Fenstergrößen größer als 64 KB – im Allgemeinen erforderlich in Netzwerken mit hoher Bandbreitenet.ipv4.tcp_reordering=3
Die maximale Zeit, die ein IPV4-Paket in einem TCP-Paketstrom neu geordnet werden kann, ohne dass TCP einen Paketverlust annimmt und in einen langsamen Start übergeht.net.ipv4.tcp_low_latency=1
beabsichtigt, eine niedrige Latenz gegenüber einem höheren Durchsatz zu bevorzugen; Einstellung =1 deaktiviert IPV4-TCP-Prequeue-Verarbeitungnet.ipv4.tcp_sack=0
Die Einstellung auf 1 aktiviert die selektive Bestätigung für IPV4, was die Aktivierung von tcp_timestamps erfordert und etwas Paket-Overhead hinzufügt, den Sie nicht benötigen, wenn Sie keinen Paketverlust erlebennet.ipv4.tcp_timestamps=0
Nur empfohlen, wenn Sack benötigt wird.net.ipv4.tcp_fastopen=1
Aktivieren, um Daten im öffnenden SYN-Paket zu senden.
Die meisten, wenn nicht alle, sind in den Kernelquellen besser dokumentiert.
Sie können natürlich rohe TCP-Sockets codieren und den Kernel-TCP/IP-Stack insgesamt weitgehend umgehen.
Häufig laufen stark abgestimmte Systeme in einem vertrauenswürdigen Netzwerk und ihre lokalen (iptables) Firewalls sind deaktiviert.