tcpdump aumenta le prestazioni udp

Sto eseguendo una serie di test di carico per determinare le prestazioni della seguente configurazione:

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

In breve, la suite di test node.js invia una determinata quantità di metriche ogni x secondi a un'istanza di StatsD che si trova su un altro server. Successivamente, StatsD scarica le metriche ogni secondo su un'istanza di Graphite situata sullo stesso server. Guardo quindi quante metriche sono state effettivamente inviate dalla suite di test e quante sono state ricevute da Graphite per determinare la perdita di pacchetti tra la suite di test e la grafite.

Tuttavia ho notato che a volte ho ottenuto percentuali di drop dei pacchetti molto grandi (si noti che viene inviato con il protocollo UDP), che vanno dal 20-50%. Quindi è stato quando ho iniziato a esaminare dove venivano rilasciati questi pacchetti, visto che potrebbe essere un problema di prestazioni con StatsD. Quindi ho iniziato a registrare le metriche in ogni parte del sistema per rintracciare dove si è verificato questo calo. Ed è qui che le cose si fanno strane.

Sto usando tcpdump per creare un file di acquisizione che ispeziono dopo l'esecuzione del test. Ma ogni volta che eseguo i test con tcpdump in esecuzione, la perdita di pacchetti è quasi inesistente! Sembra che tcpdump stia in qualche modo aumentando le prestazioni dei miei test e non riesco a capire perché e come. Sto eseguendo il comando seguente per registrare i messaggi tcpdump sia sul server che sul client:

tcpdump -i any -n port 8125 -w test.cap

In un caso di test particolare sto inviando 40000 metriche / s. Il test durante l'esecuzione di tcpdump ha una perdita di pacchetti di circa il 4% mentre quella senza una perdita di pacchetti di circa il 20%

Entrambi i sistemi funzionano come Xen VM con la seguente configurazione:

• Intel Xeon E5-2630 v2 a 2,60 GHz
• 2 GB di RAM
• Ubuntu 14.04 x86_64

Cose che ho già verificato per potenziali cause:

• Aumento della dimensione di ricezione / invio del buffer UDP.
• Carico della CPU che influisce sul test. (carico massimo del 40-50%, lato client e server)
• Esecuzione di tcpdump su interfacce specifiche anziché "qualsiasi".
• Esecuzione di tcpdump con '-p' per disabilitare la modalità promiscua.
• Esecuzione di tcpdump solo sul server. Ciò ha comportato una perdita di pacchetti del 20% e sembra non influire sui test.
• Esecuzione di tcpdump solo sul client. Ciò ha comportato un aumento delle prestazioni.
• Aumentando netdev_max_backlog e netdev_budget a 2 ^ 32-1. Questo non ha fatto differenza.
• Ho provato ogni possibile impostazione della modalità promiscua su ogni nic (server acceso e client spento, server spento e client acceso, sia acceso, sia spento). Questo non ha fatto differenza.

Quando tcpdump è in esecuzione, sarà abbastanza veloce da leggere nei frame in arrivo. La mia ipotesi è che le impostazioni del buffer dell'anello dei pacchetti della NIC potrebbero essere un po 'piccole; quando tcpdump è in esecuzione viene svuotato in modo più tempestivo.

Se sei un abbonato Red Hat, questo articolo di supporto è molto utile Panoramica sulla ricezione dei pacchetti . Ci sono alcune cose che non credo tu abbia ancora preso in considerazione.

Considera come il tuo sistema sta gestendo gli IRQ; prendere in considerazione l'idea di aumentare il "dev_weight" dell'interfaccia di rete (ovvero più pacchetti letti dalla NIC allo spazio utente); guarda con quale frequenza l'applicazione legge il socket (può usare un thread dedicato, ci sono problemi / soluzioni noti riguardo alla scalabilità).

Aumenta il buffer del frame NIC (usando il ethtoolcomando - guarda gli --set-ringargomenti ecc.).

Guarda 'ricevi ridimensionamento laterale' e usa almeno quel numero di thread di ricezione da leggere nel traffico.

Mi chiedo se tcpdump stia facendo qualcosa di interessante come usare il supporto del kernel per i buffer dei pacchetti di pacchetti . Ciò aiuterebbe a spiegare il comportamento che stai vedendo.

Quale regolatore di potenza stai usando? Ho visto comportamenti simili con il governatore "ondemand" o "conservatore".

Prova a utilizzare il "performance" governatore e a disabilitare tutte le funzionalità di risparmio energetico nel BIOS del server.

Cambia qualcosa?

Un altro modo è il ip_conntarckmodulo, sei sicuro che la tua linux-box possa accettare una nuova connessione? test tramite:

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

Devi testare

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

se max == count, la tua connessione massima è piena e la tua linux-box non può accettare una nuova connessione.
Se non si dispone di ip_conntrack, è possibile caricare facilmente tramitemodprobe ip_conntrack

Sospetto che il lato ricevente non sia semplicemente in grado di gestire la frequenza dei pacchetti ed ecco perché:

1. l'uso di tcpdump sul client riduce i pacchetti rilasciati: tcpdump sta rallentando il client e quindi il server sta vedendo una velocità di compressione molto più bassa che può ancora parzialmente gestire. Dovresti essere in grado di confermare questa ipotesi controllando i contatori di pacchetti RX / TX sia sul client che sul server

2. hai detto che hai aumentato la dimensione di ricezione / invio del buffer UDP, potresti spiegare come? È importante che sul server modifichi sia rmem_max che rmem_default, ad esempio: sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

Test delle tue impostazioni

Arresta statsd e l'applicazione nodo, quindi con i sistemi inattivi usa iperf per testare la velocità dei pacchetti che la rete / kernel può gestire. Se puoi trasmettere in streaming 40K pacchetti / i con iperf ma non puoi con statsd, dovresti concentrare i tuoi sforzi sull'ottimizzazione di statsd.

Altri parametri sintonizzabili

Ricorda anche di ottimizzare net.core.netdev_max_backlog : numero massimo di pacchetti autorizzati a mettere in coda quando una determinata interfaccia riceve pacchetti più velocemente di quanto il kernel possa elaborarli.