10 GB BKF-File über vSwitch 11 Minuten ??????????

[bla!zilla]

]Ich befürchte, du wirst da wohl leider nicht viel mehr erwarten dürfen. Höchstwahrscheinlich zählt der P400-Controller nicht zur performanteren Reihe von Raid-Controllern...

Der P400 an sich ist ein fixer Controller. Es ist das Konstrukt, was halt nicht auf Touren kommt.

[Dayworker]

Mit mehr als 4 Platten wäre dann wohl immer ein Raid10 angesagt.

[djbreezer]

mit was für Raten kann ich rechnen, wenn ich das ganze zu nem Raid10 migriere? Lohnt es sich? Ich mein 15 MB/s ist jetzt wirklich nicht die Welt! Wenn man mit großen ISOs u.ä. arbeitet gehen jedesmal etliche Minuten drauf in denen man einfach nur wartet... ist manchmal wirklich deprimierend Auf dem Host laufen schließlich nur 5 VMs! Ok eine davon ist ein Exchange 2010, der sich auch n großen Teil der Performance-Torte abschneidet, aber da muss doch noch ein bißchem mehr drin sein.

[irix]

Ich meine das mein DL380 G5 mit dem P400 und ein RAID10 aus 8 Platten mir bei IOmeter mit den Traeumerwerten (=Unrealistisch) von 81921/1/16 und 64GB/100%,Read mit 220MB/s gibt.

Wir hatten hier schon mal die Zeit zur Erstellung einer 10GB eagerzeroThick VMDK gestoppt und Zeiten von div. Storagen gelistet.

Gruss
Joerg

[djbreezer]

wie siehts denn mit iSCSI aus? Hab eben im Netz mal geschaut... laut diverser Foren soll unser NAS 110 MB/s schaffen. Ist das über iSCSI realisierbar? Dann könne ich die Partitionen die performanter sein sollen auf iSCSI auslagern. Hab aber keine HBA hier, würde also den Softwareinitiator nutzen.

[bla!zilla]

Es ist immer eine Frage wie getestet wird. Wenn ich mit großen IOs teste, dann komme ich auch auf ordentlich MB/s. Wenn ich aber eher kleinere IOs habe, so wie es meist bei Virtualisierungsumgebungen ist, dann kann ich keine MB/s erwarten.

[djbreezer]

Es ist immer eine Frage wie getestet wird. Wenn ich mit großen IOs teste, dann komme ich auch auf ordentlich MB/s. Wenn ich aber eher kleinere IOs habe, so wie es meist bei Virtualisierungsumgebungen ist, dann kann ich keine MB/s erwarten.

Ich teste nun mal selbst. Ich nehm also am besten ne kleine Blocksize wieder 4k und vergleich die Werte mit denen aus dem Local-Storage.

EDIT: Und siehe da, das NAS kommt eigentlich gut weg bei der Sache:

Code: Alles auswählen

Command Line:

    % dt.exe of=d:\dt.dat bs=4k limit=3g iotype=sequential log=d:\dt.log

   --> Date: February 6th, 2001, Version: 14.3, Author: Robin T. Miller <--

Write Statistics:
     Total records processed: 786432 @ 4096 bytes/record (4.000 Kbytes)
     Total bytes transferred: 3221225472 (3145728.000 Kbytes, 3072.000 Mbytes)
      Average transfer rates: 57330441 bytes/sec, 55986.759 Kbytes/sec
     Number I/O's per second: 13996.690
      Total passes completed: 0/1
       Total errors detected: 0/1
          Total elapsed time: 00m56.18s
           Total system time: 00m16.06s
             Total user time: 00m16.37s

Read Statistics:
     Total records processed: 786432 @ 4096 bytes/record (4.000 Kbytes)
     Total bytes transferred: 3221225472 (3145728.000 Kbytes, 3072.000 Mbytes)
      Average transfer rates: 89168871 bytes/sec, 87078.976 Kbytes/sec
     Number I/O's per second: 21769.744
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m36.12s
           Total system time: 00m06.25s
             Total user time: 00m29.87s

Total Statistics:
     Output device/file name: d:\dt.dat (device type=regular)
     Type of I/O's performed: sequential (forward)
   Data pattern read/written: 0x39c39c39
     Total records processed: 1572864 @ 4096 bytes/record (4.000 Kbytes)
     Total bytes transferred: 6442450944 (6291456.000 Kbytes, 6144.000 Mbytes)
      Average transfer rates: 69789962 bytes/sec, 68154.259 Kbytes/sec
     Number I/O's per second: 17038.565
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 01m32.31s
           Total system time: 00m22.31s
             Total user time: 00m46.25s
               Starting time: Tue Jun 22 07:26:40 2010
                 Ending time: Tue Jun 22 07:28:12 2010



[djbreezer]

so und mit 64k Blocksize ist das NAS sogar schneller:

Code: Alles auswählen

Command Line:

    % dt.exe of=d:\dt.dat bs=64k limit=3g iotype=sequential log=d:\dt.log

   --> Date: February 6th, 2001, Version: 14.3, Author: Robin T. Miller <--

Write Statistics:
     Total records processed: 49152 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 3221225472 (3145728.000 Kbytes, 3072.000 Mbytes)
      Average transfer rates: 64930971 bytes/sec, 63409.151 Kbytes/sec
     Number I/O's per second: 990.768
      Total passes completed: 0/1
       Total errors detected: 0/1
          Total elapsed time: 00m49.61s
           Total system time: 00m29.07s
             Total user time: 00m19.29s

Read Statistics:
     Total records processed: 49152 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 3221225472 (3145728.000 Kbytes, 3072.000 Mbytes)
      Average transfer rates: 94741926 bytes/sec, 92521.412 Kbytes/sec
     Number I/O's per second: 1445.647
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m34.00s
           Total system time: 00m05.40s
             Total user time: 00m28.57s

Total Statistics:
     Output device/file name: d:\dt.dat (device type=regular)
     Type of I/O's performed: sequential (forward)
   Data pattern read/written: 0x39c39c39
     Total records processed: 98304 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 6442450944 (6291456.000 Kbytes, 6144.000 Mbytes)
      Average transfer rates: 77039772 bytes/sec, 75234.152 Kbytes/sec
     Number I/O's per second: 1175.534
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 01m23.62s
           Total system time: 00m34.50s
             Total user time: 00m47.87s
               Starting time: Tue Jun 22 07:33:53 2010
                 Ending time: Tue Jun 22 07:35:17 2010


Das ist doch garnicht möglich! Ist da eventuell der iSCSI-Initiator am cachen?! Solche Werte über iSCSI sind doch unmöglich.... oder?

Welche Rolle spielt die Dateigröße bei meinen Messungen genau? Sobald die Dateien größer als 3 GB werden sinkt die Read-Rate EXTREM teilweise nur noch 9-10 MB/s !!!! Wie kann das sein? Die Write-Rate bleibt konstant hoch!

[djbreezer]

Falls du genau wissen möchtest, wie die Disks der VM ausgelastet sind, dann empfehle ich dir das Tool vscsiStats, welches auf jedem ESX Server vorhanden ist.

Gruß
Ralf

Habe mir das Tool gerade mal angeschaut... es bietet mir leider nicht die Möglichkeit die Gesamte Lese-/Schreibrate auf das Raid anzuzeigen. Es gibt mir nur Auskunft über jede einzelne VM!

[kastlr]

Hallo,

das ist korrekt, aber da du das Tool ja offenbar innerhalb einer VM laufen läßt, kannst du dir genau ansehen, wie sich z.B. die Antwortzeiten verhalten, ob du sequentiell oder random arbeitest usw.

Viel Erfolg,
Ralf

[djbreezer]

So ich kram das Thema jetzt nochmal aus...
ich habe jetzt mal ein paar Performance-Messungen gemacht und komischerweise habe ich bessere Werte wenn ich ein Raid5 nutze! Hat jemand eine Idee woran das liegen kann? Ich habe alle bei der Bereitstellung der vmdks immer die gleichen Werte genutzt:

iSCSI Target = 1,7 TB
Blocksize = 4 MB
vmdk = 800 GB
MTU = 9000

Hier die Messlogs:

RAID5:

Code: Alles auswählen

Command Line:

    % dt.exe of=d:\dt.dat bs=64k limit=2g iotype=sequential log=d:\dt.log

   --> Date: February 6th, 2001, Version: 14.3, Author: Robin T. Miller <--

Write Statistics:
     Total records processed: 32768 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 71846224 bytes/sec, 70162.329 Kbytes/sec
     Number I/O's per second: 1096.286
      Total passes completed: 0/1
       Total errors detected: 0/1
          Total elapsed time: 00m29.89s
           Total system time: 00m17.92s
             Total user time: 00m08.81s

Read Statistics:
     Total records processed: 32768 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 98521982 bytes/sec, 96212.873 Kbytes/sec
     Number I/O's per second: 1503.326
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m21.79s
           Total system time: 00m03.34s
             Total user time: 00m18.45s

Total Statistics:
     Output device/file name: d:\dt.dat (device type=regular)
     Type of I/O's performed: sequential (forward)
   Data pattern read/written: 0x39c39c39
     Total records processed: 65536 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 4294967296 (4194304.000 Kbytes, 4096.000 Mbytes)
      Average transfer rates: 83095697 bytes/sec, 81148.142 Kbytes/sec
     Number I/O's per second: 1267.940
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m51.68s
           Total system time: 00m21.26s
             Total user time: 00m27.26s
               Starting time: Wed Aug 11 16:52:03 2010
                 Ending time: Wed Aug 11 16:52:55 2010



RAID10:

Code: Alles auswählen

Command Line:

    % dt.exe of=d:\dt.dat bs=64k limit=2g iotype=sequential log=d:\dt-raid10.log

   --> Date: February 6th, 2001, Version: 14.3, Author: Robin T. Miller <--

Write Statistics:
     Total records processed: 32768 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 67173939 bytes/sec, 65599.550 Kbytes/sec
     Number I/O's per second: 1024.993
      Total passes completed: 0/1
       Total errors detected: 0/1
          Total elapsed time: 00m31.96s
           Total system time: 00m15.84s
             Total user time: 00m10.35s

Read Statistics:
     Total records processed: 32768 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 98666834 bytes/sec, 96354.330 Kbytes/sec
     Number I/O's per second: 1505.536
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m21.76s
           Total system time: 00m03.20s
             Total user time: 00m18.56s

Total Statistics:
     Output device/file name: d:\dt.dat (device type=regular)
     Type of I/O's performed: sequential (forward)
   Data pattern read/written: 0x39c39c39
     Total records processed: 65536 @ 65536 bytes/record (64.000 Kbytes)
     Total bytes transferred: 4294967296 (4194304.000 Kbytes, 4096.000 Mbytes)
      Average transfer rates: 79930161 bytes/sec, 78056.798 Kbytes/sec
     Number I/O's per second: 1219.637
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m53.73s
           Total system time: 00m19.04s
             Total user time: 00m28.92s
               Starting time: Wed Aug 11 17:19:05 2010
                 Ending time: Wed Aug 11 17:19:59 2010


Meiner Meinung nach sollte das Raid10 doch eigentlich schneller sein, da keine Paritäten berechnet werden müssen. Oder hab ich da irgendwo noch n Denkfehler oder irgendwas übersehen?

In einem weiteren Test in dem ich ein Raid10 eingerichtet habe und das iSCSI-Target an das Ende vom Raid gelegt habe, ist die Schreibrate auf 20 MB/s abgesunken! Wie ist das möglich? Kann die Rate so massiv abfallen weil dann die äußeren Spuren der Platten genutzt werden?

[Dayworker]

Server-Platten haben nicht umsonst eine geringere Kapazität als deren Desktop-Derivate. Vielen Server-Hersteller nutzen nur die äußeren, schnellen Plattenbereiche und der Rest bleibt ungenutzt. Dadurch verhindern sie aber gleichzeitig auch einen spürbaren IO-Einbruch auf den inneren, langsameren Bereichen.

[djbreezer]

Wunderbar.. machtg auch Sinn. Somit ist dann auch klar warum das Target am Ende das Raids so viel langsamer war... dann werd ich da wohl den ISO-Store unterbringen... nun gilt es nur noch zu klären wie ein Raid in dem Paritäten berechnet werden müssen schneller sein kann als eines wo die nicht passiert.
Bzw. wäre ne kleine Stellungnahme von den Storage-Experten zu den Messwerten auch n nettes Feature für diesen Thread

[Dayworker]

Ein ungeschicktes Stripe-Size würde auch noch die IO-Rate extrem drücken.

[Saturnous]

Nur glaubst du nun das Werte innerhalb einer VM etwas bedeuten, ohne die CPU zu betrachten sind die nicht allzuviel Wert. Zieht dein virtueller SCSI Kontroller Interrupte verliert er Ticks - verliert er Ticks misst er die Zeit schief. Schau über esxtop oder performance Tab auf den Durchsatz - und kopiere Dateien über 500 MB mit dem ESEUTIL.

http://technet.microsoft.com/en-us/libr ... 65%29.aspx

[djbreezer]

Ein ungeschicktes Stripe-Size würde auch noch die IO-Rate extrem drücken.

Ich gehe davon aus, dass du die Stripe-Size meines Raids auf dem NAS meinst... da ist die aktuelle Stripe-Size auf 64kb. Welche Stripe-Size macht deiner Meinung nach bei folgenden Werten denn mehr Sinn?

Blocksize 1 MB
MTU 9000

Oder meinst du vll die NTFS Blocksize (4k) in der VM ?

[djbreezer]

Nur glaubst du nun das Werte innerhalb einer VM etwas bedeuten, ohne die CPU zu betrachten sind die nicht allzuviel Wert. Zieht dein virtueller SCSI Kontroller Interrupte verliert er Ticks - verliert er Ticks misst er die Zeit schief. Schau über esxtop oder performance Tab auf den Durchsatz - und kopiere Dateien über 500 MB mit dem ESEUTIL.

http://technet.microsoft.com/en-us/libr ... 65%29.aspx

Worin genau unterscheidet sich ein "normaler" Kopiervorgang zu einem Kopiervorgang mit ESEUTIL ? Aber ich kenn den Test gern mal machen. Du meinst also, dass mein Raid5 eigentlich garnicht schneller ist als mein Raid10 und es sich nur um Schwankungen handelt die vom ESXi herrühren?

[Dayworker]

Ein ungeschicktes Stripe-Size würde auch noch die IO-Rate extrem drücken.

Ich gehe davon aus, dass du die Stripe-Size meines Raids auf dem NAS meinst... da ist die aktuelle Stripe-Size auf 64kb. Welche Stripe-Size macht deiner Meinung nach bei folgenden Werten denn mehr Sinn?

Blocksize 1 MB
MTU 9000

Oder meinst du vll die NTFS Blocksize (4k) in der VM ?

Ich meine schon den Raid-Stripe-Size. Ob 64kByte da optimal sind, kann ich dir nicht sagen. Es kommt auch immer darauf an, was dein Raid-Controller da anbietet und im Normalfall sollte im Manual dazu ein Vermerk existieren, welche Einstellung bevorzugt wird.

[add]
Lies dir mal VMware RAID 5 vs 10 and stripe size und Disk Performance Hands On, Part 2: RAID 10 Performance durch. Hab ich auf die Schnelle gefunden, aber noch nicht durchgelesen.

[djbreezer]

Hi nochmal,
hab nunmal ein Target als RAW-Device gemappt und schon ist der ProCurve das Nadelöhr:

Code: Alles auswählen

Command Line:

    % dt.exe of=G:\dt.dat bs=32k limit=2g iotype=sequential log=G:\dt.log

   --> Date: February 6th, 2001, Version: 14.3, Author: Robin T. Miller <--

Write Statistics:
     Total records processed: 65536 @ 32768 bytes/record (32.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 106127188 bytes/sec, 103639.832 Kbytes/sec
     Number I/O's per second: 3238.745
      Total passes completed: 0/1
       Total errors detected: 0/1
          Total elapsed time: 00m20.23s
           Total system time: 00m08.36s
             Total user time: 00m09.53s

Read Statistics:
     Total records processed: 65536 @ 32768 bytes/record (32.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 98103410 bytes/sec, 95804.111 Kbytes/sec
     Number I/O's per second: 2993.878
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m21.89s
           Total system time: 00m02.98s
             Total user time: 00m18.90s

Total Statistics:
     Output device/file name: G:\dt.dat (device type=regular)
     Type of I/O's performed: sequential (forward)
   Data pattern read/written: 0x39c39c39
     Total records processed: 131072 @ 32768 bytes/record (32.000 Kbytes)
     Total bytes transferred: 4294967296 (4194304.000 Kbytes, 4096.000 Mbytes)
      Average transfer rates: 101957681 bytes/sec, 99568.047 Kbytes/sec
     Number I/O's per second: 3111.501
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m42.12s
           Total system time: 00m11.34s
             Total user time: 00m28.43s
               Starting time: Wed Aug 18 08:08:21 2010
                 Ending time: Wed Aug 18 08:09:03 2010



Sobald ich RoundRobin füür das LUN aktivieren sinken die Werte:

Code: Alles auswählen

Command Line:

    % dt.exe of=G:\dt.dat bs=32k limit=2g iotype=sequential log=G:\dt.log

   --> Date: February 6th, 2001, Version: 14.3, Author: Robin T. Miller <--

Write Statistics:
     Total records processed: 65536 @ 32768 bytes/record (32.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 44973480 bytes/sec, 43919.414 Kbytes/sec
     Number I/O's per second: 1372.482
      Total passes completed: 0/1
       Total errors detected: 0/1
          Total elapsed time: 00m47.75s
           Total system time: 00m09.14s
             Total user time: 00m10.09s

Read Statistics:
     Total records processed: 65536 @ 32768 bytes/record (32.000 Kbytes)
     Total bytes transferred: 2147483648 (2097152.000 Kbytes, 2048.000 Mbytes)
      Average transfer rates: 96720427 bytes/sec, 94453.542 Kbytes/sec
     Number I/O's per second: 2951.673
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 00m22.20s
           Total system time: 00m04.06s
             Total user time: 00m18.14s

Total Statistics:
     Output device/file name: G:\dt.dat (device type=regular)
     Type of I/O's performed: sequential (forward)
   Data pattern read/written: 0x39c39c39
     Total records processed: 131072 @ 32768 bytes/record (32.000 Kbytes)
     Total bytes transferred: 4294967296 (4194304.000 Kbytes, 4096.000 Mbytes)
      Average transfer rates: 61397900 bytes/sec, 59958.887 Kbytes/sec
     Number I/O's per second: 1873.715
      Total passes completed: 1/1
       Total errors detected: 0/1
          Total elapsed time: 01m09.95s
           Total system time: 00m13.20s
             Total user time: 00m28.23s
               Starting time: Wed Aug 18 07:40:17 2010
                 Ending time: Wed Aug 18 07:41:27 2010


Wie kann das sein?

[irix]

Das bei RoundRobin die Werte sinken wenn man nur mit einer "Instanz" sprich einem Lastgenerator arbeitet finde ich normal. Roundrobin bedeutet ja das die Pfade abwechselnd benutzt werden und NICHT GLEICHZEITIG oder?

Sprich richtig wirken tut es erst wenn mehre VMs Last erzeugen.

Gruss
Joerg

[djbreezer]

Das bei RoundRobin die Werte sinken wenn man nur mit einer "Instanz" sprich einem Lastgenerator arbeitet finde ich normal. Roundrobin bedeutet ja das die Pfade abwechselnd benutzt werden und NICHT GLEICHZEITIG oder?

Sprich richtig wirken tut es erst wenn mehre VMs Last erzeugen.

Gruss
Joerg

Wenn ich RR aktiviere wird def. ein Lastenausgleich während meiner Messungen gefahren! Hier mal ein Screenshot:


Po33 = NAS
Po37 = ESX Nic1
Po38 = ESX Nic2

Ich vermute, dass das NAS kein RR unterstützt... kann es mir nicht anders erklären...

[Saturnous]

ESEUTIL greift glaubich per FUA auf das NTFS (nicht sicher), reserviert den Platz beim NTFS sofort und springt deshalb nicht ständig zurück. Eine Kopie über den Explorer ist jedenfalls bei grösseren Dateien LAHM und per scsivstats sieht man das mit fortschreiten so einer megakopie immer wieder Schreibvorgänge in die NTFS Tabelle laufen. Auch bei shares ist eseutil schneller.

Ein Benchmark in der VM wird mit Auslastung der vCPU unrealistische Werte ausgeben. Packst du groessere Bloecke auf den LSI als du in den sympi Registry Einstellungen zugelassen hast dann muss der nach 2 Requests schon einen IRQ ziehen, die vCPU stoppt kurz und verliert ticks (%WAIT geht hoch) - eine Sekunde ist dann keine Sekunde mehr - und du denkst der Durchsatz ist jetzt höher.

Stell dir einen Stotterer vor der beim Joggen bis 100 zählt und meint er kommt 4 Kilometer weit und wäre deshalb Weltklasseläufer .

Kurz gesagt : Prüf den Durchsatz und Latenz mit esxtop oder Performancetab im VI Client gegen.