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!
Vsphere Client 5.5 und Probleme mit der Systemauslastung
Vsphere Client 5.5 und Probleme mit der Systemauslastung
Hallo zusammen,
wir haben folgende Serverumgebung:
HP Pro Liant DL 380 P GEN 8 V2 Rack
4 Virtuelle Maschinen:
SBSSRV2008
SQLSRV2008
TS1SRV (Terminalserver)
TS2SRV (Terminalserver)
VCenter
Bestehende Hardwareserver wurden übernommen und virtualisiert
Die Terminalserver hatten vorher keine klare Zuordnung der User. Es konnte also sein das sich alle auf TS1 und keiner auf TS2 angemeldet hat.Dies wurde auf eine feste Verteilung der User auf TS1SRV und TS2SRV umgestellt
Problematik:
- Festplattenspeicher der Systempartition C: auf dem SBSSRV geht auf unter 1 GB
- Arbeitspeicherauslastung (16GB) geht auf 100 %. Dabei sind 75% im Cache und parallel zur Verminderung des Festplattenspeichers geht der freie Speicher auf 0
Prozessorauslastung liegt zw. 80 % und 100 %
Chronologie eines Tages:
10:15 Uhr:
Arbeitsspeicher SBSSRV (16GB): 10,7 GB im Cache
Frei: 1,7 GB
Festplattenspeicherplatz: 5,78 GB
Prozessorauslastung: 69%
11:20 Uhr:
Arbeitsspeicher SBSSRV (16GB): 13,7 GB im Cache
Frei: 0 GB
Festplattenspeicherplatz: 1,7GB GB
Prozessorauslastung: 80%
12:00 Uhr:
Arbeitsspeicher SBSSRV (16GB): 13,8 GB im Cache
Frei: 0 GB
Festplattenspeicherplatz: 0,98 GB
Prozessorauslastung: 95%
12:25 Uhr
Arbeitsspeicher SBSSRV (16GB): 3,97 GB im Cache
Frei: 9,9 GB
Festplattenspeicherplatz: 6,98 GB
Prozessorauslastung: 100%
13:00 Uhr
Arbeitsspeicher SBSSRV (16GB): 5.8 GB im Cache
Frei: 5.8 GB
Festplattenspeicherplatz: 10,7 GB
Prozessorauslastung: 20%
16.09.2014 12:36 Uhr im VCenter
Arbeitsspeicher verwendet: 7GB 42%
13:00 Uhr im VCenter
Arbeitsspeicher verwendet: 7GB 42%
Bereits getätigte Lösungsansätze:
Arbeitsspeicher auf dem SBSSRV von 32GB auf 24GB reduziert ( Speicherverteilung in VCenter manuell)
Arbeitsspeicher auf dem SBSSRV von 24GB auf 16GB reduziert
Schattenkopien auf dem SBSSRV deaktiviert und Server neugestartet
TS1SRV und TS2SRV neugestartet
Evtl. spielt auch die Software Multicash ein Rolle. Zeitlich ist der Zugriff der User über den Terminalserver auf Multicash in etwa identisch bezogen auf die Performenceeinbrüche.
Bis etwa 10:00 Uhr läuft alles sehr gut. Dann haben sich bis zu 20 User auf den Terminalserver und im Multicash eingelogged und die Performence geht runter. Ab 12:30 geht das Performenceproblem dann wieder zurück. Der Festplattenspeicher(10,7GB) und der Arbeitsspeicherplatz (5,8GB) wird wieder größer. Zu der Zeit gehen einige User in die Pause und kommen dann um 13:30 Uhr wieder.
Dann gehen die Performenceeinbrüche wieder los.
Hat der eine oder andere evtl. eine Idee woran es noch liegen könnte?
Confused
Viele Grüße
wir haben folgende Serverumgebung:
HP Pro Liant DL 380 P GEN 8 V2 Rack
4 Virtuelle Maschinen:
SBSSRV2008
SQLSRV2008
TS1SRV (Terminalserver)
TS2SRV (Terminalserver)
VCenter
Bestehende Hardwareserver wurden übernommen und virtualisiert
Die Terminalserver hatten vorher keine klare Zuordnung der User. Es konnte also sein das sich alle auf TS1 und keiner auf TS2 angemeldet hat.Dies wurde auf eine feste Verteilung der User auf TS1SRV und TS2SRV umgestellt
Problematik:
- Festplattenspeicher der Systempartition C: auf dem SBSSRV geht auf unter 1 GB
- Arbeitspeicherauslastung (16GB) geht auf 100 %. Dabei sind 75% im Cache und parallel zur Verminderung des Festplattenspeichers geht der freie Speicher auf 0
Prozessorauslastung liegt zw. 80 % und 100 %
Chronologie eines Tages:
10:15 Uhr:
Arbeitsspeicher SBSSRV (16GB): 10,7 GB im Cache
Frei: 1,7 GB
Festplattenspeicherplatz: 5,78 GB
Prozessorauslastung: 69%
11:20 Uhr:
Arbeitsspeicher SBSSRV (16GB): 13,7 GB im Cache
Frei: 0 GB
Festplattenspeicherplatz: 1,7GB GB
Prozessorauslastung: 80%
12:00 Uhr:
Arbeitsspeicher SBSSRV (16GB): 13,8 GB im Cache
Frei: 0 GB
Festplattenspeicherplatz: 0,98 GB
Prozessorauslastung: 95%
12:25 Uhr
Arbeitsspeicher SBSSRV (16GB): 3,97 GB im Cache
Frei: 9,9 GB
Festplattenspeicherplatz: 6,98 GB
Prozessorauslastung: 100%
13:00 Uhr
Arbeitsspeicher SBSSRV (16GB): 5.8 GB im Cache
Frei: 5.8 GB
Festplattenspeicherplatz: 10,7 GB
Prozessorauslastung: 20%
16.09.2014 12:36 Uhr im VCenter
Arbeitsspeicher verwendet: 7GB 42%
13:00 Uhr im VCenter
Arbeitsspeicher verwendet: 7GB 42%
Bereits getätigte Lösungsansätze:
Arbeitsspeicher auf dem SBSSRV von 32GB auf 24GB reduziert ( Speicherverteilung in VCenter manuell)
Arbeitsspeicher auf dem SBSSRV von 24GB auf 16GB reduziert
Schattenkopien auf dem SBSSRV deaktiviert und Server neugestartet
TS1SRV und TS2SRV neugestartet
Evtl. spielt auch die Software Multicash ein Rolle. Zeitlich ist der Zugriff der User über den Terminalserver auf Multicash in etwa identisch bezogen auf die Performenceeinbrüche.
Bis etwa 10:00 Uhr läuft alles sehr gut. Dann haben sich bis zu 20 User auf den Terminalserver und im Multicash eingelogged und die Performence geht runter. Ab 12:30 geht das Performenceproblem dann wieder zurück. Der Festplattenspeicher(10,7GB) und der Arbeitsspeicherplatz (5,8GB) wird wieder größer. Zu der Zeit gehen einige User in die Pause und kommen dann um 13:30 Uhr wieder.
Dann gehen die Performenceeinbrüche wieder los.
Hat der eine oder andere evtl. eine Idee woran es noch liegen könnte?
Confused
Viele Grüße
1. Als erstes würde erst mal das Systemdrive C: um so ca. 20GB vergrößern. Geht ja seit 2008 Server online.
2. Lässt sich nicht sehen, woher der mehrverbrauch an HDD Platz kommt?
3. Welche CPU hat den der Server? oder Sind das mehrere?
Und welche vcpu haben die VM's?
Läuft um die Zeit ein Backup oder eine Datensicherung? Schreibt das Multicash ggf logfiles auf C: beim User anmelden?
Wenn sich das so zeitlich zuordnen lääst, bekommt vielleicht der SBS zu wenig Leistung ab, weil die TS den Server in die Knie zwingen?!
Läuft da ggf ein Virenscanner Amok?
ggf mal mit sysinternals Process Explorer evaluieren, was genau auf dem Server passiert, wenn sich ein User in dem Mulitcash einloggt..
2. Lässt sich nicht sehen, woher der mehrverbrauch an HDD Platz kommt?
3. Welche CPU hat den der Server? oder Sind das mehrere?
Und welche vcpu haben die VM's?
Läuft um die Zeit ein Backup oder eine Datensicherung? Schreibt das Multicash ggf logfiles auf C: beim User anmelden?
Wenn sich das so zeitlich zuordnen lääst, bekommt vielleicht der SBS zu wenig Leistung ab, weil die TS den Server in die Knie zwingen?!
Läuft da ggf ein Virenscanner Amok?
ggf mal mit sysinternals Process Explorer evaluieren, was genau auf dem Server passiert, wenn sich ein User in dem Mulitcash einloggt..
Du hast hier wahrscheinlich mehr als einen zugrunde liegenden Effekt.
Wenn der freie Speicherplatz auf C: reversibel voll läuft, ist die wahrscheinlichste Ursache ein Prozess der zeitweilig Unmengen RAM frisst und die Auslagerungsdatei aufpustet oder ein Prozess, der den Platz selbst voll schreibt. Einfach auf der VM den Ressourcenmonitor mitlaufen lassen und schauen, was da los ist.
Die Performanceeinbrüche können mit der Konkurrenz um die physischen Kerne zusammenhängen. Wie Supi schon schrieb:
- wie viele Prozessoren/Kerne (ohne HT!) hat der Host?
- wie viele vCPU/vCores haben die VMs?
Wenn der freie Speicherplatz auf C: reversibel voll läuft, ist die wahrscheinlichste Ursache ein Prozess der zeitweilig Unmengen RAM frisst und die Auslagerungsdatei aufpustet oder ein Prozess, der den Platz selbst voll schreibt. Einfach auf der VM den Ressourcenmonitor mitlaufen lassen und schauen, was da los ist.
Die Performanceeinbrüche können mit der Konkurrenz um die physischen Kerne zusammenhängen. Wie Supi schon schrieb:
- wie viele Prozessoren/Kerne (ohne HT!) hat der Host?
- wie viele vCPU/vCores haben die VMs?
Re: Vsphere Client 5.5 und Probleme mit der Systemauslastung
Grando hat geschrieben:
Evtl. spielt auch die Software Multicash ein Rolle. Zeitlich ist der Zugriff der User über den Terminalserver auf Multicash in etwa identisch bezogen auf die Performenceeinbrüche.
Bis etwa 10:00 Uhr läuft alles sehr gut. Dann haben sich bis zu 20 User auf den Terminalserver und im Multicash eingelogged und die Performence geht runter. Ab 12:30 geht das Performenceproblem dann wieder zurück. Der Festplattenspeicher(10,7GB) und der Arbeitsspeicherplatz (5,8GB) wird wieder größer. Zu der Zeit gehen einige User in die Pause und kommen dann um 13:30 Uhr wieder.
Dann gehen die Performenceeinbrüche wieder los.
Hat der eine oder andere evtl. eine Idee woran es noch liegen könnte?
Confused
Viele Grüße
Wir kennen ähnliche Effekte wenn Java-Anwendungen Logfiles versehentlich im Debug-Modus schreiben.
Gruss
~thc hat geschrieben:- wie viele Prozessoren/Kerne (ohne HT!) hat der Host?
- wie viele vCPU/vCores haben die VMs?
Wir haben Hardwareseitig zwei Prozessoren mit jeweils 8 Kernen.
Die VM´s haben die folgende Anzahl an Kernen zugeordnet:
SBS08 8 Kerne
SQL 16 Kerne
TS1 16 Kerne
TS2 16 Kerne
VCenter 6 Kerne
Also, ich kann wohl leider ausschliessen das Multicash das Problem darstellt, denn wir testen seit heute morgen die Umgebung ohne die Nutzung von Multicash durch die User.
In den Prozessen selber finden man keinen aufälligen Prozess der ein Hinweis sein könnte, dass der Speicher zuläuft.
Kann es denn evtl. auch mit der Virtualisierung der Hardwareserver zu tun haben?
Grando hat geschrieben:~thc hat geschrieben:- wie viele Prozessoren/Kerne (ohne HT!) hat der Host?
- wie viele vCPU/vCores haben die VMs?
Wir haben Hardwareseitig zwei Prozessoren mit jeweils 8 Kernen.
Die VM´s haben die folgende Anzahl an Kernen zugeordnet:
SBS08 8 Kerne
SQL 16 Kerne
TS1 16 Kerne
TS2 16 Kerne
VCenter 6 Kerne
Also, ich kann wohl leider ausschliessen das Multicash das Problem darstellt, denn wir testen seit heute morgen die Umgebung ohne die Nutzung von Multicash durch die User.
In den Prozessen selber finden man keinen aufälligen Prozess der ein Hinweis sein könnte, dass der Speicher zuläuft.
Kann es denn evtl. auch mit der Virtualisierung der Hardwareserver zu tun haben?
http://technet.microsoft.com/en-US/sysinternals
Da findest du diverse Tools die ggf. bei der Analyse innerhalb des Gastes helfen.
Wie habt ihr das System virtualisiert?
Gruss
Grando hat geschrieben:~thc hat geschrieben:- wie viele Prozessoren/Kerne (ohne HT!) hat der Host?
- wie viele vCPU/vCores haben die VMs?
Wir haben Hardwareseitig zwei Prozessoren mit jeweils 8 Kernen.
Die VM´s haben die folgende Anzahl an Kernen zugeordnet:
SBS08 8 Kerne
SQL 16 Kerne
TS1 16 Kerne
TS2 16 Kerne
VCenter 6 Kerne
Also auf 16 Kerne (32 Logische CPUs mit HT) kommen bei euch 62 vCPUs. Und da wunderst du dich? Schau dir mal %RDY und Werte für Co-Stop an. Wenn ein SQL oder einer der Terminalserver rechnen will, dann kann der Scheduler keine andere VM einplanen, die müssen dann warten. Resourcenvergabe immer nach der Fausregel "So viel wie nötig, so wenig wie möglich".
bla!zilla hat geschrieben:...
Also auf 16 Kerne (32 Logische CPUs mit HT) kommen bei euch 62 vCPUs. Und da wunderst du dich?.
...
Das Verhältnis haben wir auf einem Host auch. Allerdings sind es nur 1 und 2 Core Maschinen, die auf dem Host laufen. Und die laufen butterwich durch. Der Host hat im Schnitt 30% CPU Auslastung und Peaks von 60%
Laufen die 16 Kerner wirklich oft auf 100%?
Ich würde mich das nicht trauen, auf einem 16 Kern Host neben einer 16 Kern VM noch mehr laufen zu lassen...
@stahly
Wenn die CPU nur 1-2vcpu hat, ist das sicher noch keine Problem.
http://www.gabesvirtualworld.com/how-to ... rformance/
Wenn die CPU nur 1-2vcpu hat, ist das sicher noch keine Problem.
http://www.gabesvirtualworld.com/how-to ... rformance/
Supi hat geschrieben:@stahly
Wenn die CPU nur 1-2vcpu hat, ist das sicher noch keine Problem.
http://www.gabesvirtualworld.com/how-to ... rformance/
Ich denke auch
Könnte es evtl. auch mit dem fest zugewiesenen Speicher für die einzelnen VM´s im VCenter zu tun haben? Leider ist die Person die den Server aufgesetzt hat verhindert und wir fischen ein wenig im trüben :-/
Grando hat geschrieben:
Könnte es evtl. auch mit dem fest zugewiesenen Speicher für die einzelnen VM´s im VCenter zu tun haben? Leider ist die Person die den Server aufgesetzt hat verhindert und wir fischen ein wenig im trüben :-/
Wenn du Reservierungen meinst, dann ja.
Poste doch mal genau, welche HW du hast. Und wieviele User auf dem TS arbeiten.
Aslo CPU Typ. Installierter Ram, auf welchem Storage liegen die VM's. (Local oder SAN)
Dann die VM's. Also VM1 z.b. 4cpu und 16GB ram... usw.
Ebenso in den VM schauen, welche Reservierungen ihr da habt. ( VM Rechtsklick, Eigenschaften, Ressourcen) Hier sollte nur im Bedarfsfall was definiert sein)
Quick and Dirty würde ich wie folgt ändern:
TS1/2 und SQL auf wenigstens 8 Kerne runter (den SQL ggf auch auf 4), Vcenter auf 4 Kerne.
Dann damit mal testen.
Alternativ gibts vielleicht den ein oder anderen hier im Forum, der das Remote per Teamviewer als Kleinauftrag anschauen kann, wenn ihr da keine richtige Ahnung habt.
Zurück zu „vSphere 5.5 / ESXi 5.5“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste