osa
Goto Top

Netzwerkgeschwindigkeit bricht ein - server oder switch problem?

Moin,

ich habe hier 50 clients, die über 100 Mbit und in 2 Netzwerken an einen Win2k (File)Server angeschlossen sind.
Dabei hat 1 Netzwerk Zugang zum Internet, das andere nicht.

Seit ein paar Wochen ist die Geschwindigkeit der Zugriffe auf den Fileserver tagsüber zum Teil stark beeinträchtigt.
Zu diesem Zeitpunkt sind aber auch noch ein paar clients (5) dazu gekommen.

Nun frage ich mich, wo ich ansetzen sollte. Die switche sind Bunt gemischt (vor meiner Zeit) ein HP (3 Jahre), ein 3com (3-4 Jahre),
2 Dell billig Dinger (1 Jahr), aber sie funktionieren, sonst würden einige gar keinen Zugriff erhalten.

Ich tippe da eher auf den server, der mit 4 Jahren ja nun auch schon recht betagt ist (wie ich finde).
Dell Server PE 2650. Könnte es sein das der weder die Anfragen übers Netz noch die E/As gebacken bekommt und deswegen die
performance so einbricht? Die Datenrate/s bricht auch immer zwischendurch ein, bei etwaigen Kopiervorgängen.

Am abend oder am morgen geht es normal fix.
Oder liegt das nur an den broadcasts der ganzen clients, die nun mittlerweile das Netz so dicht machen, das sich alles verzögert?

Für einen Ansatz wäre ich sehr dankbar.

Content-ID: 29903

Url: https://administrator.de/contentid/29903

Ausgedruckt am: 08.11.2024 um 05:11 Uhr

Supaman
Supaman 06.04.2006 um 17:18:07 Uhr
Goto Top
gibt viele möglichkeiten:
- zu wenig freier platz auf der swap-partition des servers
- hohe cpu last durch datenbankabfragen (sofern eine entsprechende applikation läuft)
- platten liefern nicht schnell genug die daten (eine 30er/40er Platte wär vor 4 jahren normal gewesen, ist aber im vergleich zu den neuen kriechend langsam)
- zu wenig ram, server muss oft swappen
- langsame cpu: um 100mbit mit voller rate zu betanken, sollte die cpu schon 2.5 ghz oder mehr haben
- gigabit anbindung an einen verteiler switch, an den dann die anderen 4-5 switches angeschlossen sind wär empfehlenswert
- fehlerhafte verkabelung-> viele datenfehler die durch crc-check doppelt gesent werden müssen-> durchsatzrate sinkt erheblich
- wie ist die cpu auslastung wenn das netz schneckt?

das mal so als ansatzpunkte..

gruß,

supa
aqui
aqui 06.04.2006 um 17:27:21 Uhr
Goto Top
Die Fehlerquellen, sofern es nur das Netz sein sollte, können vielfältig sein. Erstmal solltest du testen ob du wirklich ein Performance Problem mit deinem Server bzw. Client hat. Dafür eignet sich das Tool netio sehr gut:

www.wintotal.de/softw/index.php?rb=28&id=671

Das rennt im DOS Fenster und zeigt dir deine Netzwerkperformance bzw. die deiner Karten bei unterschiedlichen Packetgrößen. Ein Aufruf ohne Parameter zeigt die Bedienung, die recht einfach ist. Damit kannst du dann erstmal generell sagen wie performant deine Apapter bzw. der Switch ist. Adapterperformance allein kannst du natürlich nur mit einer Back to Back Verbindung ohne Switch verifizieren.

Da der Fehler sporadisch auftritt könnten das durchaus Broadcast Stürme sein, dazu musst du aber rausbekommen wer der Verursacher ist. Ein gutes Tool dafür ist Ethereal:

www.ethereal.com

Ein Sniffertool, der dir sowas anzeigt. Allerdings benutzt du Switches und da ist das Messen nicht ganz einfach denn normal siehst du nur Broad- und Multicast Packete an so einem Port, was aber ggf. schon ausreicht um Verdächtige zu identifizieren. Ansonsten musst du einen Mirror Port definieren und daran messen. Wie das geht steht im Manual deines Switchherstellers. Hast du allerdings einen nicht mangebaren Switch hast du Pech, denn diese bieten solch eine Möglichkeit eben aus Preisgründen nicht.
Solcherlei Low Budget Switches haben meist eine sehr schwache CPU. Diese muss bei entsprechender Broadcastlast alle Broadcast Packete n mal auf alle Ports kopieren. Das überfordert bei einer entsprechenden Grundlast meist solche Systeme, so das die dann Packets droppen und es zu Verlangsamung kommt, da die Endgeräte retransmitten müssen oder schlimmstenfalls die Sessions abbbrechen.

Weitere Möglichkeit ist ein NIC Negotiation Problem deines Servers oder deiner Server. D.h. die Karte hat z.B. Full Duplex negotiated und dein Switch aber nur Half Duplex. Solange du moderaten Netzwerktraffic hast fällt das nicht weiter auf, da man meistens ein Half Duplex Verhalten in der Kommunikation der Rechner hat über die Zeit gesehen. Steigt allerdings die Anzahl der Benutzer und Transaktionen mit dem Server kann es durch den ungleichen Modus zu Kollisionen auf dem Link kommen und alles rennt im 3. Gang. Intelligente Switches blocken außerdem kurzzeitig solche Ports wenn die Collision Rate einen bestimmten Wert übersteigt, was das Verhalten verschlimmert.
Solche Diskrepanzen erkennst du wenn du dir den Switchport über die Managementconsole ansiehst und dazu deine NIC im Server. Im Fehlerfalle hilft hier das Setzen BEIDER Seiten auf feste Werte sowohl für Speed als auch für den Duplex Modus. Hast du einen nicht managebaren Switch hast du leider Pech und must mit so einem Fehler leben, denn auf die Link LEDs kann man sich keineswegs verlassen.

Hast du das Netzwerk ausgeschlossen kommen noch die Server und Komponenten dran und das ist eine weitere Geschichte... (siehe Kommentar oben)
osa
osa 10.04.2006 um 09:48:26 Uhr
Goto Top
Erstmal vielen Dank für die sehr ausführlichen Antworten.

Die Serverlast ist sowohl bei der CPU als auch beim RAM völlig banal.
2x DC Xeon 1,8 Ghz, 8 GB RAM - die Auslastung steigt selten bei der CPU über 25/35% und beim RAM schon gar nicht.

Ich tippe daher eher auf die 4 Jahre alten RAID Systeme (Raid 5) und die Anzahl der gestiegenen Clients sowie schlappe Switche. Was bedeutet: ne Menge Schnüffelarbeit.

Ich werd mal eure Tipps umsetzen.
So ist das aber wohl immer, wenn man etwas organisch gewachsenes übernimmt. ;/
osa
osa 11.04.2006 um 15:05:04 Uhr
Goto Top
Hm,

Sowohl im Betrieb, als auch bei nur 2 Maschinen, die eingeschaltet sind erhalte ich folgende
Meldungen per Ethereal, vielleicht hat dazu noch jemand einen Tipp. Ergänzend werde ich dann morgen die switche durchtesten, sollten die in Ordnung sein liegt es wohl doch am server.

Wobei dann die Frage ist, wieso ist dies auch auf einem 2. neuen server das Problem...
Hier die Einträge:

SMB - NT Create Andx Request, Path (checksum error)
SMB - Close Request, FID: (checksum error)
SMB - Trans2 Request, FIND_FIRST2 (checksum error)
TCP - TCP segment of a reassembled PDU (kann ich nichts mit anfangen)
TCP - TCP checksum incorrect (das versteh sogar ich)
NBSS Continuation Message (Detail info: checksum incorrect)
TCP window Full

Falls dazu noch jemand einen Tipp hat: danke schon vorab.
aqui
aqui 12.04.2006 um 00:07:39 Uhr
Goto Top
Oha, dasklingt nicht gut. SMB ist Server Message Block, darunter kommuniziert Windows. PDU heisst Protocol Data Unit. Was aber sehr bedenklich ist das die Packet Checksum Fehler haben. Da muss man jetztmal schauen von wem genau diese Packete kommen. Das kann jetzt vielfältige Ursachen haben. Kaputte Netzwerkkkarte, kaputter Switch etc. Ggf. Back to Back Tests um Switches und andere aktive Komponenten auszuschliessen.
Ist auf alle Fälle eine höchst bedenkliche Fehlermeldung ! Solche Checksum Fehler treten sehr sehr selten in der Kommunikation auf. Wenn das gehäuft bei dir der Fall ist, ist da irgendwas fehlerhaft. Alle diese Packete werden verworfen, da sie eben fehlerhaft sind und die Endgeräte müssen retransmitten. Kein Wunder das dein Netz lahm ist...
osa
osa 12.04.2006 um 12:15:23 Uhr
Goto Top
Danke.

back to back test?
Könntest du das erläutern? bzw. das heißt vermutlich immer das gleiche Testfile unter Verwendung von verschiedenen Sende/Empfangspunkten zu verwenden?

Ich werde heute abend die switche einzeln durchtesten, jeweils mit nur 1 server, mit beiden servern (also alt + neu) und danach hoffentlich weitere Ergebnisse haben.
osa
osa 13.04.2006 um 03:25:21 Uhr
Goto Top
So.

so ganz blick ich das immer noch nicht, aber:
Beim Kontrollieren der Settings für die NICs am server (alt) waren Veränderungen, die quasi zu einer doppelt QoS geführt haben, was offenbar eine Überforderung war.

Egal welcher switch immer die checksum error. Auf dem backbone switch ist es nun an, dafür auf den NICs aus. Seitdem habe ich kaum noch checksum errors. Im Vergleich zu vorher (jedes 2./3. Paket) ca. noch jedes 800./1000. Paket. Das sollte soweit in Ordnung sein.

Ich habe nun fast nur noch: "TCP segment of a reassembled PDU" Sprich TCP Segment einer zusammengesetzten Protokoll Daten Einheit.

Da es sich um einen schlichten Kopiervorgang von server/client via smb handelt nehm ich mal er beschreibt das Zusammensetzen der TCP Segmente für die Schicht auf der SMB abläuft.

Desweiteren habe ich 2 weitere clients mit Problemen. server (alt) wie oben beschrieben (vorheriger Absatz) aber beim client erscheint immer die Meldung TCP window full/retransmission. Kann ich daraus schließen, das die Karte nicht hinterherkommt? (Client? wobei der zwischendurch mal keine fehler hatte)
der 3. Testclient sowie server2server hat keine fehler mehr, bis auf reassembled...

Oder lieg ich damit falsch? Ich glaube ich mache mal Pause und lass mich erstmal überraschen.
Ich bin jetzt viel zu lange auf und mache bestimmt Denkfehler, da hilft auch kein Kaffe mehr ;/

Erneut bedanke ich mich für weitere Sachdienliche Hinweise und entschuldige mich schonmal für Schlafmangel bedingte Fehler/falsche Beschreibungen. ;=))

Vielen Dank schon im vorraus
aqui
aqui 14.04.2006 um 19:17:36 Uhr
Goto Top
Kein Problem.... Mit Back to Back meinte ich einen Client mit Crosskabel einmal direkt an den Server zu hängen ohne Switch um zu sehen ob diese Fehler noch auftreten. Ziel wäre damit rauszubekommen ob ggf. der Switch die Fehler verursacht.
Ein sliding Window bei einer TCP Session ist nicht unbedingt ein Problem. So passen sich die Entgeräte an wenn einer zu schnell sendet und der andere nicht schnell genug empfangen kann.
Deinen Einwand mit "doppeltem QoS" verstehe ich jetzt nicht genau. Normalerweise könnte ein Endgerät 802.1q QoS Bits setzen aber das machen dann meistens die Applikationen, da das ja sinnvollerweise applikationsabhängig sein sollte und nicht generell alles per Schrotschuss priorisiert werden sollte. Der 2. Punt bei QoS ist die Frage ob dein Switch das überhaupt versteht. Gemeine Consumer Switches ala Netgear 8 Port u.ä. können sowas nicht und ignorieren das schlicht. Andere Switches wiederum haben ein default QoS Profile indem sie das Queueing steuern je nach gesetzem TOS Bit. Bei den meisten muss man das aber über das Konsolmanagement einstellen bzw. konfigurieren, sonst ignorieren sie schlicht QoS. "Doppeltes" QoS kann es so eigentlich nicht geben. Endweder sind die Bits gesetzt oder nicht.... Da bei Mittelklasse Switches sowas meist in Hardware passiert sollten die eigentlich nicht überfordert sein und auch sollten daraus niemals Checksum Errors resultieren. Es sei den.... Dein Switch versteht das überhaupt nicht. 802.1q ist ein zusätzlicher Tag der an den Ethernet Frame angehängt wird. Ist dein Switch nicht 802.1q fähig erkennt er möglicherweise diesen Frame nicht als gültigen Ethernet Frame und quittiert ihn als Collision oder Giant, was dann wieder andere Problem hinter sich herziehen kann. Du solltest auf alle Fälle sämtliches QoS ausschalten wenn du einfache nicht QoS fähige Switches einsetzt.
osa
osa 18.04.2006 um 09:58:45 Uhr
Goto Top
Vielen Dank,

4 von 5 switchen sind, ich sage mal "älter" und "günstig" und laut handbuch findet sich dort nichtmal im Ansatz etwas von QoS, der letzte hat eine Webgui wo man QoS aktivieren kann.
Zum anderen konnte ich am Server auf den NICs QoS aktivieren.

Jedoch verschwanden die cheksum error nachdem ich die Option auf den NICs deaktiviert habe.
Vermutlich konnte ein switch damit nicht anfangen, wobei ich alles switche einzeln rangehängt hatte und die Fehler auch beim "neueren" auftraten - allerdings nicht mehr nachdem die Option auf den NICs deaktiviert ist.

back-to-back werde ich dann nochmal testen. Bisher sind zwar die Fehler weg, aber die Geschwindigkeit ist immer noch nicht wirklich berauschend, aber immerhin nicht mehr kriechend.

Zusätzlich werd ich dann nochmal QoS komplett deaktivieren (also auch auf dem 1 switch)

Vielen Dank bis hierhin, hat mir immer neue Ansatzmöglichkeiten eröffnet. Ich gebe laut, sobald ich was neues habe.
osa
osa 24.04.2006 um 17:01:15 Uhr
Goto Top
So ich denke ich hab was gefunden, wenn auch eher durch Zufall.

Nachdem also keine Fehlermeldungen im traffic mehr auftauchen (bzw. sehr selten),
war ich ja etwas ratlos und wandte mich dem bösen server zu.

An diesem hängt ein Bandlaufwerk, für backup etc.
Als ich jetzt was zurücklas und zufällig mal auf die Datenrate des Laufwerks achtete, musste ich mit erschrecken lesen 280MB/m statt 490/600 MB/m

Was für mich bedeutet, das die Platten im server bzw. die I/O Rate am Server stark eingebrochen ist. Hat da jemand vielleicht ein paar tools/tipps, wie ich das System intensiver unter die Lupe nehmen kann?
z.B. Plattenperformancetest - Ich denke wirklich das es an den Platten liegt, was auch die Haker und Transferrateneinbrüche sinnig machen würde.

--
*edit*
anderes Thema, ich mache mal einen neuen thread dafür auf
Vielen Dank