ESXI 6.7 Data Store Read Latency Hoch

Ser1ous1

Cadet 3rd Year
Dabei seit
Dez. 2017
Beiträge
56
#1
Hi,

verwende dz. ESXI 6.7 als HV, RAID5 mit 5 * 2 TB Seagate 7,2k rpm SATA Platten + SSD Cache (cachecade) 512 GB 850 EVO, heute kommt noch eine im RAID 1 dazu. Controller LSI 9271-8I, Firmware latest usw.

Leider habe ich heftige Peaks bei der Read Latenz. was kann hier das Problem sein?

Gelesen und geschrieben wird untertags wenig, in der Nacht lauft ein Backup, jedoch ist da kein starker Anstieg zu erkennen.
 

Anhänge

d4rksen

Cadet 3rd Year
Dabei seit
März 2008
Beiträge
58
#3
Servus,

welche Hardware ist in dem Host verbaut? Wieviele virtuelle Maschinen laufen, wieviele vCPUs sind bei diesen konfiguriert? Gibt es Snapshots?
 

Ser1ous1

Cadet 3rd Year
Ersteller dieses Themas
Dabei seit
Dez. 2017
Beiträge
56
#4
------------------------------------------------
VD Property Value Status ErrMsg ErrCd
------------------------------------------------
0 DS - Failed DS not Supported 255


Servus,

welche Hardware ist in dem Host verbaut? Wieviele virtuelle Maschinen laufen, wieviele vCPUs sind bei diesen konfiguriert? Gibt es Snapshots?
MB: Supermicro X11SSM-F
RAM: 16 GB Samsung unbuffered ECC (DDR4)
CPU: Intel Pentium G4600 (2 cores 4 threads)

4 VM's

SOPHOS UTM 4 Vcore
Linux Webserver VM Debian 9 4 Vcore
Win2k16 4 Vcore
Monitoring Debian 9 1 Vcore

Keine Snapshots.
CPU Spikes gibt es keine, wenn unter last dann unter 100 % CPU.
Festplatten: 5 * 2 TB Consumer dz. noch im RAID 5
CacheCade: 2 * 512 GB Samsung 850 EVO


Natürlich mit USV und alles was man so braucht..
 
Zuletzt bearbeitet:

d4rksen

Cadet 3rd Year
Dabei seit
März 2008
Beiträge
58
#5
Besteht die Möglichkeit, alle Maschinen auf eine vCPU zu begrenzen und dann das Ganze nochmal zu beobachten? Eine gewisse Oversubscription ist in der Regel in Ordnung, kann jedoch ab einem gewissen Punkt auch zu Performanceproblemen führen. Deshalb die Empfehlung es mal zu beobachten wie es sich verhält wenn du das entsprechend anpasst.
 

Ser1ous1

Cadet 3rd Year
Ersteller dieses Themas
Dabei seit
Dez. 2017
Beiträge
56
#6
Besteht die Möglichkeit, alle Maschinen auf eine vCPU zu begrenzen und dann das Ganze nochmal zu beobachten? Eine gewisse Oversubscription ist in der Regel in Ordnung, kann jedoch ab einem gewissen Punkt auch zu Performanceproblemen führen. Deshalb die Empfehlung es mal zu beobachten wie es sich verhält wenn du das entsprechend anpasst.
Das kann ich mir leider nicht vorstellen: Diagramme im selben Zeitfenster.
 

Anhänge

d4rksen

Cadet 3rd Year
Dabei seit
März 2008
Beiträge
58
#8
Das Chart zeigt die Usage und wie stehts um die Readiness? Kannst die Werte ja mal ggf. per esxtop und hier reinstellen. Du musst es dir ja nicht vorstellen, du kannst es ja einfach mal testen;)

Ansonsten, kannst ja auch mir mal nochmal schauen ob du noch was optimieren kannst(Leider fehlt 6.7 noch, aber ich denke, du kannst dich an 6.5 orientieren) https://kb.vmware.com/s/article/2001003
 
Zuletzt bearbeitet:

Ser1ous1

Cadet 3rd Year
Ersteller dieses Themas
Dabei seit
Dez. 2017
Beiträge
56
#9
Ich sehe das Problem nicht. Bei einem Cache Miss ist die Latenz mit diesen Festplatten völlig normal.
Vermutlich stimmt das, nur hängt da kurz das ganze System. Leider.

Das Chart zeigt die Usage und wie stehts um die Readiness? Kannst die Werte ja mal ggf. per esxtop und hier reinstellen. Du musst es dir ja nicht vorstellen, du kannst es ja einfach mal testen;)

Ansonsten, kannst ja auch mir mal nochmal schauen ob du noch was optimieren kannst(Leider fehlt 6.7 noch, aber ich denke, du kannst dich an 6.5 orientieren) https://kb.vmware.com/s/article/2001003
Danke ich lass das jetzt mal so arbeiten und schau es mir später an.

Update:

Mitlerweile habe ich echte Probleme mit dem Datastore, auch nachdem ich von RAID 10 auf RAID 6 gewechselt habe (VD's gelöscht und Backups eingespielt)

Habe ich den selben schwankenden ATTO Durchsatz? Sequentiell schreiben ist vorallem sehr schlecht! An was könnte das liegen? ATTO Screens folgen.

Cache ist < 1 GB CTRL ist ein 9271-8I mit CacheCade RAID 1
 

Anhänge

Zuletzt bearbeitet:
Top