ESXi 5.1.0 Performance

[crepa]

Hallo zusammen

Die Kopiervorgänge auf meinem Server sind unterschiedlich langsam. Auch die Kopiervorgänge von/zu meinem NAS sind teilweise sehr mühsam. Mein Server sieht wie folgt aus:
ProLiant ML350 G6, CPU-Kerne: 4 CPUs x 2.399 GHz, Xeon E5620 @ 2.40 GHz
1 Prozessor-Sockets, 4 Kerne pro Socket, 8 Logische Prozessoren
2 Netzwerkkarten
vMotion: nicht verfügbar, EVC-Modus: deaktiviert, vSphere HA-Status: nicht verfügbar

Darauf ist ESXi, 5.1.0, 1065491 mit 24 GB RAM
Server 1: Windows Small Business Server 2011, 64-Bit, 4 vCPU, 8 GB RAM, 2 virt Sockets mit 2 Kerne pro Socket, VMXNET3 Adapter
Server 2: Windows Server 2012, 64-Bit, 4 CPU, 8 GB RAM, 2 virt. Sockets mit 2 Kerne pro Socket, VMXNET3-Adapter
Im weiteren sind 8 viruelle PC's installiert mit je 2 GB RAM. Von denen laufen jedoch in der Regel nur immer 1 bis 4 Maschinen gleichzeitig.

Wenn ich 1 Datei von 1 GB Grösse umkopiere erhalte ich folgende Werte:
via WinExplorer auf Srv01:
von Srv01 zu Srv03: 10 Sekunden = 102.40 MB/s
von Srv03 zu Srv01: 3 Sekunden = 341.33 MB/s
via WinExplorer auf Srv03:
von Srv01 zu Srv03: 15 Sekunden = 68.27 MB/s
von Srv03 zu Srv01: 15 Sekunden = 68.27 MB/s
via WinExplorer auf PC:
von Srv01 zu Srv03: 20 Sekunden = 51.20 MB/s
von Srv03 zu Srv01: 22 Sekunden = 46.55 MB/s

Wo muss ich die Konfiguration anpassen, damit ich bei allen Kopiervorgängen schnellere und gleichmässigere Werte erhalte.

Ich danke Euch für Eure Hilfe.
Gruss
Franz

[~thc]

Gegenfrage: Gibt es einen besonderen Grund, mit dem ESXi-Patchlevel 2,5 Jahre zurück zuhängen?

Essentielle Infos fehlen: Worauf liegen die virtuellen Festplatten der VMs (DAS,SAN,NAS)?

[Supi]

Essentielle Infos fehlen: Worauf liegen die virtuellen Festplatten der VMs (DAS,SAN,NAS)?

Mal von dem over provisioning der vcpu abgesehen.
Was macht der Server 2012, dass der 4 vcpu braucht?
Wieviele CPU's haben den diese virtuellen PC's ? Mehr Ram zu verbauen wird bestimmt auch nicht schaden.

Edit: Der Patch-Level ist übrigens fast 3,5 Jahre her. Stammt aus 04/2013.

[crepa]

Hallo und danke für Eure Hilfe

Ein Ex-Kollege hat mir die Kiste mal aufgebaut. Da ich kein Profi bin, habe ich nie gepatcht. Sollte das tatsächlich einmal an die Hand nehmen.

Ich habe
4 Disk on HPSA1 à 279 GB, Raid 5
2 Disk on HPSA1 à 931 GB, Raid 1
Wie kann ich das over provisioning korrigieren?
Auf dem Server 2012 laufen 2 SQL Server (1 x 2012 + 1 x 2014). Aktuell kein grosser Traffic.
Wie soll ich die vcpu auf den beiden Servern besser einstellen?
Alle 9 virtuellen PC's haben 1 virt. Socket + 1 Kern pro Socket.

Danke für Eure weitere Hilfe.
Franz

[Supi]

Hallo und danke für Eure Hilfe

Ein Ex-Kollege hat mir die Kiste mal aufgebaut. Da ich kein Profi bin, habe ich nie gepatcht. Sollte das tatsächlich einmal an die Hand nehmen.

Ich habe
4 Disk on HPSA1 à 279 GB, Raid 5
2 Disk on HPSA1 à 931 GB, Raid 1
Wie kann ich das over provisioning korrigieren?
Auf dem Server 2012 laufen 2 SQL Server (1 x 2012 + 1 x 2014). Aktuell kein grosser Traffic.
Wie soll ich die vcpu auf den beiden Servern besser einstellen?
Alle 9 virtuellen PC's haben 1 virt. Socket + 1 Kern pro Socket.

Danke für Eure weitere Hilfe.
Franz

Nun, zum Thema Overprovisioning. Erst mal den SQL Server auf 2 virt. Sockets mit 1 Kern umstellen. Wenn das SQL Server Express Versionen sind, genau anders herum. Der kann nur mit 1 Sockel umgeben.

Als weiteren Test lässt sich das auch beim SBS 2011 machen. Wieviele User hängen da denn dran?

Aber immer eins nach dem anderen Test und den Erfolg/Misserfolg messen.

Thema patchen:
Als erstes sollte man prüfen ob eine funktionierende Datensicherung vorliegt.
Dann ist der einfachste Weg auf dem Server SSH aktivieren und hier mal schauen:
https://esxi-patches.v-front.de/ESXi-5.1.0.html

Wenn du auf einen Patch stand schaust

Cut and paste these commands into an ESXi shell to update your host with this Imageprofile
# See the Help page for more instructions
#
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-5.1.0-20160504001-standard \
-d https://hostupdate.vmware.com/software/ ... -index.xml
esxcli network firewall ruleset set -e false -r httpClient
#
# Reboot to complete the upgrade

vorteil, man muss den patch nicht selber auf den server laden. der ESXI muss am Internetzugriff haben. Dessen Firewall wird oben ein und wieder ausgeschaltet.

bzw hier : https://www.markus-huether.de/mh/index. ... te-manager

Server muss dabei im Wartungsmodus sein. Daher VM's vorher herrunterfahren.

Letzter Tipp:
Die Hardware selbst. der SBS freut sich bestimmt auch über mehr RAM.

http://www.kingston.com/de/memory/searc ... odel=55047

so ein 3x16GB Paket ist mit knapp 300€ überschaubar.

http://www.idealo.de/preisvergleich/Off ... gston.html

[crepa]

Hallo Supi

Die Hardware selbst. der SBS freut sich bestimmt auch über mehr RAM.

Ich möchte im Herbst vom SBS 2011 auf Server 2016 wechseln und dann wird der ProLiant fast 5-jährig sein. Ich werde dann entscheiden müssen, ob ich einen neuen Server mit mehr Power kaufen sollte. Deshalb möchte ich momentan keine Erweiterung vornehmen.

Thema patchen

Das Patchen werde ich demnächst einmal durchführen.

Wieviele User hängen da denn dran?

2 User bzw. 2 PC's mit Win10. Die virtuellen PC's sind für Programmtests mit unterschiedlichen Windows- und Office-Versionen. Es laufen sporadisch 0 bis 3 PC's.

Nun, zum Thema Overprovisioning. Erst mal den SQL Server auf 2 virt. Sockets mit 1 Kern umstellen.

Ich habe folgende Schritte durchgeführt:
Srv03: Sockets/Kerne umgestellt von 2/2 auf 2/1, Total 2 Kerne
Srv01: Sockets/Kerne umgestellt von 4/1 auf 2/1, Total 2 Kerne
virtuelle PC's bleiben auf 1 Kern
RAM-Änderung (total 24):
Srv01 von 8 auf 12 GB
Srv03 von 8 auf 6 GB
PC's bleiben je auf 2 GB

Während den Tests liefen die beiden virtuellen Server und die beiden PC's mit wenig eigenem Traffic. Von den 9 virtuellen PC's war keiner eingeschaltet.

Nach jedem Schritt habe ich mehrmals 1 Datei à 1 GB mit dem WinExplorer umkopiert und zwar wie folgt:
RDP Srv01: Kopieren von Srv01 auf Srv03: ca. 12 Sekunden
RDP Srv01: Kopieren von Srv03 auf Srv01: ca. 4 Sekunden
RDP Srv03: Kopieren von Srv01 auf Srv03: ca. 18 Sekunden
RDP Srv03: Kopieren auf Srv03 auf Srv01: ca. 12 Sekunden
Zudem habe ich noch verschiedene QNAP-Backup-Programme laufen gelassen (NAS to NAS, rsync, RTRR).

Die Zeiten blieben - unabhängig von den Umstellungen - immer ziemlich gleich wie in meiner 1. Nachricht erwähnt. Was mich aber wundert, sind die weiterhin unterschiedlichen Zeiten von zwischen 4 und 18 Sekunden, je nachdem von welchem RDP und in welche Richtung in kopiert habe.

Gibt es da noch Erkenntnisse für weitere Optimierungen? Soll ich die Kerne jetzt so lassen wie sie sind? Waren die RAM-Umstellungen sinnvoll und hilfreich und soll ich diese jetzt auch so belassen?

Danke Euch
Franz

[~thc]

Entscheidend für die Schreibleistung sind die Leistungsdaten der RAID-Controller. Wenn diese über kaum eigenes RAM oder kein Write-Back (wegen fehlender BBU oder fehlendem RAM) verfügen, macht das Bewegen großer Datenmengen keinen Spaß.

ESXi wirft die Daten einfach der Hardware vor die Füße - ESXi hat im Gegensatz zu anderen OS keine eigene Puffer-Strategie - das muss alles die Hardware erledigen.

Mit HP SmartArrays kennen sich andere hier im Forum besser aus.

[Supi]

Hallo Franz,

ich versuche mal kurz zusammenzufassen.

SRV03 wird der 2012er Server sein, richtig?

Daten die dieser Server sendet ( oder wenn du von dort kopierst) geht am schnellsten.

Was jedoch fehlt ist die Info, auf welchem Raid die jeweiligen Testlaufwerke der Server liegen.

Kopierst von z.B. von LW_D des SRV03, das auf dem Raid 1 liegt, ist hier die Schreibrate ggf. besser als auf dem Raid-5. Kann aber auch anders rum sein.

Was will ich sagen, die Laufwerke für den Test sollten auf dem gleichen Raid liegen.

Auf die schnelle habe ich dieses Tool gefunden, was einfacher zum Testen wäre:
http://totusoft.com/lanspeed1/
hier mal mit 5000 MB testen. 1x lokal und dann auf der Freigabe des anderen Servers. Die Werte dann hier mal posten

...Aber ganz ehrlich, wenn du im Herbst eh wechseln willst, wieso dann hier noch rumdoktern?
Da könnte ich mir sinnvollere Sachen vorstellen. Lass es wie es ist und plane lieber den neuen Server. Das können wir gerne hier in einem neuen Thread diskutieren.

[crepa]

Hallo Stefan

Hier die weiteren Angaben mit dem aktuellen Stand:
Srv01: Windows SBS 2011 Standard, 64-Bit, 12 GB RAM, 2 Prozessoren
Srv03: Windows Server 2012 R2 Standard, 64-Bit, 6 GB RAM, 2 Prozessoren

Beide Server liegen auf dem Raid 5

Die Testresultate mit dem LAN Speed Test zeigen folgendes Bild für 5000 MB:
Von Srv01 zu Srv03: Writing: 1,558.4555520 Mbps, Reading: 1,575.1378240 Mbps
Von Srv03 zu Srv01: Writing:617.9953040 Mbps, Reading: 490.0985920 Mbps
Von PC (Win 10, 64-Bit) zu Srv01: Writing: 263.4782160 Mbps, Reading: 427.9330560Mbps
Von PC zu Srv03: Writing: 722.5556640 Mbps, Reading: Mbps 776.4024320

Man sieht auch hier die deutlichen Unterschiede, die für mich nicht erklärbar sind.

Der Entscheid zum Serverwechsel ist noch nicht definitiv und zudem möchte ich die Gründe kennen, damit ich das Problem mit dem neuen Server nicht haben werde.

Gruss
Franz

[Supi]

@ Franz: Jetzt mal nur aus dem Bauch heraus, ggf SMB 2.0 bei dem SBS 2011 deaktiviert?

http://www.edist.net/microsoft/server/w ... ieren.html
http://www.windowspage.de/tipps/021217.html

hier steht zwar wie es deaktiviert wird, aber kann man ja auch fürs aktivieren nutzen.

SMB 2.0 ist schon deutlich schneller als SMB 1 vor Vista. Und der Server 2011 SBS entspricht ja Server2008/Vista.

https://www.administrator.de/frage/serv ... 58882.html
hier hatte es einer wegen Sage Classic Line deaktiviert.

[crepa]

Hallo Stefan

In der Registry von Srv01 (Win2011 SBS) steht
mrxsmb / Start = 3
mrxsmb10 / Start = 3
mrxsmb20 / Start = 3

In der Registry von Srv 03 (Win2012 R2) steht
mrxsmb / Start = 3
mrxsmb10 / Start = 2
mrxsmb20 / Start = 3

Mir ist nicht bekannt, was das genau bedeutet, aber ich habe in meinem Netzwerk von WinXP (Testmaschine für alte Software) bis Win10 alles im Einsatz und eine allfällige Umstellung der SMB-Konfig darf nicht zu Störungen führen.

Gruss
Franz

[Supi]

Also ich kann da jetzt auch nicht mehr weiterhelfen. Denke aber nicht, dass es ein VMWARE Problem ist. Offene Snapshots gibts bei dem SBS2011 hoffentlich nicht.

[crepa]

Hallo Stefan

Auch wenn wir das Rätsel nicht lösen können, so danke ich Dir für Deine Hilfe. Offene Snapshots gibt es nicht. Ich werde mich nun wohl auf die Planung des neuen Servers konzentrieren.

Gruss
René

[kastlr]

Hallo zusammen,

hier wird ja ständig die Netzwerkperformance beim Kopieren der Daten gemessen, aber was ist mit der jeweiligen Diskperformance?

Wie viele VMFS Datastores sind denn hier beteiligt, und wie sind die aus dem RAID Verbund gebildet worden?
Je nachdem mit welchem Workload du auf deinen beiden RAIDs arbeitest könnten die Unterschiede auch aus der Ecke kommen.

Allerdings laufen die von dir verwendeten Meßverfahren nicht lange genug, um daraus Erkenntnisse gewinnen zu können.

Sofern möglich, kopiere mal 20-50 GB hin und her und schau dabei mal unter esxtop nach, was die Platten so liefern.

Gruß,
Ralf

[crepa]

Hallo Curt

Ich habe 2 Datastores
Datastore 1: Raid 5 mit 4 Festplatten
Datastore 2: Raid 1 mit 2 Festplatten

Im Datastore 1 sind beide Server
Im Datastore 2 sind 9 virtuelle PC + WSUS

Somit haben beide Kopiervorgänge die gleiche Ausgangslage für die Performance. Es scheint mir deshalb fraglich, ob weitere Tests mit grossen Datenmengen und esxtop zum Ziel führen können.

Gruss
Franz

[kastlr]

Hallo Franz,

prinzipiell muß ich dir da zustimmen, allerdings variiert die Performance einer Platte auch von der angesprochenen Diskregion.
Weiterhin würde es mich nicht wundern, wenn Quell und Ziel Windows unterschiedliche IO Größen für Read & Write IO's verwenden würden.

Zumindest habe ich bei ähnlichen Test schon festgestellt, das auf der Quell VM mit 1MB Read IO's gearbeitet wurde, während die Ziel VM 16 /32/64 KB Write IO's verwendet hat.

Daher könnte es sein, das beim Einsatz kleiner Read & Write IO's die HBA Queue kurzfristig volläuft.
Oder die IO's werden je nach OS Version sequentiell oder parallel erzeugt.
Windows SBS 2011 ist aus dem Jahr 2010, sollte somit zumindest in Teilen auf W2K8 basieren.
W2K12 ist von Ende 2012 und verwendet nach meiner Erfahrung bei Copy Jobs andere IO Block Größen.

Ob das allerdings ausreicht, um solche Unterschiede in der Performance zu produzieren kann ich dir nicht sagen.
Aber mit estop könntest du das relativ schnell verifizieren.

Schönes Wochenende,
Ralf

[UrsDerBär]

Gibt da noch eine wahrscheinliche Variante. Pufferung durch das OS. Sei es Read oder Write.

Bei so wenig Platen ist es für mich schon die tiefe Schreibleistung verwunderlich. Meines erachtens puffert Windows kräftig mit. Das neuere Windows eben noch mehr. Versuche es mal mit wesentlich grösseren Daten, damit sämtlich Write-Buffer geflutet werden. Ich behaupte, die Werte werden sich dann etwas annähern auch wenn die neuen OS tendenziell etwas besser sein dürften.

Auch kann man Windows sagen, es soll die Commits nicht abwarten sondern einfach weiter Daten schicken. Das geht auch massiv auf die Performance, gerade dann, wenn die Disk-System Puffer voll sind.
Das habe ich gerade bei eher schmalbrüstigen Server mit wenig Disk-Leistung schon oft gesehen auch wenn es meines Erachtens fahrlässig ist.

Dann ist es noch so, dass ein SBS den vollständigen RAM belegt sofern man nicht einzelne Dienste selbständig etwas begrenzt. Das könnte dann auf den Write-Cache gehen. Also dreh mal Exchange, ein allfälliger SQL/interne Windows DB sowie die bescheuerte Wartungsoberfläche etc. ab und machs nochmal.

[Dayworker]

SBS2k11 hat wegen seiner Abstammung von Win2k8 dessen schwachsinnige Arbeitsspeicherverwaltung geerbt. Letztendlich wachsen die Caches immer weiter an, bis sie den gesamten vorhandenen RAM belegen. Kommt dann eine Anwendung daher, weigert sich SBS beharrlich seine Caches zu schrumpfen und dadurch etwas RAM freizugeben. Von der Warte muß man alle auf Win2k8 basierenden OS etwas nachhelfen und notgedrungen den RAM-Verbrauch einiger Funktionen einschränken. Als weiteres Schmackerl von Win2k8 kommt dessen idiotische NUMA- bzw Prozessorgruppen-Verwaltung ins Spiel. Den Müll haben sie dankenswerter Weise bei Win2k12 direkt wieder rausgeworfen.

[kastlr]

Hallo,

Auch kann man Windows sagen, es soll die Commits nicht abwarten sondern einfach weiter Daten schicken. Das geht auch massiv auf die Performance, gerade dann, wenn die Disk-System Puffer voll sind.
Das habe ich gerade bei eher schmalbrüstigen Server mit wenig Disk-Leistung schon oft gesehen auch wenn es meines Erachtens fahrlässig ist.

Das mußt du näher erklären.

Solange wie ein IO an den Adapter übergeben und vom Device/Array noch nicht beantwortet ist belegt er einen Queue Slot auf dem HBA/Adapter.
Je nach HBA/Adapter/Treiber kann das System nur x IO Requests an die Hardware übergeben, der Rest muß dann im Layer oberhalb des HBA/Adapter Treibers so lange warten, bis der Treiber wieder einen neuen IO annimmt.

Das einzige was man meines Wissens nach beeinflussen kann (über den HBA/Adapter Treiber) ist die Anzahl der Queue Slots.

Wie sagt man Windows denn, dass es nicht auf einen Commit (bei Write) oder auf die angeforderten Daten (bei Reads) warten soll?
Meiner Meinung nach kann das gar nicht gehen, denn wie soll eine Applikation wie z. B. eine Datenbank ohne die angeforderten Daten oder ohne die Schreibbestätigung (z. B. Transaction Logs) sicher weiter arbeiten können?

Gruß,
Ralf

[UrsDerBär]

Falsch formuliert.
Im Grunde läufts auf den OS-Disk-Cache bzw. allgemein die Nutzung von Cache der Festplatte/OS hinaus den man unter Polices bei ner Festplatte einstellen kann (Explorer>Rechte Maustaste>Eigenschaften>Register Policies/Richtlinien).

Wird da alles deaktiviert, scheint Windows nur neue Daten rauszuhauen, wenn der vorhergehende Write tatsächlich komplett durch ist.
--> So ist zumindest meine Interpretation, sonst dürfte das nicht auf das unterirdische Niveau von ca. 3.5MB/Platte sinken bei ner 15k SAS-Platte ohne Controller.

Eine Applikation kann eine Cache-Einstellungen aber überstimmen. Für sowas wie DB-Files und Transaktionslogs und andere kritische Daten. Da wird dann trotz Aktivierung des Caches safe geschrieben. Filecopy voa GUI ist aber normalerweise - sofern nicht epxlizit angegeben und nicht deaktiviert immer unter Nutzung des Caches.