2012-01-24 10 views
10

Sto diventando migliaia di pacchetti eliminati da una scheda di rete Broadcom:come trovare i pacchetti che siamo lasciati

eth1  Link encap:Ethernet HWaddr 01:27:B0:14:DA:FE 
      UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 
      RX packets:2746252626 errors:0 dropped:1151734 overruns:0 frame:0 
      TX packets:4109502155 errors:0 dropped:0 overruns:0 carrier:0 
      collisions:0 txqueuelen:1000 
      RX bytes:427998700000 (408171.3 Mb) TX bytes:3530782240047 (3367216.3 Mb) 
      Interrupt:40 Memory:d8000000-d8012700 

Ecco la versione installata:

filename:  /lib/modules/2.6.27.54-0.2-default/kernel/drivers/net/bnx2.ko 
version:  1.8.0 
license:  GPL 
description: Broadcom NetXtreme II BCM5706/5708/5709 Driver 

I pacchetti vengono eliminati in rinfuse vanno da 500 a 5000 pacchetti più volte all'ora. Il server (con Postgres in esecuzione) sta funzionando bene - solo i dropps sono fastidiosi.

Dopo aver provato un sacco di cose diverse, mi chiedo: come posso sapere da dove vengono i pacchetti e perché sono stati eliminati?

risposta

3

(Per il beneficio di quelli che arrivano a questo tramite una ricerca) Ho visto lo stesso problema (anche con un modulo bnx2, IIRC).

Si potrebbe provare a disattivare il servizio irqbalance. Nel mio caso, ha completamente bloccato la soluzione.

Si prega di notare che non molto tempo fa, c'erano molti aggiornamenti (RHEL 6) per irqbalance. Gli aggiornamenti del firmware dovrebbero essere controllati sia per il sistema principale che per la scheda Ethernet.

Stavamo vedendo solo una sottorete molto grande con una grande quantità di attività broadcast/multicast. Non stavamo vedendo questo sulla stessa apparecchiatura su una parte meno rumorosa - ma ancora molto attiva - della rete.

Potenzialmente, anche l'impostazione della dimensione del buffer di squillo ethernet per la scheda NIC può essere utile. So che ci sono state alcune modifiche per sysctl su quella rete occupata ...

11

Un pacchetto scartato significa che il buffer utilizzato per memorizzare il pacchetto per l'inoltro/l'elaborazione è pieno. L'atto di esaminare i dati del pacchetto per informazioni implica che i dati da guardare sono in primo luogo (cosa che non si fa, perché non c'era spazio per archiviarli).

Un modo carino per visualizzare i dati che vengono rilasciati, è esaminare il dump del traffico per le richieste di ritrasmissione TCP che escono dal server. Quando manca un pacchetto TCP, per qualsiasi motivo, il server chiederà che venga inviato nuovamente. La ritrasmissione ti darà il contesto di conversazione che stai cercando.

In realtà suggerisco di dare un'occhiata allo switch/router a cui è collegato il server. Sarà in grado di darti una bella idea della perdita e del throughput dell'interfaccia verso il tuo server, permettendoti di diagnosticare, ad esempio, se la tua scheda è troppo lenta per il cavo.

EDIT

This blog post cita uno strumento chiamato dropwatch, che potrebbe dare qualche indizio pure.

+1

Vale la pena sottolineare che non ci sono build disponibili per Ubuntu al momento della stesura di questo - dropwatch è mantenuto e fornito per fedora/redhat .. – rasjani

+1

e anche allora, non ho mai trovato che sia terribilmente utile (o al meno utilizzabile) –

+0

Se davvero hai bisogno di dropwatch, trovi il rpm per la tua architettura e convertilo in un file deb con 'alien'. –

7

È possibile che si sia imbattuto in https://www.novell.com/support/kb/doc.php?id=7007165.

citazione:

Cominciando con kernel 2.6.37, è stato cambiato il significato del numero di pacchetti caduto. Prima, i pacchetti eliminati erano molto probabilmente a causa di un errore.Ora, il contatore rx_dropped mostra le statistiche per la perdita di frame a causa di:

arretrato Softnet completa - (misurato da/proc/net/softnet_stat)

Bad/tags Unintended VLAN

Anonimo/protocolli non registrati

IPv6 incornicia quando il server non è configurato per IPv6

Se qualsiasi frame soddisfano tali condizioni, sono caduto prima della stack di protocollo e il contatore rx_dropped viene incrementato.