Kurioses Performanceproblem

[ipzipzap 10]

So, eingelesen *G*

 

@DJMaker: Dein Tip bzgl. SMB-Signing bezieht sich jetzt auf die Kommunikation mit dem NAS, richtig? Damit habe ich ja kein Problem. Wäre SMB-Signing falsch konfiguriert, würde ich ja überhaupt keinen Zugriff auf das NAS bekommen.

Ich weiß jetzt nicht, ob Du den kompletten Thread gelesen hast, aber um das NAS geht es hier auch überhaupt nicht.

 

Lassen wir das NAS mal weg und bleiben wir innerhalb der Domäne.

 

Wie schon vorher geschrieben:

Starte ich einen Kopiervorgang am Client, bekomme ich ca. 70MB/s.

Sterte ich den Kopiervorgang am Server, bekomme ich nur ca. 30MB/s.

 

Alles innerhalb der Domäne zwischen Server und Clients.

 

cu,

Dino

[ipzipzap 10]

Könnte es sein dass evtl. irgend eine Protokollierung (Netz,-monitor, Zugriff ect.) läuft? Der Virenscanner ist glaube ich weiter oben schon erwähnt worden.

 

Nein, nichts dergleichen.

[BrainStorm 10]

Mal weiter runter im OSI-Modell ;)

Hast du die Verkabelung geprüft/getauscht? Den Switchport mal gewechselt?

 

Siehst du auf dem Switch vielleicht irgendwelche Retransmits oder verworfene Pakete?

[wissbegierig 10]

Hallo,

 

siehe Hier: Gruppenrichtlinien - Übersicht, FAQ und Tutorials

 

...wenn man dem glauben schenkt dann kann der SMB Signings zu performance einbussen führen.

[ipzipzap 10]

Hmm, ich habe da in der Microsoft-KB etwas "ähnliches" gefunden:

 

Slow SMB performance when you copy files from Windows XP to a Windows 2000 domain controller

Slow performance occurs only when you copy files from a Windows XP-based client to a Windows 2000-based domain controller (push mode) and not when you copy files from the domain controller to the client (get mode).

 

Gilt hier zwar nur für XP und 2K-Server und außerdem ist es das umgekehrte Problem (bei mir im Push-Mode langsam und nicht beim Get-Mode), aber vielleicht bringt uns das ja evtl. in die richtige Richtung.

 

Da der Artikel für Win2000 Server ist und nicht für 2003, habe ich die Workarounds darin noch nicht angewandt.

Irgendwelche Vorschläge?

 

Dino

[wissbegierig 10]

Hallo Dino,

 

ich denke du hast recht mit der Annahme, dass es am SMB liegt, weil es bekannt ist das es bei eingestelltem SMB zu geschwindigkeitseinbussen (Microsoft sagt zwischen 10-15 normal) kommt, vor allem bei älteren Geräten (Netzkarten, HDD ect) kann es aber deutlich mehr sein. Ich würde vorschlagen für Testzwecke Daten zwischen Client und Server ohne SMB und ohne SCSI hin und her zu schicken und dann wieder mit SMB. Das ganze natürlich mit Messung, dann weißt du es genau. so kannst du nach und nach die Hardware abklappern. Sei so gut und schreib dann das Ergebnis. Viel erfolg!:) Hier noch ein Link: SMB Signing unter Windows - Systemfehler 1240 :: network lab

[wissbegierig 10]

Hallo Dino,

Ach ja...mit was stellst du denn die Messung an? Ich habe selber noch nicht das ideale Werkzeug gefunden....

[ipzipzap 10]

Also die LAN-Messungen ein paar Postings weiter vorne habe ich ja mit NetIO gemacht. Ansonsten nehme ich für "Real-World"-Tests einfach die Anzeige vom Total Commander, den ich als Dateimanager nutze. Der zeigt während des Kopiervorganges immer die gerade aktuelle Geschwindigkeit an.

Dem Explorer kann man da ja eh nicht vertrauen, der zeigt allzuoft irgendwelche Phantasiewerte an.

 

cu,

Dino

[ipzipzap 10]

Soo, also die Einstellungen bzgl. SMB-Signing haben nichts gebracht... immer noch dasselbe Problem :-(

 

Noch irgendwelche anderen Ideen? Ich bin so langsam mit meinem Latein am Ende :-(

[NorbertFe 1.799]

bekannt ist das es bei eingestelltem SMB zu geschwindigkeitseinbussen (Microsoft sagt zwischen 10-15 normal) kommt,

 

Ich vermute mal, du beziehst dich hierauf:

How to enable SMB signing in Windows NT

 

Der Artikel bezieht sich auf NT 4.0 und wahrscheinlich auch auf die damals aktuelle Hardwaregeneration. INsofern bezweifle ich jetzt einfach mal (ich habe keine objektiven Messdaten), dass diese Ziffern bei aktueller Hardware tatsächlich noch stimmen können. Wenns jemand testen will, kann er hier ja gern mal die Daten bereitstellen.

 

Bye

Norbert

[nerd 28]

Hi,

 

gerade kommt mir noch ne Idee - wie sehen denn deine GPO's zum Thema IPSec aus?

 

LG

[zahni 521]

Deaktiviere mal am Client dieses QoS-Client.

 

Füge mal beim Client den Parameter sizreqbuf mit 0x0000ffff hinzu: Slow file write from Windows 2000 or Windows Server 2003 to Windows NT 4.0 Server

 

Dein Problem: Bei der 1. Variante ist beim Client nur der WS-Dienst beteiligt. Bei der anderen Variante der Server-Dienst. Dei scheint etwas anders zu funktionieren bzw. ist ein Client für die Ausführung von Anwendungen optimert und nicht für Serverfunktionen.

 

Falls Du den Test direkt per UNC gemacht hast, wiederhole den Test mal mit einem Laufwerkamapping.

 

-Zahni

[ipzipzap 10]

Mahlzeit!

 

Also ich habe nun immer noch dieses Problem und komme einfach nicht weiter. Es liegt definitiv nicht am Protokoll, weil es nun auch bei iSCSI auftritt. Mehr als rund 35MB/s lesend(!) bekomme ich einfach nicht hin. Schreiben kann ich mit 100MB/s.

 

****erweise bin ich gerade dabei, unser Backup umzustellen auf Backup2Disk2Tape, und dabei kann ich das Problem nicht wirklich gebrauchen. Das Backup2Disk geht aufs externe NAS recht schnell, aber das darauffolgende 2Tape braucht verständlicherweise mit 35MB/s eine Ewigkeit, vom Bandverschleiß wegen des spulens mal ganz abgesehen.

 

Bin da langsam mit meinem Latein am Ende und weiß einfach nicht mehr, was es noch sein könnte. Irgendjemand noch eine Idee?

[zahni 521]

Existieren unterschiedliche LAN-Geschindigkeiten im Netz, also 100 mbit und 1 Gbit gemischt ?

 

Funktioniert vom Client um Server "ping server -l 65500" ?

 

-Zahni

[ipzipzap 10]

Existieren unterschiedliche LAN-Geschindigkeiten im Netz, also 100 mbit und 1 Gbit gemischt ?

 

Ja, aber nicht in dem Abschnitt, d.h. Server und NAS hängen beide am selben Gigabit-Switch.

 

Funktioniert vom Client um Server "ping server -l 65500" ?

 

Nein, kann es auch nicht, da Jumbo-Frames ausgeschaltet sind.

 

Habe eben mal eine Broadcom NIC in den Server gebaut, um einen Defekt oder ein grundsätzliches Treiber-Problem der onBoard Intel-NIC auszuschließen. Und auch bei der Broadcom habe ich schreibend auf das NAS rund 85-90MB/s, lesend aber nur knappe 35MB/s :-(

 

Also mal zusammenfassend:

 

- An der Hardware kann es nicht liegen, da NetIO Lowlevel in beide Richtungen über 100MB/s macht.

- Am NIC-Treiber kann es nicht liegen, da das Problem auch bei unterschiedlichen Herstellern und verschiedenen Treiberversionen auftritt.

- Am verwendeten Protokoll kann es nicht liegen, da es z.b. bei SMB, iSCSI und FTP gleichermaßen auftritt.

 

Also was liegt sonst noch dazwischen?

 

 

Gruß,

Dino