Soluzione 1:
Onestamente, non userei Ubuntu per questo... ma ci sono opzioni che possono essere applicate a qualsiasi variante di Linux.
Ti consigliamo di aumentare i buffer dello stack di rete:
net.core.rmem_default = 10000000
net.core.wmem_default = 10000000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
Se l'applicazione sta scrivendo su disco, potrebbe essere necessario modificare lo scheduler/elevator (ad es. deadline
ascensore).
A livello di server, puoi modificare il governor della CPU e la gestione dell'alimentazione e della frequenza della CPU (Stati P, Stati C).
A livello di sistema operativo, puoi modificare la priorità in tempo reale della tua applicazione (chrt
), ottimizzando per ridurre gli interrupt, bloccandolo su una CPU o un gruppo di CPU (taskset
) e arrestando qualsiasi servizio o demone non necessario.
Puoi anche vedere alcuni suggerimenti su:Come risolvere i problemi di latenza tra 2 host Linux
È difficile essere più specifici senza conoscere l'hardware o le apparecchiature di rete coinvolte.
Soluzione 2:
Se stai percorrendo la strada delle prestazioni elevate, in genere vorrai eseguire il minor numero possibile di altri processi (pianificati) in quanto interferiranno con la tua applicazione.
Linux, come i classici sistemi operativi UNIX, è progettato per eseguire più applicazioni contemporaneamente in modo equo e cerca di prevenire la fame di risorse e tu mirerai al contrario, affamare tutto il resto tranne la tua applicazione. Semplici passaggi a livello di sistema operativo stanno cambiando il bel livello e la priorità in tempo reale della tua applicazione, cambiando lo scheduler o optando per un kernel in tempo reale.
Il protocollo TCP/IP è generalmente ottimizzato per evitare interruzioni della connessione e utilizzare in modo efficiente la larghezza di banda disponibile. Per ottenere la latenza più bassa possibile da un collegamento molto veloce, piuttosto che ottenere la massima larghezza di banda possibile da una connessione in cui alcuni collegamenti intermedi sono più vincolati, regolerai l'ottimizzazione dello stack di rete.
sysctl -a
ti mostrerà una serie di impostazioni del kernel che puoi regolare. Le impostazioni dipendono dal fatto che tu stia utilizzando o meno IPv4 o IPv6 e cosa esattamente fai già nella tua applicazione ma potrebbe essere interessante:
net.ipv4.tcp_window_scaling=1
RFC 1323 - supporto per dimensioni della finestra TCP IPV4 superiori a 64K - generalmente necessario su reti con larghezza di banda elevatanet.ipv4.tcp_reordering=3
Il numero massimo di volte in cui un pacchetto IPV4 può essere riordinato in un flusso di pacchetti TCP senza che TCP presupponga la perdita di pacchetti e vada in avvio lento.net.ipv4.tcp_low_latency=1
destinato a dare la preferenza a una bassa latenza rispetto a un throughput più elevato; l'impostazione =1disabilita l'elaborazione della precoda IPV4 tcpnet.ipv4.tcp_sack=0
l'impostazione su 1 abilita il riconoscimento selettivo per IPV4, che richiede l'abilitazione di tcp_timestamps e aggiunge un po' di overhead dei pacchetti, che non ti serve se non si verificano perdite di pacchettinet.ipv4.tcp_timestamps=0
Consigliato solo nei casi in cui è necessario il sacco.net.ipv4.tcp_fastopen=1
Abilita l'invio di dati nel pacchetto SYN di apertura.
La maggior parte, se non tutte, sono meglio documentate nei sorgenti del kernel.
Ovviamente puoi codificare i socket TCP non elaborati e in gran parte aggirare del tutto lo stack TCP / IP del kernel.
Spesso i sistemi altamente ottimizzati vengono eseguiti in una rete affidabile e avranno i loro firewall locali (iptables) disabilitati.