Soluzione 1:
Il problema potrebbe essere che stai ricevendo troppe interruzioni sulla tua scheda di rete. Se la larghezza di banda non è il problema, lo è la frequenza:
-
Attiva i buffer di invio/ricezione sulla scheda di rete
ethtool -g eth0
Ti mostrerà le impostazioni correnti (256 o 512 voci). Probabilmente puoi aumentarli a 1024, 2048 o 3172. Di più probabilmente non ha senso. Questo è solo un ring buffer che si riempie solo se il server non è in grado di elaborare i pacchetti in arrivo abbastanza velocemente.
Se il buffer inizia a riempirsi, il controllo di flusso è un mezzo aggiuntivo per dire al router o allo switch di rallentare:
-
Attiva il controllo del flusso in/outbound sul server e sulle porte switch/router a cui è collegato.
ethtool -a eth0
Probabilmente mostrerà:
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
Controllare /var/log/messages per l'impostazione corrente di eth0. Cerca qualcosa come:
eth0:il collegamento è attivo a 1000 Mbps, full duplex, controllo del flusso tx e rx
Se non vedi tx e rx, i tuoi amministratori di rete devono regolare i valori sullo switch/router. Su Cisco con controllo del flusso di ricezione/trasmissione attivo.
Attenzione: La modifica di questi valori porterà il tuo collegamento verso il basso e verso l'alto per un tempo molto breve (meno di 1 secondo).
-
Se tutto ciò non aiuta, puoi anche ridurre la velocità della scheda di rete a 100 MBit (fai lo stesso sulle porte switch/router)
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
Ma nel tuo caso direi:aumenta i buffer di ricezione nel ring buffer della NIC.
Soluzione 2:
Seguire potrebbe non essere la risposta definitiva, ma sicuramente svilupperà alcune idee
Prova ad aggiungerli a sysctl.conf
## tcp selective acknowledgements.
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1
Mentre tcp ack selettivo è buono per prestazioni ottimali nel caso di rete ad alta larghezza di banda. Ma attenzione agli altri inconvenienti però. I vantaggi del ridimensionamento della finestra sono descritti qui. Per quanto riguarda la terza opzione sysctl:per impostazione predefinita, TCP salva varie metriche di connessione nella route cache quando la connessione si chiude, in modo che le connessioni stabilite nel prossimo futuro possano utilizzarle per impostare le condizioni iniziali. Di solito, questo aumenta le prestazioni complessive, ma a volte può causare un degrado delle prestazioni. Se impostato, TCP non memorizzerà nella cache le metriche alla chiusura delle connessioni.
Controlla con
ethtool -k ethX
per vedere se l'offload è abilitato o meno. L'offload del checksum TCP e l'offload di segmenti di grandi dimensioni sono supportati dalla maggior parte delle NIC Ethernet odierne e apparentemente anche Broadcom lo supporta.
Prova a utilizzare lo strumento
powertop
mentre la rete è inattiva e quando viene raggiunta la saturazione della rete. Questo mostrerà sicuramente se gli interrupt NIC sono i colpevoli. Il polling del dispositivo è una risposta a tale situazione. FreeBsd supporta il polling switch direttamente all'interno di ifconfig ma Linux non ha tale opzione. Consultalo per abilitare il polling. Sta dicendo che BroadCom supporta anche i sondaggi, il che è una buona notizia per te.
La modifica del pacchetto Jumbo potrebbe non essere adatta a te poiché hai menzionato che il tuo traffico è costituito principalmente da piccoli pacchetti. Ma hey, provalo comunque!
Soluzione 3:
Ho notato nell'elenco delle modifiche che i timestamp sono disattivati, per favore non farlo. Questo è un vecchio ritorno ai tempi passati, quando la larghezza di banda era molto costosa e le persone volevano risparmiare qualche byte/pacchetto. Viene utilizzato, ad esempio, dallo stack TCP in questi giorni per dire se un pacchetto che arriva per un socket in "CLOSE_WAIT" è un vecchio pacchetto per la connessione o se è un nuovo pacchetto per una nuova connessione e aiuta nei calcoli RTT. E salvare i pochi byte per un timestamp non è NIENTE rispetto a ciò che aggiungeranno gli indirizzi IPv6. Disattivare i timestamp fa più male che bene.
Questa raccomandazione per la disattivazione dei timestamp è solo un ritorno al passato che continua a passare da una generazione di amministratori di sistema a quella successiva. Una specie di "leggenda metropolitana".
Soluzione 4:
è necessario distribuire il carico su tutti i core della CPU. Avvia 'irqbalance'.
Soluzione 5:
Nel mio caso solo una singola accordatura:
net.ipv4.tcp_timestamps = 0
apportato un cambiamento molto grande e utile, il tempo di caricamento del sito è diminuito del 50%.