[Debian] veel dropped packets?

[Verwijderd]

Hallo allemaal,

Sinds vandaag heb ik in een cluster van 5 machines (waarvan 1 het 'middelpunt' is en met vier gbit-netwerkkaarten en UTP-crosscables de rest aanstuurt) het probleem dat de hoeveelheid "dropped" packets gigantisch hoog oploopt. Voorbeeldje:

eth2      Link encap:Ethernet  HWaddr 00:0E:2E:70:7B:68
          inet addr:10.0.2.1  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:2eff:fe70:7b68/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:72167214 errors:0 dropped:251419 overruns:0 frame:0
          TX packets:23988813 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3952050019 (3.6 GiB)  TX bytes:3102237136 (2.8 GiB)
          Interrupt:217 Base address:0x4000

Dit geldt voor alle netwerkkaarten waar veel data overheen gaat. Ik weet niet precies wat dit 'dropped' precies inhoudt, maar ik weet wel dat het in andere netwerken waarop ik werk gewoon '0' is. Iemand enig idee hoe dit kan komen en hoe ik het kan debuggen?

[webfreakz.nl]

http://www.google.nl/sear...packets&btnG=Zoeken&meta=

levert: http://www.linuxquestions...s/showthread.php?t=238626

[Verwijderd]

Zulke topics ben ik inderdaad ook al tegengekomen, waar mensen klagen over een paar dropped packets. Echter, bij mij gaan het om enkele honderden duizenden! Vergeleken met het totaal aantal packets relatief niet heel veel, maar toch zeker significant!

Overigens draait er op de server geen enkele vorm van firewall (iptables), bovendien is het aantal gedropte packets aan de andere kant van de UTP crosscable gewoon '0'.

[ Voor 12% gewijzigd door Verwijderd op 26-09-2006 21:29 ]

[zomertje]

Het dataverkeer gaat wel goed verder? En als het voor meer dan 1 van de kaarten geldt dan kunnen we de kabel wel uitsluiten (tenzij de cross niet klopt oid) Ik neem aan dat het probleem zit bij het 'middelpunt'? Misschien een routingprobleem? Hoe weet die machine over welke netwerkkaart hij iets moet sturen?

[Verwijderd]

Dat is niet heel ingewikkeld, check de routetable (route -n):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.4.0        0.0.0.0         255.255.255.0   U     0      0        0 eth4
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth2
10.0.3.0        0.0.0.0         255.255.255.0   U     0      0        0 eth3
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.202   0.0.0.0         UG    0      0        0 eth0

Zelf begin ik eigenlijk te vermoeden dat het de kernel gewoon iets te veel wordt, 4 GBit-kaarten die zo snel mogelijk opereren. Om precies te zijn gaat het om een ENBD (Enhanced Network Block Device) cluster, waarbij het middelpunt RAID5 (momenteel resync) draait over geimporteerde block devices.

[ Voor 18% gewijzigd door Verwijderd op 26-09-2006 22:05 ]

[Verwijderd]

Wat geeft cat /proc/nbdinfo terug? Staan daar errors in?
Ik denk dat het eerste wat je zou moeten testen, je kabels zijn; ze even omwisselen en je hebt een (mogelijke) oorzaak uitgesloten.
Het zou best kunnen dat de kernel (je hardware dan dus) het niet "aan kan", maar dat zou dan volgens mij een I/O kwestie zijn. Je kunt met vmstat kijken hoe het met de performance van je subsystems zit.

Op wat voor een systeem draai je dit? Welke hardware ( goedkope NIC's?) gebruik je? Welke kernel draai je? Heb je em zelf gecompileerd? Je zou eens naar Networking -> Networking options-> QoS and/or fair queueing kunnen kijken, om zo de de scheduler aan je wensen aan te passen.

[Verwijderd]

Er staan wel wat errors geteld in /proc/nbdinfo, maar de developer van ENBD heeft al aangegeven dat de telling van errors niet betrouwbaar gebeurt. Ik zal het wel in de gaten houden...

Het zit hoogstwaarschijnlijk niet in de kabels: het betreft 1 gloednieuwe kabel, en drie zelfgeknepen kabels, allemaal geven ze dezelfde resultaten.

Wat hardware betreft is niet bezuinigd: een P4 3GHz met 512MB geheugen. De load op de server is nooit hoger dan 4, en de CPU is 50% van de tijd idle volgens top. De NICs zijn uitgerust met een Realtek 8169 chipset, die zouden toch gewoon een gigabit moeten kunnen halen, of in ieder geval iets in de buurt? Op dit moment gaat het met "slechts" 15 megabyte per seconde per interface.

Kernel:

uname -a
Linux infinity 2.6.16-2-686-smp #1 SMP Fri Aug 18 19:25:21 UTC 2006 i686 GNU/Linux

Dit is de standaard Debian testing kernel op een verder stable systeem, verder heb ik niets aan schedulers aangepast en ik vraag me af of dit mogelijk is zonder je kernel te recompilen. Ik kan nog niet echt wijs worden uit de output van vmstat, maar daar zal ik eens naar gaan kijken...

Elders op het internet heb ik iemand horen zeggen dat het wel eens aan SMP kan liggen, ik ga nu even een test draaien op een normale kernel.

edit: ook op een non-SMP-kernel krijg ik dropped packets. Wel ben ik er achter dat als ik de RAID resync speed naar beneden zet (/proc/sys/dev/raid/*), het aantal gedropte packets afneemt of zelfs verdwijnt. Maar ik heb natuurlijk dat gbit-netwerk liggen om snel over RAID te kunnen werken!

[ Voor 10% gewijzigd door Verwijderd op 27-09-2006 13:53 . Reden: testresultaat non-SMP kernel ]

[Verwijderd]

Inmiddels heb ik de r1000-driver van Realtek gedowload, die werkte (na aanpassen) wel goed, maar niet snel (ongeveer 1MB/s langzamer dan de r8169 driver). Eigenlijk komt het er dus op neer dat ik nu weliswaar zonder packet drops nog steeds op 100Mbit aan het communiceren ben, terwijl ik voor vier servers een gigabit twisted pair UTP heb liggen!