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.
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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 29903
Url: https://administrator.de/contentid/29903
Ausgedruckt am: 25.11.2024 um 23:11 Uhr
10 Kommentare
Neuester Kommentar
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
- 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
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)
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)
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...
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...
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.
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.