Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Performance Messung Storage
Performance Messung Storage
Hi,
ich steh aktuell vor dem Problem das ein Auswertungs-Tool viel zu lange braucht für eine Ausführung im Vergleich Windows 7 VM zu Notebook.
Es handelt sich um einen Trace Test, bei dem verschiedene Softwarestände verglichen werden und die Ergebnisse dann weggeschrieben werden. niedrige Lese aber hoher Schreibe Last wird erzeugt.
Die auszuwertenden Daten liegen alle Lokal auf der Platte und die Ergebnisse landen auch wieder auf der Platte
Nach einem Gespräch mit "irix" und einer kleinen Forensuche scheint es zur großen Wahrscheinlichkeit am Storage zu hängen, also möchte ich die Zugriffszeiten vom Notebook und der LUN vergleichen.
Die 2 Systeme werden verglichen:
Latitude Notebook E6430 mit einem I5-3340M + 840er PRO Samsung SSD, 8 GB RAM
Ausführungsdauer: ca. 33 Sekunden
Windows 7 VM, 2 vCPUs (XEON e5-2620, ohne Reservierung) 4 GB Ram, EQL Storage Cluster (eql 4110 und eql 6110 gemischt)
Ausführungsdauer: ca. 4-7 Minuten (schwankt sehr stark)
Die üblichen Fehlerquellen konnte ich bisher ausschließen, den egal ob ich einen ESXi Host komplett leer Räume und nur eine VM drauf laufen lasse, 8 Kerne und 32 GB Ram zuteile, ändert nicht wirklich etwas.
VMware Tools sind aktuell.
Die VM liegt in einer eigenen LUN, und die eine Disk ist per VMware Paravirtuell iSCSI Controller eingebunden.
Also erstmal die Bandbreite getestet:
Test im Idle
time /usr/sbin/vmkfstools -c 10G -d eagerzeroedthick perf_test.vmdk
real 0m 1.59s
user 0m 0.44s
sys 0m 0.00s
Test während der Tool Ausführung:
real 0m 2.11s
user 0m 0.48s
sys 0m 0.00s
Ist das normal das bei dem Test 2 Dateien angelegt werden?„perf_test.vmdk“ und eine „perf_test-flat.vmdk“.
Unterm Strich denke ich hier liegt kein Problem vor.
esxtop
Im Top sieh ich im Write zwischendurch mal einen Ausreißer auf 0,6ms sonst bleibt es bei 0 – 0,1
SANHQ
Mitschnitt der LUN der letzten 20 Ausführungen des Tools
Averange Latency
Reads : 1,59
Writes: <1.0ms,
Weighted Avg: 1,25ms
Jetzt zum eigentlichen Problem bzw meinen Fragen:
1. Generell ist das die richtige Herangehensweise?
2 .Wie bekomme ich das Aussagekräftig auf das Notebook gemapt, der Ressourcenmonitor im Windows ist irgendwie nicht das tolle Mittel um so was zu messen, kann mir wer was empfehlen?
Grüße
ich steh aktuell vor dem Problem das ein Auswertungs-Tool viel zu lange braucht für eine Ausführung im Vergleich Windows 7 VM zu Notebook.
Es handelt sich um einen Trace Test, bei dem verschiedene Softwarestände verglichen werden und die Ergebnisse dann weggeschrieben werden. niedrige Lese aber hoher Schreibe Last wird erzeugt.
Die auszuwertenden Daten liegen alle Lokal auf der Platte und die Ergebnisse landen auch wieder auf der Platte
Nach einem Gespräch mit "irix" und einer kleinen Forensuche scheint es zur großen Wahrscheinlichkeit am Storage zu hängen, also möchte ich die Zugriffszeiten vom Notebook und der LUN vergleichen.
Die 2 Systeme werden verglichen:
Latitude Notebook E6430 mit einem I5-3340M + 840er PRO Samsung SSD, 8 GB RAM
Ausführungsdauer: ca. 33 Sekunden
Windows 7 VM, 2 vCPUs (XEON e5-2620, ohne Reservierung) 4 GB Ram, EQL Storage Cluster (eql 4110 und eql 6110 gemischt)
Ausführungsdauer: ca. 4-7 Minuten (schwankt sehr stark)
Die üblichen Fehlerquellen konnte ich bisher ausschließen, den egal ob ich einen ESXi Host komplett leer Räume und nur eine VM drauf laufen lasse, 8 Kerne und 32 GB Ram zuteile, ändert nicht wirklich etwas.
VMware Tools sind aktuell.
Die VM liegt in einer eigenen LUN, und die eine Disk ist per VMware Paravirtuell iSCSI Controller eingebunden.
Also erstmal die Bandbreite getestet:
Test im Idle
time /usr/sbin/vmkfstools -c 10G -d eagerzeroedthick perf_test.vmdk
real 0m 1.59s
user 0m 0.44s
sys 0m 0.00s
Test während der Tool Ausführung:
real 0m 2.11s
user 0m 0.48s
sys 0m 0.00s
Ist das normal das bei dem Test 2 Dateien angelegt werden?„perf_test.vmdk“ und eine „perf_test-flat.vmdk“.
Unterm Strich denke ich hier liegt kein Problem vor.
esxtop
Im Top sieh ich im Write zwischendurch mal einen Ausreißer auf 0,6ms sonst bleibt es bei 0 – 0,1
SANHQ
Mitschnitt der LUN der letzten 20 Ausführungen des Tools
Averange Latency
Reads : 1,59
Writes: <1.0ms,
Weighted Avg: 1,25ms
Jetzt zum eigentlichen Problem bzw meinen Fragen:
1. Generell ist das die richtige Herangehensweise?
2 .Wie bekomme ich das Aussagekräftig auf das Notebook gemapt, der Ressourcenmonitor im Windows ist irgendwie nicht das tolle Mittel um so was zu messen, kann mir wer was empfehlen?
Grüße
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo zusammen,
du kannst die Ausführung deines Tests auf einem ESXi Server mal mit dem vscsiStats Tool überwachen.
Meine Vermutung ist folgende.
Dein Analyse Tool parallelisiert seine Write IO's nicht, somit wird der folgende IO erst dann ans Array gesendet, wenn der vorangegangene abgearbeitet worden ist.
Und dann ist ein Array natürlich deutlich langsamer als eine lokale SSD.
Allein die Anbindung deiner internen SSD ist ja schon um ein Vielfaches höher als die im SAN verfügbare Bandbreite, welche dann ja auch noch üblicherweise mit vielen anderen geteilt wird.
Für solch ein Scenario bieten sich Flash Karten in den ESXi Servern an.
Gruß,
Ralf
du kannst die Ausführung deines Tests auf einem ESXi Server mal mit dem vscsiStats Tool überwachen.
Meine Vermutung ist folgende.
Dein Analyse Tool parallelisiert seine Write IO's nicht, somit wird der folgende IO erst dann ans Array gesendet, wenn der vorangegangene abgearbeitet worden ist.
Und dann ist ein Array natürlich deutlich langsamer als eine lokale SSD.
Allein die Anbindung deiner internen SSD ist ja schon um ein Vielfaches höher als die im SAN verfügbare Bandbreite, welche dann ja auch noch üblicherweise mit vielen anderen geteilt wird.
Für solch ein Scenario bieten sich Flash Karten in den ESXi Servern an.
Gruß,
Ralf
Für Latenzen:
Histogram: latency of IOs in Microseconds (us) for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : 110
max : 1000978
mean : 4099
count : 359247
0 (<= 1)
0 (<= 10)
0 (<= 100)
39550 (<= 500)
106229 (<= 1000)
112857 (<= 5000)
88735 (<= 15000)
8722 (<= 30000)
1425 (<= 50000)
1254 (<= 100000)
475 (> 100000)
Histogram: latency of Read IOs in Microseconds (us) for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : 110
max : 1000978
mean : 4297
count : 322907
0 (<= 1)
0 (<= 10)
0 (<= 100)
26455 (<= 500)
93891 (<= 1000)
105058 (<= 5000)
86629 (<= 15000)
8123 (<= 30000)
1210 (<= 50000)
1111 (<= 100000)
430 (> 100000)
Histogram: latency of Write IOs in Microseconds (us) for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : 194
max : 339051
mean : 2344
count : 36340
0 (<= 1)
0 (<= 10)
0 (<= 100)
13095 (<= 500)
12338 (<= 1000)
7799 (<= 5000)
2106 (<= 15000)
599 (<= 30000)
215 (<= 50000)
143 (<= 100000)
45 (> 100000)
Histogram: latency of IOs in Microseconds (us) for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : 110
max : 1000978
mean : 4099
count : 359247
0 (<= 1)
0 (<= 10)
0 (<= 100)
39550 (<= 500)
106229 (<= 1000)
112857 (<= 5000)
88735 (<= 15000)
8722 (<= 30000)
1425 (<= 50000)
1254 (<= 100000)
475 (> 100000)
Histogram: latency of Read IOs in Microseconds (us) for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : 110
max : 1000978
mean : 4297
count : 322907
0 (<= 1)
0 (<= 10)
0 (<= 100)
26455 (<= 500)
93891 (<= 1000)
105058 (<= 5000)
86629 (<= 15000)
8123 (<= 30000)
1210 (<= 50000)
1111 (<= 100000)
430 (> 100000)
Histogram: latency of Write IOs in Microseconds (us) for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : 194
max : 339051
mean : 2344
count : 36340
0 (<= 1)
0 (<= 10)
0 (<= 100)
13095 (<= 500)
12338 (<= 1000)
7799 (<= 5000)
2106 (<= 15000)
599 (<= 30000)
215 (<= 50000)
143 (<= 100000)
45 (> 100000)
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Na ja,
ich habe gerade selber keinen vscsiStats Output zur Hand.
Aber ich weiß, dass dort etwas wie outstanding/parallel IO's aufgeführt wird.
Außerdem solltest du dort auch etwas über die IO Size finden, das könnte man dann in einem IO Meter Test verwenden.
Weiterhin wäre es hilfreich zu wissen, ob die IO's random oder sequentiell zur Disk geschickt warden.
Auch dazu gibt es in vscsiStats eine eigene Tabelle.
Dein Analyse Tool verwendet vorwiegend Read IO's, von knapp 360.000 IO's sind 323.000 Read IO's dabei.
Von deinen knapp 360.000 IO's werden 72% in weniger als 5 ms bearbeitet, 28% benötigen mindestens 5ms.
Gruß,
Ralf
ich habe gerade selber keinen vscsiStats Output zur Hand.
Aber ich weiß, dass dort etwas wie outstanding/parallel IO's aufgeführt wird.
Außerdem solltest du dort auch etwas über die IO Size finden, das könnte man dann in einem IO Meter Test verwenden.
Weiterhin wäre es hilfreich zu wissen, ob die IO's random oder sequentiell zur Disk geschickt warden.
Auch dazu gibt es in vscsiStats eine eigene Tabelle.
Dein Analyse Tool verwendet vorwiegend Read IO's, von knapp 360.000 IO's sind 323.000 Read IO's dabei.
Von deinen knapp 360.000 IO's werden 72% in weniger als 5 ms bearbeitet, 28% benötigen mindestens 5ms.
Gruß,
Ralf
@kastlr
Welche Tabelle würde dafür passen:
seekDistance, outstandingIOs, latency oder interarrival
Es gibt zwar ein paar schöne Erklärungen im Web aber das muss man(ich) erstmal verstehen.
Bin da noch ziemlich neu in dem Bereich Performance Analyse.
@joergpc
- 2 EQL in einer GRP (langsame PS41er mit langsamen Platten und PS61er mit schnellen Platten + SSDs)
- Anbindung per iSCSI (10 Gbit)
- Aktuell sind 131 VMs aktiv, jede VM liegt in einer eigenen LUN > 886 von 1024 iSCSI Connections belegt.
edit:
ist das DELL’s Multipath Extension Module eigentlich Plicht?
Grüße
Welche Tabelle würde dafür passen:
seekDistance, outstandingIOs, latency oder interarrival
Es gibt zwar ein paar schöne Erklärungen im Web aber das muss man(ich) erstmal verstehen.
Bin da noch ziemlich neu in dem Bereich Performance Analyse.
@joergpc
- 2 EQL in einer GRP (langsame PS41er mit langsamen Platten und PS61er mit schnellen Platten + SSDs)
- Anbindung per iSCSI (10 Gbit)
- Aktuell sind 131 VMs aktiv, jede VM liegt in einer eigenen LUN > 886 von 1024 iSCSI Connections belegt.
edit:
ist das DELL’s Multipath Extension Module eigentlich Plicht?
Grüße
-
- King of the Hill
- Beiträge: 13043
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
ReedyTT hat geschrieben:- 2 EQL in einer GRP (langsame PS41er mit langsamen Platten und PS61er mit schnellen Platten + SSDs)
Die Frage ob beide im selben Pool sind oder getrennt. Wenn im selben Pool , was etwas unschoen waere, die Frage ob per RAID Preference RAID6 Accel. die Volumes auf besagter EQL liegen.
- Aktuell sind 131 VMs aktiv, jede VM liegt in einer eigenen LUN > 886 von 1024 iSCSI Connections belegt.
Man kann es auch uebertreiben. 131 Datastores? Wieviel Jahre dauert der ESXi Bootvorgang wenn das Storage mal nicht da ist?
Der Managementaufwand fuer 131 Volumes/Datastore steht in keinen Verhaeltnis zum evtl. Performancegewinn. Des weitere ist bei 1024 Schluss und muss man die internen noch Abziehen.
edit:
ist das DELL’s Multipath Extension Module eigentlich Plicht?
Aus meiner Sicht ja.... auf dem Papier kann es Problem gehen was die Lizenzierung von 3rd.Party MPIO Modulen angeht aber in der Vergangenheit gabs keine techn. Begrenzung.
Du hast gesagt das EQL Volume
Averange Latency
Reads : 1,59
Writes: <1.0ms,
Weighted Avg: 1,25ms
registriert (Live Session aufgezeichnet oder?) beim Workload diese Werte.
Um diese Werte wuerden dich andere beneiden.
Ich wuerde in eine weitere Analyse keine Zeit investieren es sei denn du bist nicht ausgelastet

Gruss
Joerg
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
seekDistance zeigt an, wie sich die IO's auf der Platte verteilen.
Z. B. zeigen hohe Werte hinter dem Eintrag +1 n, dass viele der IO's auf den nächsten LBN der Platte gehen.
Wenn die Werte am oberen und unteren Rand der Tabelle besonders hoch sind, hast du ausschließlich Random IO's, die wild auf die ganze Platte verteilt werden.
outstandingIO's zeigt an, wie viele IO's annähernd zeitgleich ans Array gesendet wurden.
Wenn die höchsten Werte hinter 1 stehen bedeutet dies, dass dein Tool erst dann neue IO's erzeugt, wenn der vorangegangene IO beantwortet worden ist.
Gruß,
Ralf
seekDistance zeigt an, wie sich die IO's auf der Platte verteilen.
Z. B. zeigen hohe Werte hinter dem Eintrag +1 n, dass viele der IO's auf den nächsten LBN der Platte gehen.
Wenn die Werte am oberen und unteren Rand der Tabelle besonders hoch sind, hast du ausschließlich Random IO's, die wild auf die ganze Platte verteilt werden.
outstandingIO's zeigt an, wie viele IO's annähernd zeitgleich ans Array gesendet wurden.
Wenn die höchsten Werte hinter 1 stehen bedeutet dies, dass dein Tool erst dann neue IO's erzeugt, wenn der vorangegangene IO beantwortet worden ist.
Gruß,
Ralf
Ein Pool, die LUN hatte ich vor den Tests in die den Raid6 accel. Bereich geschoben. Aber wie dann intern die Auto-Tiering damit umgeht, also wieviel auf den SSDs und auf auf den kleinen schnellen Platten landet kann ich dir nicht sagen.
Aber Egal ob auf der EQL 41er oder 61er schwanken die exakt gleichen Tests zwischen 3:45 Min und 7 Min.
Das LUN Design wurde von Dell damals so empfohlen und vorgegeben, rein rechnerisch geht bei uns eher der allgm. Storage Platz aus als die möglichen connections.
Der Reboot eines Hosts dauert exakt 31 Minuten. (hab heut erst Updates eingespielt)
DELL’s Multipath Extension Module bau ich bei der nächste Wartung mit ein.
Ja im Workload, im Hintergurnd lief besagtes Test Tool.
Jeder Host hat min 3x 8x PCIe Anschlüsse, da passt auf jeden Fall noch ne Menge rein.
Was würden ca 3x 256 GB kosten?
Problem ist, das ich wieder nur supportete Dell Hardware einbauen darf, und da fall ich jedesmal vom Stuhl wenn ich die Angebote bekomme
Grüße
Seb
Aber Egal ob auf der EQL 41er oder 61er schwanken die exakt gleichen Tests zwischen 3:45 Min und 7 Min.
Das LUN Design wurde von Dell damals so empfohlen und vorgegeben, rein rechnerisch geht bei uns eher der allgm. Storage Platz aus als die möglichen connections.
Der Reboot eines Hosts dauert exakt 31 Minuten. (hab heut erst Updates eingespielt)
DELL’s Multipath Extension Module bau ich bei der nächste Wartung mit ein.
irix hat geschrieben:Du hast gesagt das EQL Volume
Averange Latency
Reads : 1,59
Writes: <1.0ms,
Weighted Avg: 1,25ms
registriert (Live Session aufgezeichnet oder?) beim Workload diese Werte.
Um diese Werte wuerden dich andere beneiden.
Ja im Workload, im Hintergurnd lief besagtes Test Tool.
irix hat geschrieben:Ich wuerde in eine weitere Analyse keine Zeit investieren es sei denn du bist nicht ausgelastet Smile Wenn der Workload virtuell betrieben werden soll schieb eine SSD oder besser eine NVMe PCIe Karte rein. Letzteres machen wir da Steckplaetze im Server vorhanden aber keine geeigneten Controller.
Jeder Host hat min 3x 8x PCIe Anschlüsse, da passt auf jeden Fall noch ne Menge rein.
Was würden ca 3x 256 GB kosten?
Problem ist, das ich wieder nur supportete Dell Hardware einbauen darf, und da fall ich jedesmal vom Stuhl wenn ich die Angebote bekomme

Grüße
Seb
hier die SeekDistance:
Histogram: distance (in LBNs) between successive commands for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -203170223
max : 209715185
mean : -16
count : 41065
{
10849 (<= -500000)
1498 (<= -100000)
1474 (<= -50000)
2223 (<= -10000)
27 (<= -5000)
444 (<= -1000)
84 (<= -500)
85 (<= -128)
27 (<= -64)
21 (<= -32)
1516 (<= -16)
1563 (<= -8)
477 (<= -6)
431 (<= -4)
459 (<= -2)
239 (<= -1)
244 (<= 0)
1419 (<= 1)
0 (<= 2)
1 (<= 4)
2 (<= 6)
1 (<=
999 (<= 16)
683 (<= 32)
322 (<= 64)
342 (<= 128)
323 (<= 500)
79 (<= 1000)
387 (<= 5000)
212 (<= 10000)
3676 (<= 50000)
232 (<= 100000)
965 (<= 500000)
9761 (> 500000)
}
}
Histogram: distance (in LBNs) between successive Read commands for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -174287199
max : 209715185
mean : 34338
count : 992
{
257 (<= -500000)
15 (<= -100000)
9 (<= -50000)
24 (<= -10000)
15 (<= -5000)
37 (<= -1000)
10 (<= -500)
34 (<= -128)
21 (<= -64)
10 (<= -32)
3 (<= -16)
10 (<= -8)
0 (<= -6)
1 (<= -4)
0 (<= -2)
2 (<= -1)
1 (<= 0)
66 (<= 1)
0 (<= 2)
0 (<= 4)
0 (<= 6)
0 (<=
5 (<= 16)
5 (<= 32)
5 (<= 64)
14 (<= 128)
31 (<= 500)
14 (<= 1000)
45 (<= 5000)
32 (<= 10000)
40 (<= 50000)
7 (<= 100000)
19 (<= 500000)
260 (> 500000)
}
}
Histogram: distance (in LBNs) between successive Write commands for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -113150039
max : 113165353
mean : -16
count : 40073
{
10602 (<= -500000)
1479 (<= -100000)
1468 (<= -50000)
2192 (<= -10000)
13 (<= -5000)
405 (<= -1000)
74 (<= -500)
51 (<= -128)
9 (<= -64)
7 (<= -32)
1513 (<= -16)
1553 (<= -8)
480 (<= -6)
430 (<= -4)
462 (<= -2)
237 (<= -1)
244 (<= 0)
1356 (<= 1)
0 (<= 2)
1 (<= 4)
2 (<= 6)
1 (<=
996 (<= 16)
676 (<= 32)
317 (<= 64)
324 (<= 128)
299 (<= 500)
67 (<= 1000)
341 (<= 5000)
182 (<= 10000)
3640 (<= 50000)
224 (<= 100000)
946 (<= 500000)
9482 (> 500000)
}
}
Histogram: distance (in LBNs) between each command from the closest of previous 16 for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -111828733
max : 209644869
mean : 852310
count : 41065
{
1112 (<= -500000)
704 (<= -100000)
300 (<= -50000)
425 (<= -10000)
96 (<= -5000)
167 (<= -1000)
59 (<= -500)
115 (<= -128)
89 (<= -64)
94 (<= -32)
1504 (<= -16)
2331 (<= -8)
8024 (<= -6)
1854 (<= -4)
1679 (<= -2)
904 (<= -1)
992 (<= 0)
9232 (<= 1)
1 (<= 2)
121 (<= 4)
4 (<= 6)
85 (<=
823 (<= 16)
487 (<= 32)
432 (<= 64)
499 (<= 128)
482 (<= 500)
226 (<= 1000)
1244 (<= 5000)
899 (<= 10000)
591 (<= 50000)
782 (<= 100000)
1443 (<= 500000)
3265 (> 500000)
}
}
Histogram: distance (in LBNs) between successive commands for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -203170223
max : 209715185
mean : -16
count : 41065
{
10849 (<= -500000)
1498 (<= -100000)
1474 (<= -50000)
2223 (<= -10000)
27 (<= -5000)
444 (<= -1000)
84 (<= -500)
85 (<= -128)
27 (<= -64)
21 (<= -32)
1516 (<= -16)
1563 (<= -8)
477 (<= -6)
431 (<= -4)
459 (<= -2)
239 (<= -1)
244 (<= 0)
1419 (<= 1)
0 (<= 2)
1 (<= 4)
2 (<= 6)
1 (<=

999 (<= 16)
683 (<= 32)
322 (<= 64)
342 (<= 128)
323 (<= 500)
79 (<= 1000)
387 (<= 5000)
212 (<= 10000)
3676 (<= 50000)
232 (<= 100000)
965 (<= 500000)
9761 (> 500000)
}
}
Histogram: distance (in LBNs) between successive Read commands for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -174287199
max : 209715185
mean : 34338
count : 992
{
257 (<= -500000)
15 (<= -100000)
9 (<= -50000)
24 (<= -10000)
15 (<= -5000)
37 (<= -1000)
10 (<= -500)
34 (<= -128)
21 (<= -64)
10 (<= -32)
3 (<= -16)
10 (<= -8)
0 (<= -6)
1 (<= -4)
0 (<= -2)
2 (<= -1)
1 (<= 0)
66 (<= 1)
0 (<= 2)
0 (<= 4)
0 (<= 6)
0 (<=

5 (<= 16)
5 (<= 32)
5 (<= 64)
14 (<= 128)
31 (<= 500)
14 (<= 1000)
45 (<= 5000)
32 (<= 10000)
40 (<= 50000)
7 (<= 100000)
19 (<= 500000)
260 (> 500000)
}
}
Histogram: distance (in LBNs) between successive Write commands for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -113150039
max : 113165353
mean : -16
count : 40073
{
10602 (<= -500000)
1479 (<= -100000)
1468 (<= -50000)
2192 (<= -10000)
13 (<= -5000)
405 (<= -1000)
74 (<= -500)
51 (<= -128)
9 (<= -64)
7 (<= -32)
1513 (<= -16)
1553 (<= -8)
480 (<= -6)
430 (<= -4)
462 (<= -2)
237 (<= -1)
244 (<= 0)
1356 (<= 1)
0 (<= 2)
1 (<= 4)
2 (<= 6)
1 (<=

996 (<= 16)
676 (<= 32)
317 (<= 64)
324 (<= 128)
299 (<= 500)
67 (<= 1000)
341 (<= 5000)
182 (<= 10000)
3640 (<= 50000)
224 (<= 100000)
946 (<= 500000)
9482 (> 500000)
}
}
Histogram: distance (in LBNs) between each command from the closest of previous 16 for virtual machine worldGroupID : 64178, virtual disk handleID : 8195 (scsi1:0) {
min : -111828733
max : 209644869
mean : 852310
count : 41065
{
1112 (<= -500000)
704 (<= -100000)
300 (<= -50000)
425 (<= -10000)
96 (<= -5000)
167 (<= -1000)
59 (<= -500)
115 (<= -128)
89 (<= -64)
94 (<= -32)
1504 (<= -16)
2331 (<= -8)
8024 (<= -6)
1854 (<= -4)
1679 (<= -2)
904 (<= -1)
992 (<= 0)
9232 (<= 1)
1 (<= 2)
121 (<= 4)
4 (<= 6)
85 (<=

823 (<= 16)
487 (<= 32)
432 (<= 64)
499 (<= 128)
482 (<= 500)
226 (<= 1000)
1244 (<= 5000)
899 (<= 10000)
591 (<= 50000)
782 (<= 100000)
1443 (<= 500000)
3265 (> 500000)
}
}
Sind die SSDs als Lese oder auch als Schreibcache Konfiguriert.
Dann dürftest du maximal 3500 IOPs auf der PS41 und ca. 4000-6000 IOPs PS61
unter der annahme das du 2 Hostspare und 2 parity pro Storage hast.
Die 840er PRO Samsung SSD bringt im schlechtesten Fall 20.000 bis 80.000 IOPS
was sich dann auch in deiner Zeitmessung wiederspiegelt.
Und wie hier schon einige dir mitteilten, hast du sehr viele "random access" was die
Leistung nochmals reduziert.
Wenn du genug Platz hast dann verschiebe alle mal von PS61 auf PS41 dann neue Lun.
Wir haben ca 80 Systeme auf einer iSCSI Lun mit eine NETAPP 8020, und das läuft sehr
Stabil und Performant.
Viele Grüße
Jörg
PS: hier mal eine Möglichkeit der IOPs Berechnung:
Using specifications of a Samsung Spinpoint F3 HD103SJ 7200RPM, avg seek time 8.9ms, avg latency 4.17ms
IOPS = 1/ (0.00417 + 0.0089) = 1000/(4.17 + 8.9) = ~76 IOPs
Dann dürftest du maximal 3500 IOPs auf der PS41 und ca. 4000-6000 IOPs PS61
unter der annahme das du 2 Hostspare und 2 parity pro Storage hast.
Die 840er PRO Samsung SSD bringt im schlechtesten Fall 20.000 bis 80.000 IOPS
was sich dann auch in deiner Zeitmessung wiederspiegelt.
Und wie hier schon einige dir mitteilten, hast du sehr viele "random access" was die
Leistung nochmals reduziert.
Wenn du genug Platz hast dann verschiebe alle mal von PS61 auf PS41 dann neue Lun.
Wir haben ca 80 Systeme auf einer iSCSI Lun mit eine NETAPP 8020, und das läuft sehr
Stabil und Performant.
Viele Grüße
Jörg
PS: hier mal eine Möglichkeit der IOPs Berechnung:
Using specifications of a Samsung Spinpoint F3 HD103SJ 7200RPM, avg seek time 8.9ms, avg latency 4.17ms
IOPS = 1/ (0.00417 + 0.0089) = 1000/(4.17 + 8.9) = ~76 IOPs
-
- King of the Hill
- Beiträge: 13043
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
@Jörg,
bei einer EQL Hybrid gibt es nichts zu konfigurieren und die SSDs sowie HDD laufen jeweils als RAID6 und es gibt eine HDD als GlobalHotspare. Die SSD Kapazitaet wird geteilt so das alle Writes aufgenommen werden sofern moeglich und die andere Haelfte "HotData" enthaelt.
@Seb,
ich persoenlich finde das Unklug beide in einem Pool zuhaben weil die erste Stufe des ALB ist Kapazitaetsorientiert und die PS4110 hat doppelt soviel wie die PS6110 (9TB Netto oder?). Das heisst es liegen 2/3 des Volumes auf der PS4110 sofern man nichts weiter macht.
Wo ein Volume genau liegt siehst du im GroupManager wenn du das Volume auswaehlst. Das mit der Raid Preference ist nur eine "weiche" Empfehlung und keine strikte Zuweisung. Wenn einen der Storage der Platz ausgeht dann kommt da Bewegung in die Sache und die Daten liegen nicht mehr da wo man meint sie hingetan zuhaben. Das ist aber die natuerliche "DNA" von Dell EQL.
Wenn du nur einen weiteren ESXi Hosts hinzufuegen muesstest dann stoesst du gegen Max. Connections.
Wir haben die Intel DC P3500 und DC P3600 in unseren Dell Servern im Einsatz und je nach Laune als vFRC, SSD Datastore oder fuer PernixData FVP. Wenn du mehr wissen willst schreib eine PM oder ruf an.
Gruss
Joerg
bei einer EQL Hybrid gibt es nichts zu konfigurieren und die SSDs sowie HDD laufen jeweils als RAID6 und es gibt eine HDD als GlobalHotspare. Die SSD Kapazitaet wird geteilt so das alle Writes aufgenommen werden sofern moeglich und die andere Haelfte "HotData" enthaelt.
@Seb,
ich persoenlich finde das Unklug beide in einem Pool zuhaben weil die erste Stufe des ALB ist Kapazitaetsorientiert und die PS4110 hat doppelt soviel wie die PS6110 (9TB Netto oder?). Das heisst es liegen 2/3 des Volumes auf der PS4110 sofern man nichts weiter macht.
Wo ein Volume genau liegt siehst du im GroupManager wenn du das Volume auswaehlst. Das mit der Raid Preference ist nur eine "weiche" Empfehlung und keine strikte Zuweisung. Wenn einen der Storage der Platz ausgeht dann kommt da Bewegung in die Sache und die Daten liegen nicht mehr da wo man meint sie hingetan zuhaben. Das ist aber die natuerliche "DNA" von Dell EQL.
Wenn du nur einen weiteren ESXi Hosts hinzufuegen muesstest dann stoesst du gegen Max. Connections.
Wir haben die Intel DC P3500 und DC P3600 in unseren Dell Servern im Einsatz und je nach Laune als vFRC, SSD Datastore oder fuer PernixData FVP. Wenn du mehr wissen willst schreib eine PM oder ruf an.
Gruss
Joerg
Hallo, mit der Intel® SSD DC 3610 Series habe ich gute erfahrungen gemacht.
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-dc-s3x10-series-brief.html
Gruß
Jörg
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-dc-s3x10-series-brief.html
Gruß
Jörg
Hello,
ich habe mir mal den "Spaß" gemacht und eine RAMDISK eingefügt, und den kompletten Workspace auf die Disk gelegt.
Also fliegt der Flaschenhals für den Test weg.
Ohne das ich an der RAM oder CPU Reservierung oder etwas anpasse, sind die Testlaufzeiten meist um die 3:30 Minuten.
Aber jetzt kommts, reserviere ich für die VM 3 GHZ läuft ein Test knapp eine Minute, also sind meine CPUs zu langsam
ich habe mir mal den "Spaß" gemacht und eine RAMDISK eingefügt, und den kompletten Workspace auf die Disk gelegt.
Also fliegt der Flaschenhals für den Test weg.
Ohne das ich an der RAM oder CPU Reservierung oder etwas anpasse, sind die Testlaufzeiten meist um die 3:30 Minuten.
Aber jetzt kommts, reserviere ich für die VM 3 GHZ läuft ein Test knapp eine Minute, also sind meine CPUs zu langsam

@ReedyTT: Interessanter Fred. Bei sehr starker Auslastung der virtuellen Netzwerkkarte innerhalb einer VM ist wie Du bereits selber festgestellt hast, sehr gerne die CPU der limitierende Faktor.
Auf meinen lokalen SSD's (DC-S3700 im Software RAID 10 unter W2012) konnte ich eine nahezu lineare Steigerung der Random-IO's messen für jeden Kern den ich hinzgefügt habe. Fast bis zum Limit der Herstellerangaben.
Das dumme an der Sache ist, dass Du bei lokaler Anbindung - zumindest wen das Storage via VM bereitgestellt wird - die Performance auf den Verbraucher-VM's und der Storage-VM bereitgestellt werden muss. Das verbratet bei ein paar Copy-Jobs ne Menge CPU-Leistung weil das Storage eben ungewohnterweise alles wegschaufeln kann.
Besser wäre sicher ein direktangebundenes, hochzuverlässiges Flash-Storage (In Intel S3700 Qualität) ohne eine Storage-VM. Gleich mit integrierten RAID-Features.
Ein extrem zuverlässiges Flash storage und eine Zeitnahe Datensicherung würde es aber unter Umständen auch tun wenn der Flashstorage top ist. Je nach Betriebsgrösse halt. Bei euch ist das ja sicher kein Thema.
Einige Adapter lassen auch ein Offloading zu, damit der Kram eben nicht von der CPU sondern vom spezifischen Lan-Adapter berechnet wird. Damit habe ich aber keine Erfahrung, da die externen Storages in dieser Leistungsklasse nicht wirklich meine Kragenweite sind.
Wie es dann mit Host-Internem Traffic aussieht weiss ich auch nicht, also wenn die beiden VM's auf der gleichen Maschine liegen. Evtl. kommt dann wieder die CPU zum Zug. Kenne ich mich leider auch nicht aus.
Auf meinen lokalen SSD's (DC-S3700 im Software RAID 10 unter W2012) konnte ich eine nahezu lineare Steigerung der Random-IO's messen für jeden Kern den ich hinzgefügt habe. Fast bis zum Limit der Herstellerangaben.
Das dumme an der Sache ist, dass Du bei lokaler Anbindung - zumindest wen das Storage via VM bereitgestellt wird - die Performance auf den Verbraucher-VM's und der Storage-VM bereitgestellt werden muss. Das verbratet bei ein paar Copy-Jobs ne Menge CPU-Leistung weil das Storage eben ungewohnterweise alles wegschaufeln kann.
Besser wäre sicher ein direktangebundenes, hochzuverlässiges Flash-Storage (In Intel S3700 Qualität) ohne eine Storage-VM. Gleich mit integrierten RAID-Features.
Ein extrem zuverlässiges Flash storage und eine Zeitnahe Datensicherung würde es aber unter Umständen auch tun wenn der Flashstorage top ist. Je nach Betriebsgrösse halt. Bei euch ist das ja sicher kein Thema.

Einige Adapter lassen auch ein Offloading zu, damit der Kram eben nicht von der CPU sondern vom spezifischen Lan-Adapter berechnet wird. Damit habe ich aber keine Erfahrung, da die externen Storages in dieser Leistungsklasse nicht wirklich meine Kragenweite sind.

Wie es dann mit Host-Internem Traffic aussieht weiss ich auch nicht, also wenn die beiden VM's auf der gleichen Maschine liegen. Evtl. kommt dann wieder die CPU zum Zug. Kenne ich mich leider auch nicht aus.
Zurück zu „vSphere 5.5 / ESXi 5.5“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste