killtec
Goto Top

Hohe Last auf Fileserver (Plattenlast)

Hallo zusammen.
Wir haben folgendes Problem: Auf unserem Fileserver werden ab und an mal große Dateien auf die Platte kopiert. Dabei ist dann die Platte des Servers auf 100% Aktivität und die Last ist dementsprechend hoch.
Die Frage ist, wie kann man das etwas eingrenzen?

Bei dem System handelt es sich um folgende Config:
Windows 2008 R2 auf einem VMware ESXi 5.x Cluster aus 3 Hosts und einer gemeinsamen Storage das per 8Gbit/s FC redundant angeschlossen ist. (Alles Fujitsu).
In dem Server hängen folgende Platten:
80GB (System)
50GB (TS-Profiles)
2TB (Daten)
20GB (Antivirus)

Der Server arbeitet als Fileserver und Antivirusserver (Hier ist die Verwaltung der AV SW installiert).

Die Anbindung erfolgt über jeweils 1Gbit/s (direkt zugewiesener LAN-Anschluss.

Gruß

Content-ID: 223225

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

Ausgedruckt am: 20.11.2024 um 01:11 Uhr

SlainteMhath
SlainteMhath 29.11.2013 um 11:06:22 Uhr
Goto Top
Moin,

Die Frage ist, wie kann man das etwas eingrenzen?
Mittels dem Resource Monitor?

Ausschlaggebend ist was "unter" der VM für ein Plattensystem hängt und wie viele VMs darauf rumrödeln.
Aktuellste Patches Win, ESXi und VMWare Tools sind installiert nehme ich an?
Den Virenscanner kannst Du als Übeltäter ausschliessen?
Diskresourcen wurden vServer seitig auch nicht beschränkt für die VM?

lg,
Slainte
Marco-83
Marco-83 29.11.2013 um 11:12:20 Uhr
Goto Top
Moin,

an welcher Stelle Stellst du denn die hohe Auslastung fest? In der VM oder auf dem Host?
killtec
killtec 29.11.2013 um 12:50:23 Uhr
Goto Top
Hi @SlainteMhath:
Nachgeschaut amRes. Monitor. Patches sind aktuell, VMware Tools auch. Virenscannerk ann ich ausschließen, da dort nur die Verwaltung und die Signaturen drauf sind.
Eine Ressourcenbeschränkung gibt es nicht. Es laufen 23VM's auf dem System, wovon einige aber meißt im idle sind.

@--Marco-- In der VM stelle ich das fest. Währenddessem ist auch direkt auf der VM der Zugriff langsam.

Gruß
SlainteMhath
SlainteMhath 29.11.2013 um 13:08:07 Uhr
Goto Top
`Nachgeschaut amRes. Monitor
Und? Welcher Prozess verursacht die Last?

nur die Verwaltung und die Signaturen drauf sind
Kein Virenscanner der das Filesystem überwacht? Am Fileserver? Mutig face-smile
killtec
killtec 29.11.2013 um 13:13:19 Uhr
Goto Top
Hi Slainte,
ähm ja, Virenscanner ist natürlich auch auf dem System vorhanden face-smile Hab das durch den Admin des Virenscanners unterschlagen.
Der Prozess ist "system" und die Datei wird von einem Kollegen auf den Server kopiert, welches ich anhand der geöffneten Dateien sehen kann.
Cthluhu
Cthluhu 29.11.2013 um 16:00:24 Uhr
Goto Top
Hi,

Wenn große Dateien kopiert werden würde ich eigentlich wollen, dass 100% Aktivität ist. Das sagt mir, dass die Platten so schnell kopieren wie sie können.
Also: 100% Aktivität bei welchen Durchsatz (Bandbreite und IOPS)?
Ist der Schreibcache auch eingeschaltet?

mfg

Cthluhu
killtec
killtec 02.12.2013 um 09:24:27 Uhr
Goto Top
Hi @Cthluhu,
ja, 100% Aktivität ist ok. Den Durchsatz habe ich aktuell nicht im Kopf, kann ich erst testen wenn wir alle wichtigen Sachen erledigt haben.
Die Storage ist per 8Gbit/s FC angebunden und der Server selbst per Gbit. Die IOPS weiß ich nicht genau. Schreibcace, wo kann ich das nachsehen?
Hatte bsiher noch nicht damit zu tun face-sad

Gruß
killtec
killtec 09.12.2013 aktualisiert um 10:33:59 Uhr
Goto Top
Hi,
so habe jetzt mal parallel bei einem Testkopiervorgang (Eine Datei mit 116GB) auf die Storage geschaut.
Zu kopierende Datei: 116GB soll über GBit 2Stunden und 25 Minuten dauern. (Vergleich: Die selbe Datei + weite ca. 15 GB kopire ich normal in 35 Minuten über die selben Switche).
Der Fileserver sagt max. Plattenaktivität, Jedoch 4MB/s Datenträger E/A.
Die Storage sagt mir 19MB/s Read Throuput 1MB/s Write throuput mit 1404IPOS Read und 103IOPS Write

Bei einem zweiten Test (selbe Datei) sollte der Kopiervorgang 30 Minuten dauern. (was ja ok wäre)
Hier waren dann die Plattenlasten im Durchschnitt bei 60% (14 HDD's, HOT-Spare ausgenommen), Die IPOS Read waren bei 1480 und Write bei 164 mit Read 23MB/s und Write 8MB/s.
Der V-Server war aber dann soweit ausgelastet, dass das Anzeigen der Verzeichnisse extrem langsam ist.
Auf dem Server war 100% Datentr. Aktivität und keine 10MB/s E/A

Finde das da etwas komisch läuft... Ich weiß momentan nicht wie ich das eingrenzen kann. face-sad

EDIT: Weiß ja nicht ob die INfo wichtig ist, aber die Platte auf die geschrieben werden soll ist eine 1,8 TB HDD auf der Storage. Das ganze ist im sog. Thick-Provision Lazy-Zeroed angelegt und wurde bereits vergrößert.
Das Volume (LUN) worauf die Daten sind ist 3,12TB groß und belegt sind 3,02TB
Cthluhu
Cthluhu 09.12.2013 um 10:33:56 Uhr
Goto Top
Zitat von @killtec:
Schreibcace, wo kann ich das nachsehen?
Das Storage von Fujitsu hat ja ein Webinterface. Da gibts vermutlich die passenden Einstellungen zum Caching.
Cthluhu
Cthluhu 09.12.2013 um 10:36:44 Uhr
Goto Top
Zitat von @killtec:
Der Fileserver sagt max. Plattenaktivität, Jedoch 4MB/s Datenträger E/A.
Die Storage sagt mir 19MB/s Read Throuput 1MB/s Write throuput mit 1404IPOS Read und 103IOPS Write
Die Werte sind doch etwas niedrig.
Finde das da etwas komisch läuft... Ich weiß momentan nicht wie ich das eingrenzen kann. face-sad
Wie sieht die Performance auf einem anderen LUN aus?
Wie sieht die Performance aus, wenn du auf die LUN über was anderes als den Fileserver zugreifst?
killtec
killtec 09.12.2013 aktualisiert um 10:54:56 Uhr
Goto Top
Hi,
also die Plattenlast ist zumindest deutlich höher (100%) für ca. 14GB will er 4 Minuten haben. Der Fileserver wird dabei nicht beeinträchtigt. Muss also irgendwie am Fileserver liegen.
Das Volume wo der FS drauf liegt wurde übrignes zwei mal vergößert. K.A. ob es daran liegt. (Vermutung: Fragmentierte Platte auf der Storage).
Der Cache steht übrigens auf Write-Back Mode, steht zumindest auf der Startseite der Storage. Habe die Einstellung selbst noch nicht gesehen.

Edit: Was ich auch schon bei der VM gemacht habe, ist die Festplattenanteile der betreffenden HDD von 1000 auf 2000 gesetzt. Sprich, das ist der Wert lt. VMWare "Hoch". Leider ohne Erfolg.