Jump to content

Windows 2008 R2 Dateiserver Geschwindigkeitsprobleme mit filebasierten Datenbanken


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Guten Tag erst einmal,

 

zuerst einmal ein wenig Input: Wir haben einen Server ausgetauscht und somit haben wir nun statt einem Windows 2000 ein Windows 2008 R2 Serverbetriebsystem im Einsatz. Die Maschine fungiert als DC, DNS (logisch) und Fileserver mit DFS (welcher aber nur für Administrative Aufgaben verwendet wird). Auf dem Server liegen Nutzdaten, Speicherdateien für ein selbstgeschriebenes Buchhaltungstool und die Serverversion eines Programms mit der dazugehörigen Paradox-"Datenbank" (wir nennen es mal so obwohl für mich filebasierte Systeme keine Datenbank sind). So viel zur Nutzung un dem Umfeld. Achja, an den Clients ist der Server als einziger DNS eingetragen. Der DNS hat alle nötigen Stammverweise und keine Weiterleitung aktiv, also laut Handbuch installiert. Die Aussage der User, dass auch das Internet langsamer geworden wäre irretierte mich daher Anfangs, kann aber nur hiermit zu tun haben.

 

Nun zu den Problemen:

 

Die Programme laufen langsam. Ich rede hier vom Faktor x4 beim Buchhaltungstool (zur Erklärung: Das Programm erstellt auf Grundlage von Buchungsdaten Suchtabellen und nutzt Diese, Dies dauert in etwa 4 x so lange wie unter Verwendung der Win2K-Maschine, die Suche ist etwa auch 4 x länger), bei der Paradox-Software kann man es schlecht beziffern. Aber mindestens Faktor 2. Kopieren von Daten geht imho normal schnell. Das ist das Interessante! Wenn man nun die Auslastung der Maschine beobachtet erkennt man dass die CPU- und Speicherauslastung lächerlich sind. Die Maschine idlet quasi herum, weil sie mit den Rollen faktisch nicht ausgelastet wird. Die Netzwerkauslastung liegt im Tagesgeschäft bei 4-12%, Lastspitzen bis max. 50% habe ich aber auch schon gesehen. aber selten! Nun noch eine besonderheit: Starte ich das Buchhaltungstool (welches laut Ablaufverfolgung halt die Dateien die es nutzt von vorn bis hinten einliest und den Suchindex in Dateien pro Jahr schreibt) geht die Netzwerkauslastung exakt auf 12,5% hoch, verweilt dort so lange bis das Programm fertig ist und zack -> wieder runter auf das Level des Tagesgeschäfts. Ebenso verhält es sich wenn ich Suchen in der Paradox-DB ausführen lasse. Die Frage ist: was begrenzt hier?

 

Ich habe in der Rollenverwaltung des Servers mal "Diese Rolle prüfen" lassen, beim Dateiserver. Dieser brachte mit diese Meldung:

Titel: Das Erstellen kurzer Dateinamen sollte deaktiviert sein

Schweregrad: Warnung

Datum: 12.11.2010 17:18:33

Kategorie: Konfiguration

Problem: Neben den normalen Dateinamen werden vom Server kurze, aus acht Zeichen bestehende Dateinamen mit einer aus drei Zeichen bestehenden Dateierweiterung (8.3-Dateinamen) für alle Dateien erstellt.

Auswirkung: Durch das Erstellen kurzer Dateinamen zusätzlich zu den normalen, langen Dateinamen kann die Leistung des Dateiservers erheblich beeinträchtigt werden.

Lösung: Deaktivieren Sie das Erstellen kurzer Dateinamen, außer kurze Dateinamen sind für Legacyanwendungen erforderlich. Weitere Informationen zu dieser bewährten Methode und den detaillierten Lösungsverfahren: SMB: Short file name creation should be disabled

 

 

Hat das wirklich Auswirkungen? Die Einstellung muss by Default gekommen sein.

 

Ich hoffe auf Hilfe ;)

 

MfG Maik

Link zu diesem Kommentar

Update:

 

Wir sind weiter am testen woran es liegt. Ich war noch einmal vor ort und habe den alten Server vom Netz genommen und den neuen mit Gigabit versogt. Seitdem ist die Auslastung der LAN-Karte im Tagesbetrieb unter 2%, wenn man es mit einem Client richtig drauf anlegt bei 6-7% (während alle anderen normal arbeiten!).

 

Zusätzliche Erkenntnisse sind:

 

- Kopiere ich Dateien aus Shares oder Netzlaufwerken nach lokal erreiche ich am Client 50-60% Netzwerkauslastung an den 100Mbit-Anschlüssen. Das ist Okay.

- Netzwerk-Benchmark sieht auch normal aus.

- Kopiere ich das Database-Verzeichnis des Paradox-Progrämmchens über LAN vom ursprünglichen Ort mag er die 138Mb in 110 Minuten kopieren

- Kopiere ich das Database-Verzeichnis des Paradox-Progrämmchens auf dem Server zeigt er nicht mal das Kopierfensterchen im VNC an, so schnell ist der fertig.

- Kopiere ich das Database-Verzeichnis des Paradox-Progrämmchens über LAN von irgendeinem anderen Ort mag er die 138Mb in ~40 Sekunden kopieren

- Ebenso verhält es sich mit dem Zugriff auf diese Daten mit den dafür vorgesehenen Programmen: Hier schaffe ich max. die oben erwähnten 12-14% Netzwerkauslastung am Client. Die Rechenleistung limitiert hier nicht, da die Maschinen nur zu ca. 33% maximal ausgelsatet werden bei der Nutzung der Programme.

 

Mir kommt es vor als ob die Probleme vermehrt mit den alten Programmen auftreten würden. das Sage der Buchhaltung hat keine spürbare Verschlechterung. Und es scheint so als ob die Daten irgendwie "gelockt" werden wenn Programme darauf zugreifen. Dieses verhalten ist ja eigentlich normal, jedoch scheint es hier extreme Verzögerungen zu geben wenn alte Tools zugreifen.

 

Ich wäre für Ideen und Anmerkungen wirklich extrem dankbar.

 

MfG Maik

Link zu diesem Kommentar

Auf den Clients läuft der Avira Schutz, auf dem Server ist nur das Management installiert. Dies wird leider vom Team hier sorgegeben. Aber auf den Servern arbeitet nur das IT-Team, daher kann ich noch ruhig schlafen. Wir sollten alle wissen was wir tun.

 

Um deine Frage zu beantworten: Das Deaktivieren des Clientseitigen Schutzes bringt leider keine Verbesserung. Firewall können wir auch ausschließen, Diese sind per GPO deaktiviert an den Clients. Auf dem Server von Hand.

 

MfG Maik

Link zu diesem Kommentar

Wie gesagt haben wir Benchmarks mit Tools durchgeführt und die Dateien kopiert, während sie nicht im Netzwerkzugriff waren. Da ist alles Fine. Die Domäne läuft sauber, auch in den anderen Standorten. Das Problem mit der Geschwindigkeit speziell von der Paradox-basierten Software haben wir auch in den anderen Standorten, nur kommt es da weniger zum Tragen da der Datenbestand einfach viel geringer ist.

 

Den Processexplorer habe ich benutzt um eine Ablaufverfolgung des Buchhaltungs-Tools zu erstellen. Sieht normal aus, nur eben verzögert ausgeführt:

 

- Beim Klick auf "Suchen" fängt er an Dateien aus dem Sage-Verzeichnis eines verbundenen Netzlaufwerks zu laden, den Suchindex auf das Netzlaufwerk zurück zu schreiben, die Datei zu schließen. Das tut er für jedes Jahr bzw. jeden Mandanten den er finden kann. Ohne Fehler, Access denied oder sonstwas. Er benötigt am Client 33% CPU, Speicher sind 1,5 von 2Gb frei, Netzauslastung Clientseitig 17%. Vom Server reden wir lieber nicht, da sieht man kaum Ausschlag. Hab ich ja schon mal weiter oben geschrieben.

 

Die Logs sind sauber. Das Netzwerk läuft übrigens auch sauber, auch wenn es mit 2 Switches kaskadiert ist. Das ist aber durch die Bauliche Situation nötig, und die Kaskadierung ist, wie auch die Anbindung des Servers, mit Gigabit bewerkstelligt. Man kann übrigens im Betrieb der Windows Server-Sicherung, welche des Nächtens auf ein QNAP Nas sichert sehen dass das LAN tatsächlich auch zu höherem fähig ist. Ebeno bei normalen Dateikopieraktionen in beiden Richtungen ( Server<->Client ).

 

Ich würde vermuten dass die Verwaltung des Server2008 IRGENDWIE Mist baut wenn Programme auf die Dateibasierten Datenbanken zugreifen. In dem Fall scheint eine Art Locking oder Limitierung für den Zugriff über das Netzwerk zu greifen. Noch mal als Vergleich:

 

Kopierzeiten

- Paradox DB-Verzeichnis nachts über LAN -> 25 Sek

- Paradox DB-Verzeichnis tagsüber über LAN -> 110 Min (6600 Sek!!!)

- Paradox DB-Verzeichnis tagsüber Disk2Disk -> 1 Sek

 

Die Sage Verzeichnisse lassen sich normal schnell kopieren, das Sage arbeitet normal schnell, das Buchhaltungs-Suchindexprogramm um den Faktor >3 verzögert. Was es genau macht steht ja oben.

 

Wir merken: Der Teufel ist eingegrenzt, aber er zeigt sich nicht offensichtlich. :confused:

 

MfG Maik

 

BtW: Danke für die Resonanz. Der Beitrag steht noch in einem anderen IT-Forum, die Resonanz ist = 0. Hier hab ich nach ein Paar Stunden mehr Antworten als dort nach ner Woche..... Danke dass ihr euch mit mir Gedanken macht ;)

Link zu diesem Kommentar

Ich habe mal mein Ohr ans Netzwerkkabel gehalten als beim Buchhaltungstool der Suchindex erstellt wurde. Das Ganze sieht so aus dass der alle zu lesenden Dateien unendlich oft aufmacht und sich immer nur 320 Byte übertragen lässt. Das erscheint mir etwas lütt in Anbetracht der Tatsache dass die Dateien wesentlich größer sind und ich eine MTU von 1492 im Kopf habe nach der er erst splitten sollte. Habe ich hier einen Denkfehler?

 

MfG Maik

Link zu diesem Kommentar

Von Wo nach Wo werden die Dateien kopiert ? Also dei Richtung.

Haben alle Geräte im LAN die gleiche LAN-Geschindigkeit ?

 

Allgemeine Hinweise in diesem Fall: faq-o-matic.net Gut gedacht, schlecht gemacht, hin & her: Scalable Networking Pack

 

Und SMB Signing mal deaktivieren:

 

Gruppenrichtlinien - Übersicht, FAQ und Tutorials

 

Weiterhin: Prüfen, ob auf allen Gigabit-NIC's Flow Control akiviert ist (erkennen & reagieren).

 

-Zahni

Link zu diesem Kommentar

beim kopieren ist die richtung egal, geht beides schnell wie es soll. beim query der daten über das programm zieht er sich die daten nach lokal, durchsucht, schreibt das ergebnis zurück und zieht den nächsten teil der datei. leider nur 320byte-weise. das scaleable window-dingens ist deaktiviert, smb-signing per gpo unterbunden. bzw. hat das mein kollege so weit zurückgestellt wie es empfohlen wird. ganz aus machen soll man es glaube ich nicht. diese ansätze haben wir schon versucht. flow-control am server ist an, ebenso wie die fehlerkontrolle über den nic selbst. das führt allerdings dazu dass die checksum nicht mehr vom windows geprüft werden kann, was im wireshark mit "checksum 0 should be xxxx" angemarkert wird. sollte aber nichts machen.

 

hast du sonst noch ideen?

 

mfg maik

 

p.s.: entschuldige die nicht-beachtung von groß- und klein, ich sitz hier mit dem feierabendbier und hatte ztu so später stunde nicht mehr den elan ;)

prost!

Link zu diesem Kommentar

- Die Checksum-Geschichte bei Wireshark kannst Du ignorieren. Der aktuelle Netmon von MS sollte damit zurecht kommen.

 

Zu Paradox: Pradox ist leider leicht verstaubt und ich kann mich irgendwie nicht mehr daran erinnern, wie das genau funktioniert. Beachte aber bitte, dass die Software eine 32-Bit Software ist, die vermutlich nicht unter Windows 2008R2 getestet wurde. Es kann durchaus eine der Anwendungen sein, die nicht korrekt funktionieren.

 

-Zahni

Link zu diesem Kommentar

nach meinem dafürhalten sollte dies gar nichts weiter machen, da vom prinzip her nur dateioperationen laufen, oder? mal ab davon dass das phänomen ja auch mit den sage-dateien auftritt, jedoch nicht mit der sage-eigenen software. und warum kann ich die dateien nur so langsam kopieren während sie im zugriff sind? diese sachen sind mir ein rätzel...

 

mfg maik

Link zu diesem Kommentar

Jungs, jetzt kommt der Hammer! :cool:

 

Mit Windows7-Clients lüppt das Ganze wunderbar. Und auch bei XP gibt es Unterschiede, bei gleicher Hardware. Manch einer braucht im Paradox-Programm 10 Sekunden für eine Lade-Operation, ein anderer 20! Wir setzen heute mal einen XPSP1 ohne Updates auf und schauen noch einmal. OPLocks sind nach wie vor aus, SMB-Signing ist an, falls der Gegenpart Dies unterstützt. Da hatte ich meinen Kollegen falsch verstanden. Wir testen heute noch einmal weiter was passiert wenn man es ausschaltet (was imho nicht die Lösung sein darf!).

 

MfG Maik

 

P.S.: Eine Umstellung aller Clients auf Win7 wird definitiv auch nicht die lösung werden, bei insgesamt 300 Rechnern im Unternehmen. Die 12 Server umzustellen ist erst einmal genug Arbeit und Geld was da investiert wird...;)

 

Edit: Und noch ein lustiges Phänomen: In der Testumgebung haben wir alles an Optionen was die HP Netzwerkkarte des Servers hergab verstellt. Unter anderem auch den Linkspeed und Duplex. Die XP-Maschinen mit neuestem updatestand arbeiten am schnellsten mit dem Programm wenn man den Link des Servers auf 100Mbit Half Duplex stellt. Ich hasse so paradoxe Phänomene. Die wissen schon warum die Datenbank so heißt :D:D:D

Link zu diesem Kommentar

So, liebe Gemeinde,

 

wir sind Nach wie Vor nicht weiter. Aktueller Stand unserer Tests:

 

- Oplocks müssen aus sein, da Diese Probleme mit den DB`s verursachen können

- SMB-Signing deaktivieren und testweises Abschalten von SMBv2 brachte keine Besserung.

- auch die Umstellung auf NTLMv1-Authentifizierung brachte keine Besserung

- Experimente mit Chimney-Offload , NetDMA und RSS brachten leider nichts

 

Was man sagen kann:

 

Win2k8 64bit mit WinXP -> langsam

WinXP und WinXP -> normale Geschwindigkeit

Win2k8 und Win7 -> normale Geschwindigkeit

QNAP NAS und WinXP -> langsam

 

Wo kann man noch ansetzen? Die Übertragung sieht im WireShark genau gleich aus, dennoch gibt es massive Geschwindigkeitsunterschiede....

Link zu diesem Kommentar

Ich darf leider keine Internas nennen an der Stelle. Ich kann nur sagen dass es eine hornst-alte Software eines Renomierten Herstellers ist, welcher hier aber keinen Support mehr leistet. "Kaufen sie die Online-Variante" heißt es da an der Hotline. Das Problem ist dass wir von dem oben genannten Programm so schnell nicht weg kommen werden, da sehr viele selbst geschriebene Tools darauf zugreifen, und die alle anzupassen würde unsere Programmierer doch etwas über gebühr lange beschäftigen. Das Problem bezieht sich ja nicht nur auf das Paradox-Programm. Wir haben ja noch die Buchhaltungssoftware, die in die Sage-Dateien rein greift. Diese ist auch wesentlich langsamer. Fakt ist eins:

 

Beim Zugriff von Programmen, welche auf dem Server abgelegte Dateibasierte Datenbanken sequentiell in kleinen "Häppchen" lesen ist ein Signifikanter Geschwindigkeitseinbruch festzustellen. Und Dies liegt definitiv am Server 2008 ivm Windows XP-Clients. Dafür muss es eine Lösung geben. Ich gebe zu: Wir haben durch die Netzwerktraffic-Beobachtung gesehen dass auch in der Paradox-Software selbst etwas "unglücklich" auf Daten zugegriffen wird (die Daten werden halt immer in sehr kleinen Stücken gelesen), Dies ist jedoch reproduzierbar schon immer so gewesen. Daher kann ein Geschwindigkeitsunterschied vom Faktor 2-4 nicht kommen!

 

Meine Vermutung ist dass die früheren Windows-Versionen einfach mit kleineren Paketgrößen wesentlich besser umgehen konnten. Aber so was MUSS konfigurierbar sein....

 

MfG Maik

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...