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 Engpässe finden/Storage testen/I/O Analyzer
Performance Engpässe finden/Storage testen/I/O Analyzer
Moin zusammen,
ich sollte bei einem HA-System mich mal ausgiebiger auf die Suche nach Leistungsengpässen machen.
Wir haben 2 HP DL380 Gen8 mit Xeon E5 2650 und jeweils 164GB RAM im HA-Verbund.
Die reine CPU und RAM Auslastung der Hosts sieht eigentlich noch entspannt aus, wobei ich eine unschöne Lastverteilung habe - die wichtigsten Sachen laufen auf dem ESX01 und ein paar weniger wichtige auf dem ESX02. Das kann sicherlich optimiert werden. Aber meine eigentliche Vermutung ist die Storage. Auf die habe ich zwar Zugriff, aber ich habe das Teil nicht konfiguriert und fasse es nur mit großer Vorsicht an. Da es eh voll ist, soll demnächst was neues her. Aber das Thema Engpass muss vorher zumindest dahingehend gelöst werden, dass eindeutig klar ist, woher es kommt.
Am deutlichsten merken wir es am Terminalserver und den dortigen Anmeldezeiten. Insgesamt laufen 15 VMs (fast ausschließlich Windows 2012 R2), 1x DC, 1x Terminalserver (wobei es noch einen weiteren für besondere Anwendungen gibt), 1x Fileserver, 2x TK-Anlagen, 1x Exchange, 1x SQL, 1x Antivirus, 1x Zertifikatsrv, 1x Lizenzserver, 1x Mailgateway etc. pp. Nichts total herausragendes meiner Wahrnehmung nach.
Als Storage kommt derzeit eine HP G3 2000 zum Einsatz (22 Disks drin, mindestens 1x SATA Krücke, ansonsten 10k SAS in verschiedenen Größen). Mindestens 6 verschiedene Datenspeicher wurden zum ESXi eingebunden (bzw. wenn ich es richtig weiß, redundantes Setup mit FC zu beiden ESXi).
Also so rein von den Eckwerten her dürften doch schlechte Raid-Setups der Hauptgrund sein, oder?
Aber: Wie messe ich das? Habe mal den VMWare i/o Analyzer heruntergeladen und installiert, aber von den Tests verstehe ich zu wenig. Bisher habe ich nur die eine Instanz, die auch als Worker genutzt werden kann. Sollte ich mehrere haben? Welche Tests kann mir jemand empfehlen, um Bandbreite, I/O usw. zu testen?
Wäre sehr dankbar, wenn mir jemand ein bisschen weiterhelfen kann.
Grüße
sappek
ich sollte bei einem HA-System mich mal ausgiebiger auf die Suche nach Leistungsengpässen machen.
Wir haben 2 HP DL380 Gen8 mit Xeon E5 2650 und jeweils 164GB RAM im HA-Verbund.
Die reine CPU und RAM Auslastung der Hosts sieht eigentlich noch entspannt aus, wobei ich eine unschöne Lastverteilung habe - die wichtigsten Sachen laufen auf dem ESX01 und ein paar weniger wichtige auf dem ESX02. Das kann sicherlich optimiert werden. Aber meine eigentliche Vermutung ist die Storage. Auf die habe ich zwar Zugriff, aber ich habe das Teil nicht konfiguriert und fasse es nur mit großer Vorsicht an. Da es eh voll ist, soll demnächst was neues her. Aber das Thema Engpass muss vorher zumindest dahingehend gelöst werden, dass eindeutig klar ist, woher es kommt.
Am deutlichsten merken wir es am Terminalserver und den dortigen Anmeldezeiten. Insgesamt laufen 15 VMs (fast ausschließlich Windows 2012 R2), 1x DC, 1x Terminalserver (wobei es noch einen weiteren für besondere Anwendungen gibt), 1x Fileserver, 2x TK-Anlagen, 1x Exchange, 1x SQL, 1x Antivirus, 1x Zertifikatsrv, 1x Lizenzserver, 1x Mailgateway etc. pp. Nichts total herausragendes meiner Wahrnehmung nach.
Als Storage kommt derzeit eine HP G3 2000 zum Einsatz (22 Disks drin, mindestens 1x SATA Krücke, ansonsten 10k SAS in verschiedenen Größen). Mindestens 6 verschiedene Datenspeicher wurden zum ESXi eingebunden (bzw. wenn ich es richtig weiß, redundantes Setup mit FC zu beiden ESXi).
Also so rein von den Eckwerten her dürften doch schlechte Raid-Setups der Hauptgrund sein, oder?
Aber: Wie messe ich das? Habe mal den VMWare i/o Analyzer heruntergeladen und installiert, aber von den Tests verstehe ich zu wenig. Bisher habe ich nur die eine Instanz, die auch als Worker genutzt werden kann. Sollte ich mehrere haben? Welche Tests kann mir jemand empfehlen, um Bandbreite, I/O usw. zu testen?
Wäre sehr dankbar, wenn mir jemand ein bisschen weiterhelfen kann.
Grüße
sappek
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Ohne jetzt die Storage aus dem Kreis der Verdächtigen holen zu wollen, würde ich erst mal klären (über esxtop oder vergleichbare Tools/Statistiken), ob nicht die z.B. die CPUs (Ready, Co-Stop) Schuld sind. Bei so einem Setup wie deinem können sich die VMs nämlich auch gerne mal gegenseitig auf den (vCPU-)Füßen stehen.
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Musste erst mal ein bisschen schauen, was du damit meinst
OK - sieht auf den ersten Blick nicht gerade optimal aus:
esxi01: 16 Kerne
ts4: 4vpcu
ts1: 16vcpu
sql: 6vpcu
dc: 2vpcu
fs: 2vpcu
exch: 4vcpu
34 gesamt
esxi02: 16 Kerne:
monitor: 4vcpu
app: 2vcpu
cert: 2vcpu
license: 1vcpu
print: 4vcpu
telefon: 2vcpu
mailgw: 4vcpu
vmcs: 4vcpu
22 gesamt
Die Realtime-Charts von ready und co-stopp bringen um die Uhrzeit wohl wenig, oder?
Gibt es eine Option, dass ich ready und co-stopp auch die letzten 24h anzeigen lassen kann?
Danke mal,
sappel
OK - sieht auf den ersten Blick nicht gerade optimal aus:
esxi01: 16 Kerne
ts4: 4vpcu
ts1: 16vcpu
sql: 6vpcu
dc: 2vpcu
fs: 2vpcu
exch: 4vcpu
34 gesamt
esxi02: 16 Kerne:
monitor: 4vcpu
app: 2vcpu
cert: 2vcpu
license: 1vcpu
print: 4vcpu
telefon: 2vcpu
mailgw: 4vcpu
vmcs: 4vcpu
22 gesamt
Die Realtime-Charts von ready und co-stopp bringen um die Uhrzeit wohl wenig, oder?
Gibt es eine Option, dass ich ready und co-stopp auch die letzten 24h anzeigen lassen kann?
Danke mal,
sappel
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Du hast doch ein vCenter und somit Langzeitstats. Evlt. muss der Stat-Level erhoeht werden.
Die ReadyTime im vCenter/ESXi werden nur mit "ms" angezeigt waehrend esxtop diese in % anzeigt. Ich habs auch nach 11 Jahren noch nicht drauf mir die Formel fuer die Umrechnung zu merken.
1. Ein esxtop kann Werte aufzeichnen und dann kann man sie nochmals angucken bzw. auswerten.
2. Bei Performanceproblemen kann man durchaus mal den VMware Support bemuehen
3. Wer kein vRO hat aber ein VeeamOne sollte sich ruhig mal damit beschaeftigen
Was sehr unschoen ist das du einen 16 vCPU TS hast welcher eigentlich alle Cores mal belegt und somit wird keine der anderen VMs ausgefuehrt genau wie diese TS nicht dran kommt wenn eine der anderen dran ist. Bei dieser VM wuerde auch vNUMA zu Anwendung kommen muessen.
Frage: Die Anzeige der Logical CPUs ist doch aber doppelt so oder hast du HT ausgeschaltet bzw. den wegen dem L1TF den optional ESXI Scheduler aktiviert?
In sehr vielen meiner Faelle ist gefuehlte Traegheit von VMs einem schlechten Storage bzw. hohen Latenzen geschuldigt. Ich hatte neulich das erstmal so ein Ding wo eine VM 30 vDISKs hatte und der Kunde jede Produktiv VM auch noch mit VMware Snapshots betreibt. Das AllFlashArray (Tintri) konnte das zwar kaschieren aber die Performance war extrem beieintraechtigt (wir hatten stundenlange Batchjobs(SAP Tablesplitting und Import)).
Gruss
Joerg
Die ReadyTime im vCenter/ESXi werden nur mit "ms" angezeigt waehrend esxtop diese in % anzeigt. Ich habs auch nach 11 Jahren noch nicht drauf mir die Formel fuer die Umrechnung zu merken.
1. Ein esxtop kann Werte aufzeichnen und dann kann man sie nochmals angucken bzw. auswerten.
2. Bei Performanceproblemen kann man durchaus mal den VMware Support bemuehen
3. Wer kein vRO hat aber ein VeeamOne sollte sich ruhig mal damit beschaeftigen
Was sehr unschoen ist das du einen 16 vCPU TS hast welcher eigentlich alle Cores mal belegt und somit wird keine der anderen VMs ausgefuehrt genau wie diese TS nicht dran kommt wenn eine der anderen dran ist. Bei dieser VM wuerde auch vNUMA zu Anwendung kommen muessen.
Frage: Die Anzeige der Logical CPUs ist doch aber doppelt so oder hast du HT ausgeschaltet bzw. den wegen dem L1TF den optional ESXI Scheduler aktiviert?
In sehr vielen meiner Faelle ist gefuehlte Traegheit von VMs einem schlechten Storage bzw. hohen Latenzen geschuldigt. Ich hatte neulich das erstmal so ein Ding wo eine VM 30 vDISKs hatte und der Kunde jede Produktiv VM auch noch mit VMware Snapshots betreibt. Das AllFlashArray (Tintri) konnte das zwar kaschieren aber die Performance war extrem beieintraechtigt (wir hatten stundenlange Batchjobs(SAP Tablesplitting und Import)).
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Danke für deine Antwort.
Die 16vCPUs sind nicht von mir, aber ich habe das Problem verstanden und kümmere mich um Lösung. Ich denke, dass da weniger CPUs eigentlich reichen müssen.
Ufz...HT...irgendwie stocke ich gerade. 8 Kerne pro CPU, 16 Threads pro CPU, bei Dual CPU müssten das ja tatsächlich 32 mögliche Threads pro Server sein. Aber es bleibt doch bei 8 verfügbaren Kernen pro CPU, also 16 gesamt müsste doch stimmen - oder was verstehe ich gerade falsch?
Ich suche die Trägheit ja gerade bzw. deren Ursache, um sie abzuschalten
Auf Snapshots wird nichts betrieben, das ist soweit sicher. Übermäßige Anzahl an Disks hat auch keine VM, in der Regel eine Disk, manchmal zwei.
Das mit dem StatLevel schau ich mir mal an, bin mir nicht sicher. Arbeite i.d.R. mit dem Vsphere Client, nicht Web Client. Weiß nicht, ob mir da die entsprechenden Features ggf. fehlen.
Die 16vCPUs sind nicht von mir, aber ich habe das Problem verstanden und kümmere mich um Lösung. Ich denke, dass da weniger CPUs eigentlich reichen müssen.
Ufz...HT...irgendwie stocke ich gerade. 8 Kerne pro CPU, 16 Threads pro CPU, bei Dual CPU müssten das ja tatsächlich 32 mögliche Threads pro Server sein. Aber es bleibt doch bei 8 verfügbaren Kernen pro CPU, also 16 gesamt müsste doch stimmen - oder was verstehe ich gerade falsch?
Ich suche die Trägheit ja gerade bzw. deren Ursache, um sie abzuschalten
Auf Snapshots wird nichts betrieben, das ist soweit sicher. Übermäßige Anzahl an Disks hat auch keine VM, in der Regel eine Disk, manchmal zwei.
Das mit dem StatLevel schau ich mir mal an, bin mir nicht sicher. Arbeite i.d.R. mit dem Vsphere Client, nicht Web Client. Weiß nicht, ob mir da die entsprechenden Features ggf. fehlen.
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Die vCenter Settings lassen sich genau so auch mit dem vSphere Client bearbeiten. Per Default stehen alle auf Level1.
Anhand deiner Aussage ist nicht klar ob du HT aus oder an hast.
Wieviele LOGISCHE CPUs zeigt der vSphere Client fuer einen deiner Hosts an? Du kannst auch nen Screenshot posten. Die DL380 sind doch mit 2 CPUs bestueckt oder habt ihr einen Sockel freigelassen?
Gruss
Joerg
Anhand deiner Aussage ist nicht klar ob du HT aus oder an hast.
Wieviele LOGISCHE CPUs zeigt der vSphere Client fuer einen deiner Hosts an? Du kannst auch nen Screenshot posten. Die DL380 sind doch mit 2 CPUs bestueckt oder habt ihr einen Sockel freigelassen?
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Er schrieb ja:
Von daher gehe ich davon aus, dass 16 [Korrektur von mir:] physische Kerne verfügbar sind und dass die Performance unter dieser Form der Überbuchung leidet.
Ufz...HT...irgendwie stocke ich gerade. 8 Kerne pro CPU, 16 Threads pro CPU, bei Dual CPU müssten das ja tatsächlich 32 mögliche Threads pro Server sein.
Von daher gehe ich davon aus, dass 16 [Korrektur von mir:] physische Kerne verfügbar sind und dass die Performance unter dieser Form der Überbuchung leidet.
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Also ich habe es nochmal: HT ist aktiv und VMware geht von 32 logischen Prozessoren aus.
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Also so aus Erfahrung wuerde ich sagen das
Certifizierungsstelle,
MailGW
eigentlich wenig CPU benoetigen und dann solltest du vCPU herunterstellen. Wenn du da ein Monitoring hast aus sicht GuestOS dann gucke dir die Auslastung an und stelle die vCPUs nach unten.
Gruss
Joerg
Certifizierungsstelle,
MailGW
eigentlich wenig CPU benoetigen und dann solltest du vCPU herunterstellen. Wenn du da ein Monitoring hast aus sicht GuestOS dann gucke dir die Auslastung an und stelle die vCPUs nach unten.
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Guten Abend zusammen,
komme immer erst abends dazu, das Thema weiter zu verfolgen...danke für eure Anregungen so weit.
Kann mir denn jemand sagen, wonach sich ready und co-stop richten? Nach logischen Kernen oder physischen Kernen?
Ich versuche mal, im vCenter die Werte auch rückwirkend über einen Arbeitstag zu finden.
Danke und Grüße
Helge
komme immer erst abends dazu, das Thema weiter zu verfolgen...danke für eure Anregungen so weit.
Kann mir denn jemand sagen, wonach sich ready und co-stop richten? Nach logischen Kernen oder physischen Kernen?
Ich versuche mal, im vCenter die Werte auch rückwirkend über einen Arbeitstag zu finden.
Danke und Grüße
Helge
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Ich ergänze mal:
Ich sehe gerade beim Ändern der vCPU Anzahl, dass eine VM (ein TS, den wir nicht so oft nutzen) 2 Sockets mit jeweils 2 CPU-Kernen konfiguriert hat. Heißt das für cpu-ready und co-stop, dass sogar auf beiden CPUs für Berechnungen jeweils genau 2 Kerne frei sein müssen? In der Übersicht bei laufender VM stand nur "4vCPU", aber nicht die Verteilung auf die Sockets/Kerne.
Hier mal esxtop von einem ESX
Hier vom anderen ESX:
Die Load-Average Zahlen sprechen doch dafür, dass den Servern langweilig ist - oder sehe ich das falsch?
Ich sehe gerade beim Ändern der vCPU Anzahl, dass eine VM (ein TS, den wir nicht so oft nutzen) 2 Sockets mit jeweils 2 CPU-Kernen konfiguriert hat. Heißt das für cpu-ready und co-stop, dass sogar auf beiden CPUs für Berechnungen jeweils genau 2 Kerne frei sein müssen? In der Übersicht bei laufender VM stand nur "4vCPU", aber nicht die Verteilung auf die Sockets/Kerne.
Hier mal esxtop von einem ESX
Code: Alles auswählen
9:46:46pm up 597 days 10:23, 699 worlds, 8 VMs, 23 vCPUs; CPU load average: 0.06, 0.08, 0.08
PCPU USED(%): 9.1 0.6 5.4 0.3 7.1 0.2 4.5 3.2 3.9 1.2 0.5 6.9 4.7 0.2 2.2 2.7 2.1 1.7 0.9 4.6 4.2 3.5 3.1 0.7 2.6 3.2 3.4 0.2 7.3 0.3 10 0.0 AVG: 3.2
PCPU UTIL(%): 8.0 0.8 4.8 0.3 6.3 0.2 4.2 2.8 3.5 1.2 0.4 6.1 4.3 0.3 2.2 2.6 2.1 1.8 0.9 4.0 3.8 3.0 2.7 0.7 2.4 2.8 3.2 0.2 6.3 0.4 8.9 0.1 AVG: 2.9
CORE UTIL(%): 8.5 5.0 6.5 6.8 4.6 6.4 4.5 4.5 3.6 4.8 6.6 3.3 5.1 3.4 6.6 9.0 AVG: 5.6
ID GID NAME NWLD %USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
1291004492 1291004492 GRSVAV01 (Antiv 10 35.12 29.26 0.16 1000.00 1.78 0.09 458.50 0.12 0.00 0.00 0.00
855250865 855250865 Kaspersky Secur 12 17.99 15.03 0.09 1200.00 0.00 0.25 475.26 0.04 0.00 0.00 0.00
6897 6897 VCMS (VMWARE) 10 16.87 14.11 0.13 1000.00 0.59 0.69 474.12 0.11 0.00 0.00 0.00
822145559 822145559 GRSVTK02 8 8.63 7.07 0.19 800.00 0.31 0.36 237.10 0.07 0.00 0.00 0.00
3611 3611 vpxa.34875 17 6.55 5.45 0.09 1700.00 - 0.19 0.00 0.11 0.00 0.00 0.00
6907 6907 GRSVBS01 (BSK) 8 5.72 4.78 0.03 800.00 1.71 0.08 238.21 0.04 0.00 0.00 0.00
6924 6924 GRSVKM01 (Lizen 6 4.26 3.55 0.01 600.00 0.00 0.03 118.90 0.00 0.00 0.00 0.00
1318203943 1318203943 esxtop.67317469 1 3.60 3.07 0.00 100.00 - 0.00 0.00 0.00 0.00 0.00 0.00
675506467 675506467 GRSVPR02 (Print 9 2.51 2.09 0.02 900.00 0.55 0.14 486.72 0.03 0.00 0.00 0.00
7009 7009 GRSVCA01 (Certi 7 2.19 1.85 0.02 700.00 0.27 0.07 242.58 0.03 0.00 0.00 0.00
2262 2262 hostd.34185 30 1.47 1.04 0.25 3000.00 - 0.06 0.00 0.01 0.00 0.00 0.00
2 2 system 169 1.33 1.19 0.00 16900.00 - 3.11 0.00 0.08 0.00 0.00 0.00
7498 7498 sfcb-ProviderMa 9 0.63 0.52 0.00 900.00 - 0.00 0.00 0.00 0.00 0.00 0.00
4438 4438 sfcb-ProviderMa 6 0.38 0.31 0.00 600.00 - 0.01 0.00 0.00 0.00 0.00 0.00
1312744108 1312744108 sfcb-ProviderMa 11 0.36 0.30 0.00 1100.00 - 0.01 0.00 0.00 0.00 0.00 0.00
4994 4994 fdm.35576 28 0.32 0.27 0.00 2800.00 - 0.05 0.00 0.00 0.00 0.00 0.00
3429 3429 sh.34779 1 0.31 0.26 0.00 100.00 - 0.00 0.00 0.00 0.00 0.00 0.00
8 8 helper 171 0.26 0.21 0.00 17100.00 - 0.02 0.00 0.00 0.00 0.00 0.00
5476 5476 sfcb-ProviderMa 10 0.21 0.17 0.00 1000.00 - 0.00 0.00 0.00 0.00 0.00 0.00
5196 5196 hpHelper.35688 1 0.09 0.08 0.00 100.00 - 0.00 0.00 0.00 0.00 0.00 0.00
955 955 vmsyslogd.33379 3 0.08 0.07 0.00 300.00 - 0.00 0.00 0.00 0.00 0.00 0.00
5516 5516 sfcb-ProviderMa 7 0.06 0.05 0.00 700.00 - 0.00 0.00 0.00 0.00 0.00 0.00
7506 7506 sfcb-ProviderMa 7 0.06 0.05 0.00 700.00 - 0.00 0.00 0.00 0.00 0.00 0.00
Hier vom anderen ESX:
Code: Alles auswählen
9:48:00pm up 597 days 11:13, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.08, 0.11, 0.13
PCPU USED(%): 12 2.5 8.7 0.3 0.1 4.5 2.9 7.5 1.5 0.0 2.5 75 1.4 44 80 0.0 2.5 2.1 2.2 1.3 3.3 2.6 1.5 2.0 6.1 0.2 1.3 58 0.0 2.7 3.9 0.0 AVG: 10
PCPU UTIL(%): 11 3.2 8.3 0.8 0.6 4.5 3.6 10 2.1 4.4 3.9 59 2.7 39 100 4.5 3.4 3.1 3.2 6.3 3.7 6.8 2.8 3.0 5.9 3.0 2.6 54 2.3 3.1 4.3 4.4 AVG: 11
CORE UTIL(%): 13 8.5 4.6 9.7 2.1 57 40 100 5.2 4.1 5.9 4.1 6.0 51 3.3 4.3 AVG: 20
ID GID NAME NWLD %USED %RUN %SYS %WAIT %VMWAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
1299098012 1299098012 esxtop.66599117 1 0.01 0.01 0.00 0.00 - 0.00 0.00 0.00 0.00 0.00 0.00
6822 6822 Exchange01 (Exc 10 0.01 0.01 0.00 0.11 0.00 0.00 0.04 0.00 0.00 0.00 0.00
2262 2262 hostd.34185 29 0.00 0.00 0.00 0.35 - 0.00 0.00 0.00 0.00 0.00 0.00
966758952 966758952 GRSVTE01 ( Term 22 0.00 0.00 0.00 0.26 0.00 0.00 0.19 0.00 0.00 0.00 0.00
491909484 491909484 GRSVSQ01 (SQL) 13 0.00 0.00 0.00 0.16 0.00 0.00 0.07 0.00 0.00 0.00 0.00
2 2 system 169 0.00 0.00 0.00 2.11 - 0.00 0.00 0.00 0.00 0.00 0.00
5475 5475 GRSVDC01 (Domai 7 0.00 0.00 0.00 0.08 0.00 0.00 0.02 0.00 0.00 0.00 0.00
966667108 966667108 GRSVFS01 (Files 8 0.00 0.00 0.00 0.10 0.00 0.00 0.02 0.00 0.00 0.00 0.00
1299061660 1299061660 TERM04 (Corel C 8 0.00 0.00 0.00 0.10 0.00 0.00 0.02 0.00 0.00 0.00 0.00
2132 2132 vmware-usbarbit 2 0.00 0.00 0.00 0.02 - 0.00 0.00 0.00 0.00 0.00 0.00
1299097847 1299097847 sshd.665925560 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
4610 4610 openwsmand.3538 3 0.00 0.00 0.00 0.04 - 0.00 0.00 0.00 0.00 0.00 0.00
2498 2498 rhttpproxy.3430 13 0.00 0.00 0.00 0.16 - 0.00 0.00 0.00 0.00 0.00 0.00
3611 3611 vpxa.34888 15 0.00 0.00 0.00 0.18 - 0.00 0.00 0.00 0.00 0.00 0.00
4520 4520 snmpd.35344 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
5000 5000 fdm.35592 20 0.00 0.00 0.00 0.24 - 0.00 0.00 0.00 0.00 0.00 0.00
9 9 drivers 13 0.00 0.00 0.00 0.16 - 0.00 0.00 0.00 0.00 0.00 0.00
8 8 helper 172 0.00 0.00 0.00 2.12 - 0.00 0.00 0.00 0.00 0.00 0.00
1 1 idle 32 0.00 0.53 0.00 0.00 - 3200.00 0.00 0.00 0.00 0.00 0.00
10 10 ft 5 0.00 0.00 0.00 0.06 - 0.00 0.00 0.00 0.00 0.00 0.00
11 11 vmotion 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
432 432 init.33140 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
953 953 vmsyslogd.33378 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
955 955 vmsyslogd.33379 3 0.00 0.00 0.00 0.04 - 0.00 0.00 0.00 0.00 0.00 0.00
969 969 sh.33388 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1016 1016 vobd.33411 18 0.00 0.00 0.00 0.22 - 0.00 0.00 0.00 0.00 0.00 0.00
1020 1020 sh.33430 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1064 1064 vmkeventd.33452 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1100 1100 busybox.33465 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1148 1148 vmkdevmgr.33519 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1282 1282 sh.33593 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1329 1329 net-lacp.33616 3 0.00 0.00 0.00 0.04 - 0.00 0.00 0.00 0.00 0.00 0.00
1519 1519 busybox.33818 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1913 1913 sh.34014 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
1960 1960 ntpd.34037 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
2085 2085 sh.34099 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0.00
2215 2215 sh.34162 1 0.00 0.00 0.00 0.01 - 0.00 0.00 0.00 0.00 0.00 0
Die Load-Average Zahlen sprechen doch dafür, dass den Servern langweilig ist - oder sehe ich das falsch?
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Du must dann im esxtop mal V druecken weil dann werden nur die VMs gelistet in der View.
Die Load sagt doch noch aus wieviele Prozesse warten muessen. Dein erster Host hat in der Tat kaum pCPU Last und der 2. aber 20%. Der eine Core ist sogar mit 100% am Anschlag. Guck dir da drunter die CPUs an und rechts aussen steht die Avg. Belastung.
Wenn die VM 4 vCPU hat und as GuestOS auf die 4 Kerne genau einen Prozess aufuehrt und somit 0.0001% last haben koenne so muss der ESXi dann in Summe gleichezeitig 4 Cores finden. Kann er die nicht finden so muss die komplette VM pausieren und bekommt keine Rechenzeit.
Der ESXi bemueht sich alle 4 Cores auf einer pCPU zu plazieren um NUMA aussen vorzulassen.
Dem ESX ist es egal ob du in in der VM Konfig 1x Sockel und 4 Cores oder 4x Sockel mit 1 Core gemacht hast. Ergibt am Ende immer 4.
Es hat etwas mit dem GuestOS und deren max. Sockel und evtl. zu lizensierender Software zutun.
Gruss
Joerg
Die Load sagt doch noch aus wieviele Prozesse warten muessen. Dein erster Host hat in der Tat kaum pCPU Last und der 2. aber 20%. Der eine Core ist sogar mit 100% am Anschlag. Guck dir da drunter die CPUs an und rechts aussen steht die Avg. Belastung.
Wenn die VM 4 vCPU hat und as GuestOS auf die 4 Kerne genau einen Prozess aufuehrt und somit 0.0001% last haben koenne so muss der ESXi dann in Summe gleichezeitig 4 Cores finden. Kann er die nicht finden so muss die komplette VM pausieren und bekommt keine Rechenzeit.
Der ESXi bemueht sich alle 4 Cores auf einer pCPU zu plazieren um NUMA aussen vorzulassen.
Dem ESX ist es egal ob du in in der VM Konfig 1x Sockel und 4 Cores oder 4x Sockel mit 1 Core gemacht hast. Ergibt am Ende immer 4.
Es hat etwas mit dem GuestOS und deren max. Sockel und evtl. zu lizensierender Software zutun.
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Mir fiel in den Ausgaben als erstes die Uptime von 597 Tagen auf...
Nicht, dass das an sich an Unmoeglichkeit grenzen wuerde, aber im Sinne einer nachvollziehbaren Analyse von Konfigurationsaenderungen koennte es sich als zielfuehrender erweisen, die beiden Hosts erst einmal zu rebooten, und dann erneut zu schauen...
Abgesehen von ganz offenbar waehrend der letzten knapp 2 Jahre nicht installierten Updates & Patches.
Nicht, dass das an sich an Unmoeglichkeit grenzen wuerde, aber im Sinne einer nachvollziehbaren Analyse von Konfigurationsaenderungen koennte es sich als zielfuehrender erweisen, die beiden Hosts erst einmal zu rebooten, und dann erneut zu schauen...
Abgesehen von ganz offenbar waehrend der letzten knapp 2 Jahre nicht installierten Updates & Patches.
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
JustMe hat geschrieben:Mir fiel in den Ausgaben als erstes die Uptime von 597 Tagen auf...
Das wollte ich auch schreiben. Immer wenn mir die Kollegen und Kunden von XXXXXX Tagen Uptime mit stolz geschwellter Brust berichten antworte ich... XXXXXX Tage keine Sicherheistsupdates eingespielt.
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Wir sind dran, den Support zu verlängern ... vor meiner Zeit
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Nochmal vielen Dank für eure Hilfe - hilft mir ungemein beim Verstehen
Ich habe nochmal ein paar esxtop Werte mit nur VMs.
Kann ich das eigentlich irgendwie langfristig aufzeichen bzw. wie bekomme ich einen Durchschnittwert von ready oder wait usw.?
Ich habe nochmal ein paar esxtop Werte mit nur VMs.
Kann ich das eigentlich irgendwie langfristig aufzeichen bzw. wie bekomme ich einen Durchschnittwert von ready oder wait usw.?
Code: Alles auswählen
1:33:44pm up 600 days 2:59, 688 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.76, 0.54, 0.53
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 6.20 0.00 6.20 0.00 0.11 0.00 0.30
6822 Exchange01 (Exc - 2 35.52 3.58 31.95 0.33 1.13 14.60 0.46
491909484 GRSVSQ01 (SQL) - 3 210.05 84.88 125.17 1.39 0.73 0.23 0.34
966667108 GRSVFS01 (Files - 2 19.55 1.67 17.88 0.03 0.15 0.39 0.37
966758952 GRSVTE01 ( Term - 1 88.21 70.57 17.64 5.48 0.57 6.93 0.54
1299061660 TERM04 (Corel C - 2 2.62 0.00 2.62 0.00 0.01 0.00 0.42
1:33:50pm up 600 days 2:59, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.76, 0.54, 0.53
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 4.77 0.24 4.53 0.00 0.11 9.32 0.36
6822 Exchange01 (Exc - 2 22.65 0.95 21.70 0.03 0.25 5.99 0.48
491909484 GRSVSQ01 (SQL) - 3 324.01 136.61 187.40 2.48 1.06 0.20 0.23
966667108 GRSVFS01 (Files - 2 12.87 1.43 11.44 0.02 0.08 0.20 0.24
966758952 GRSVTE01 ( Term - 1 95.37 82.73 12.64 3.89 0.21 5.90 0.39
1299061660 TERM04 (Corel C - 2 1.43 0.24 1.19 0.00 0.01 10.37 0.28
1:34:00pm up 600 days 2:59, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.75, 0.54, 0.53
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 4.05 0.95 3.10 0.01 0.06 4.80 0.29
6822 Exchange01 (Exc - 2 46.01 5.72 40.29 0.12 0.45 3.04 0.43
491909484 GRSVSQ01 (SQL) - 3 150.68 61.75 88.93 1.11 0.46 0.24 0.26
966667108 GRSVFS01 (Files - 2 9.30 0.48 8.82 0.01 0.07 0.22 0.28
966758952 GRSVTE01 ( Term - 1 324.96 317.10 7.87 16.45 0.17 5.12 0.53
1299061660 TERM04 (Corel C - 2 0.72 0.00 0.72 0.00 0.00 0.00 0.30
1:34:05pm up 600 days 2:59, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.58, 0.54, 0.53
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 4.05 0.00 4.05 0.00 0.09 0.00 0.33
6822 Exchange01 (Exc - 2 19.55 1.19 18.36 0.04 0.27 3.41 0.34
491909484 GRSVSQ01 (SQL) - 3 129.46 51.98 77.49 0.95 0.50 0.23 0.39
966667108 GRSVFS01 (Files - 2 18.36 1.67 16.69 0.03 0.13 0.33 0.31
966758952 GRSVTE01 ( Term - 1 164.51 154.02 10.49 46.04 0.11 15.40 0.57
1299061660 TERM04 (Corel C - 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
1:34:10pm up 600 days 2:59, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.56, 0.54, 0.53
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 10.01 0.48 9.54 0.01 0.15 5.35 0.36
6822 Exchange01 (Exc - 2 28.13 2.15 25.99 0.03 0.60 7.38 0.34
491909484 GRSVSQ01 (SQL) - 3 30.04 11.68 18.36 0.20 0.10 0.35 0.33
966667108 GRSVFS01 (Files - 2 12.87 2.38 10.49 0.04 0.08 0.18 0.23
966758952 GRSVTE01 ( Term - 1 233.89 190.50 43.39 39.41 1.44 10.52 3.22
1299061660 TERM04 (Corel C - 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00
1:34:51pm up 600 days 3:00, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.56, 0.57, 0.54
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 4.77 0.00 4.77 0.00 0.09 0.00 0.56
6822 Exchange01 (Exc - 2 13.83 1.43 12.40 0.02 0.20 5.91 0.37
491909484 GRSVSQ01 (SQL) - 3 156.88 61.04 95.84 2.34 2.20 1.58 0.57
966667108 GRSVFS01 (Files - 2 21.22 2.15 19.07 0.04 0.16 1.52 0.36
966758952 GRSVTE01 ( Term - 1 284.19 263.45 20.74 51.33 0.20 9.79 0.66
1299061660 TERM04 (Corel C - 2 1.91 0.24 1.67 0.00 0.01 9.04 0.41
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 3.22 0.12 3.10 0.01 0.05 4.94 0.34
6822 Exchange01 (Exc - 2 32.07 0.72 31.35 0.02 0.80 14.08 0.87
491909484 GRSVSQ01 (SQL) - 3 188.11 5.01 183.11 0.09 8.53 9.92 2.92
966667108 GRSVFS01 (Files - 2 5.72 0.72 5.01 0.01 0.03 0.16 0.25
966758952 GRSVTE01 ( Term - 1 116.59 109.67 6.91 15.44 0.06 9.39 0.60
1299061660 TERM04 (Corel C - 2 0.72 0.12 0.60 0.01 0.01 7.02 0.35
1:36:24pm up 600 days 3:02, 686 worlds, 6 VMs, 32 vCPUs; CPU load average: 0.70, 0.66, 0.56
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
5475 GRSVDC01 (Domai - 1 10.25 0.95 9.30 0.01 0.13 7.88 0.51
6822 Exchange01 (Exc - 2 36.24 2.62 33.62 0.09 0.77 11.09 0.48
491909484 GRSVSQ01 (SQL) - 3 16.21 5.96 10.25 0.11 0.08 0.40 0.26
966667108 GRSVFS01 (Files - 2 102.52 18.12 84.40 1.84 6.10 31.85 1.64
966758952 GRSVTE01 ( Term - 1 104.43 79.63 24.80 28.11 0.33 7.87 0.56
1299061660 TERM04 (Corel C - 2 1.43 0.24 1.19 0.00 0.01 97.28 0.26
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
"Langzeit" Statistiken sind ein Feature vom vCenter oder aber VeeamOne z.B. Wir haben dafuer vRealize Operations Manager.
Das esxtop kann im Batch mode laufen und zwecks Test die Werte aufzeichnen.
Einige der ReadLatency Werte sind aber sehr hoch bzw. extrem Hoch. Das Werte mal hoch sind bei sehr wenigen IOs ist durchaus "normal".
Bei 100ms fuer den TS ist es kein Wunder wenn sich User beschweren.
Gruss
Joerg
Das esxtop kann im Batch mode laufen und zwecks Test die Werte aufzeichnen.
Einige der ReadLatency Werte sind aber sehr hoch bzw. extrem Hoch. Das Werte mal hoch sind bei sehr wenigen IOs ist durchaus "normal".
Bei 100ms fuer den TS ist es kein Wunder wenn sich User beschweren.
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Ich stoße an meine Grenzen
Geht es also doch eher um die Server selbst als um die Storage? Ich finde im vCenter eben keine Langzeitstatistiken zu Ready, Co-Wait oder eben zu Werten aus esxtop...
Geht es also doch eher um die Server selbst als um die Storage? Ich finde im vCenter eben keine Langzeitstatistiken zu Ready, Co-Wait oder eben zu Werten aus esxtop...
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Monitor-> Performance-> Adv. -> Chartoptions. Da kannst du dann die Metriken auswaehlen. Aber wenn noch die Default Statistiklevel (1) gesetzt sind dann gibt Rueckwirkend nur die wichtigsten Metriken. Stell die Level 2 oder 3 ein und warte ein paar Tage ab.
Gruss
Joerg
Gruss
Joerg
-
- King of the Hill
- Beiträge: 12944
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
GID VMNAME VDEVNAME NVDISK CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s LAT/rd LAT/wr
6822 Exchange01 (Exc - 2 36.24 2.62 33.62 0.09 0.77 11.09 0.48
966667108 GRSVFS01 (Files - 2 102.52 18.12 84.40 1.84 6.10 31.85 1.64
1299061660 TERM04 (Corel C - 2 1.43 0.24 1.19 0.00 0.01 97.28 0.26
Also eine Readlatency von 97ms ist jenseits von Gut und Boese. Gleiches die 31 wobei die Read IOPS sehr gering sind.
Gruss
Joerg
Re: Performance Engpässe finden/Storage testen/I/O Analyzer
Vielen Dank Joerg für deine Erläuterungen!
Ich kann unter erweitert und Diagrammoptionen nur einen CPU-Ready Wert (neben Benutzung in MHZ und Prozent) auswählen, andere Statistiken, die in der Echtzeit noch sichtbar sind, (noch) nicht.
Aber ein durchschnittlicher CPU-Ready Wert der letzten Woche von 75secs spricht Bände, oder? Auf dem anderen ESXi sind es immerhin noch 24secs.
Mal ein paar vergleichende Angaben von CPU Ready Durschnittswerten der letzten Woche (von beiden ESXi gemischt):
TK-Anlage/PBX: 3,6secs (2vCPU)
Exchange: 3,8 (4vCPU)
Monitoring: 1,4 (4vCPU)
Anwendung 1: 1 (2vCPU)
Cert-Srv: 0,8sec (2vCPU)
DC: 1,4 (2vCPU)
FS: 1,7 (2vCPU)
Lizenz-Srv: 0,5 (habe ich testweise von 2 vCPU auf 1 reduziert)
Print: 2,4 (4vCPU)
SQL: 12,5 (6vCPU)
Terminalserver: 53,4 (16vCPU)
D.h. schlechte vCPU Konfiguration, oder? Der TS und der SQL sollten auf verschiedene physische Server und auch die Kerne reduziert werden. Ein Neustart schadet sowieso nicht und ich überlege, ob wir nicht einen Server neu einplanen sollten, der mehr MHZ pro Kern liefert und insgesamt auch mehr Kerne hat. Also was die obigen Werte betrifft, ist die Storage als Performance-Engpass eher raus, oder? (Die ist voll und muss eher daher getauscht werden).
Ich kann unter erweitert und Diagrammoptionen nur einen CPU-Ready Wert (neben Benutzung in MHZ und Prozent) auswählen, andere Statistiken, die in der Echtzeit noch sichtbar sind, (noch) nicht.
Aber ein durchschnittlicher CPU-Ready Wert der letzten Woche von 75secs spricht Bände, oder? Auf dem anderen ESXi sind es immerhin noch 24secs.
Mal ein paar vergleichende Angaben von CPU Ready Durschnittswerten der letzten Woche (von beiden ESXi gemischt):
TK-Anlage/PBX: 3,6secs (2vCPU)
Exchange: 3,8 (4vCPU)
Monitoring: 1,4 (4vCPU)
Anwendung 1: 1 (2vCPU)
Cert-Srv: 0,8sec (2vCPU)
DC: 1,4 (2vCPU)
FS: 1,7 (2vCPU)
Lizenz-Srv: 0,5 (habe ich testweise von 2 vCPU auf 1 reduziert)
Print: 2,4 (4vCPU)
SQL: 12,5 (6vCPU)
Terminalserver: 53,4 (16vCPU)
D.h. schlechte vCPU Konfiguration, oder? Der TS und der SQL sollten auf verschiedene physische Server und auch die Kerne reduziert werden. Ein Neustart schadet sowieso nicht und ich überlege, ob wir nicht einen Server neu einplanen sollten, der mehr MHZ pro Kern liefert und insgesamt auch mehr Kerne hat. Also was die obigen Werte betrifft, ist die Storage als Performance-Engpass eher raus, oder? (Die ist voll und muss eher daher getauscht werden).
Zurück zu „vSphere 5.5 / ESXi 5.5“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste