"Virtuelle Maschine neu konfigurieren" dauert sehr

[dacal]

Hallo Zusammen,

zunächst allgemein:
- 8x ESX 4.1 Hosts
- VMWare vSphere 4.1.0 (auf Server 2008 x64, 8 GB RAM)
- alle aktuellen Patches
- RAM-Auslastung max. 70 % über das ganze Cluster
- CPU-Auslastung max. 40 % über das ganze Cluster
- 92 VMs (incl. Templates)
- VMWare Tools nicht überall aktuell
- keine festen Reservierungen
- SQL Standard läuf lokal auf dem vCenter-Server

Von Zeit zur Zeit dauert es bis zu 5-6 Minuten bis folgende Vorgänge abgeschlossen sind:

- Virtuelle Maschine neu konfigurieren
- Einschalten virtueller Maschinen

Reboot des vCenter Server ändert nichts an der Tatsache.
Das Problem tritt bei allen virtuellen Servern auf.

Aktuell dauert es ca. 1,5 Min, was allerdings auch nicht normal ist.
(im Normalfall dauert es max. 20s)

[Tschoergez]

Hi!
Wie "groß" ist denn der vCenter-Server?
(Ich tippe mal auf performance-probleme mit dem vCenter bzw. dessen Datenbank)
Funktioniert die Namensauflösung vorwärts und rückwärts?
Irgendwelche Auffälligkeiten in den Logs vom vCenter?

Wie lange dauerts, wenn Du Dich direkt mit einem ESX verbindest und dort eine VM testhalber umkonfigurierst?

Viele Grüße,
Jörg

[dacal]

Wie "groß" ist denn der vCenter-Server?
(Ich tippe mal auf performance-probleme mit dem vCenter bzw. dessen Datenbank)

Groß im Sinne von RAM: 8 GB, belegt sind zwischen 5 und 7.
9,5 GB Datenbank.
Ich werde jetzt mal ein Cleanup-Script laufen lassen.

Funktioniert die Namensauflösung vorwärts und rückwärts?
Irgendwelche Auffälligkeiten in den Logs vom vCenter?

Ja, ohne Probleme.
Nein, keine Auffälligkeiten.

Wie lange dauerts, wenn Du Dich direkt mit einem ESX verbindest und dort eine VM testhalber umkonfigurierst?

Gerade getestet, 2 Sekunden.

[Tschoergez]

ok, 9.5GB Datenbank sind schon was bei 100VMs.
Hast Du das mal verglichen mit dem Datanbank-Kalkulator von VMware (im vSphere Client unter Administration/Server Settings/Database)?
Wie viele CPUs hat das vCenter? (zwei sind gut, v.a. wenn die Datenbank lokal läuft)

Irgendwelche Performanceprobleme sonst im Cluster?

Irgendwelche Auffälligkeiten in den Datenbank-Logs (Transaction-Logs, die überlaufen...)
Das vCenter führt normalerweise auch automatisch skripte aus, um die Performancedaten zu aggregieren, was manchmal probleme macht (und auf jeden Fall Leistung kostet).

Läuft Dein vCenter physikalisch oder virtuell?
Wenn virtuell, gibts Probleme mit dem ESX darunter?

Und: HAst Du nen Supportvertrag? Dann mach doch mal einen Call bei VMware auf...

Viele Grüße,
Jörg

[dacal]

Erstmal Danke für die prompte Rückmeldung.

Hast Du das mal verglichen mit dem Datanbank-Kalkulator von VMware (im vSphere Client unter Administration/Server Settings/Database)?

Gerade gemacht, => nur 1 GB.

Irgendwelche Performanceprobleme sonst im Cluster?

Nein, nichts bekannt.

Irgendwelche Auffälligkeiten in den Datenbank-Logs (Transaction-Logs, die überlaufen...)

Auch gerade geprüft, die Transactionlogs sind nur 100 MB, also auch i.O.

Wie viele CPUs hat das vCenter? (zwei sind gut, v.a. wenn die Datenbank lokal läuft)

Läuft Dein vCenter physikalisch oder virtuell?
Wenn virtuell, gibts Probleme mit dem ESX darunter?

Das ganze Cluster hat 76 Cores. (Hyperthreading nicht eingerechnet).
vCenter läuft auch auf einer VM.
Zugeteilt sind sogar 4 CPUs.


Ich habe nun das DB-Script laufen lassen (120 Tage),
leider nur wenige MB gebracht.

Vertrag haben wir natürlich (über Dell),
allerdings wollte ich erstmal so schauen, da es doch immer relativ lange dauert über Dell einen Call zu eröffnen.

[Tschoergez]

hm, wie ist denn die CPU-Auslastung des vCenters während der Wartezeit?
Wie viele Cores hat der ESX, auf dem die vCenter-VM läuft?
(4 vCPU sind nicht immer besser als 2... )

[dacal]

hm, wie ist denn die CPU-Auslastung des vCenters während der Wartezeit?

Kleine Spitzen beim CPU Load, allerdings zu vernachlässigen.

Wie viele Cores hat der ESX, auf dem die vCenter-VM läuft?

8 Cores.

Was mir nun aufgefallen ist, ich habe nun die Retention auf 90 Tage geändert.
(anstatt 120 Tage). Nun läuft das Script schon seit ca. 1,5 Stunden und hat schon über
760.000 Datensätze gelöscht. Vermutlich scheint in der Datenbank irgendwie noch einiges an "Ballast" zu sein (evtl. vom Upgrade von 3.5 auf 4.X).

Sobald das Script fertig ist, verkleiner ich die DB und melde mich wieder.

PS:
Falls es jemanden etwas sagt, fast alle gelöschten Datensätze liegen in der
Tabelle VPX_HIST_STAT1.

edit.

Gerade ist mir aufgefallen, dass scheinbar nur eine CPU wirklich genutzt wird.
Die CPU-Last (der sqlservr.exe) bleibt bei konstant 25%.

Die Einstellung im SQL Server sind allerdings so:

[irix]

..
PS:
Falls es jemanden etwas sagt, fast alle gelöschten Datensätze liegen in der
Tabelle VPX_HIST_STAT1.

Da kommen Erinnerungen hoch! Bei uns hat die Verarbeitungen der Statistikdaten irgendwann seinen Dienst eingestellt und die Tabelle ist dann auf 60.000.000 Eintraege angewachsen. Damals war der Support nicht in der Lage die Verarbeitung wieder in Gang zusetzten wenn eine SQL Express verwendet wird.

Eigentlich muestest du das aber merken wenn du die mal Performancedaten anschauen willst die ein paar Tage/Wochen in der Vergangenheit liegen.

Da du aber SQL Standard hast nehme ich ja das die Jobs einfach nicht mehr laufen oder fehlen.

Gruss
Joerg

[dacal]

Also nochmal als Update,
Das Script läuft jetzt schon 2:45 Stunden.

[irix]

Also nochmal als Update,
Das Script läuft jetzt schon 2:45 Stunden.

Ich hatte nach 1 1/2 Tagen dann ein "truncate <table>" gemacht . Allerdings muesste ich nachgucken in welcher der 4-5 HIST Tables sich die Eingangswerte gestapelt hatten.

Gruss
Joerg

[dacal]

Ich hatte nach 1 1/2 Tagen dann ein "truncate <table>" gemacht

Das mach ja Hoffnung
Naja, abwarten und Kaffee trinken

Sobald es durch ist, melde ich mich wieder.
Aber soweit erstmal Danke!

edit:

Ok, Tag 2 und neue Erkenntnisse.

Gestern Nachmittag ist uns aufgefallen, dass einer unserer DNS-Server Probleme bereitet. Dieser ist auch als primärer DNS auf den ESX Hosts eingetragen.
Auf dem vCenter Server ist er allerdings als sekundärer Server eingetragen
(weshalb ich auch oben geschrieben habe, dass die DNS Auslösung funktioniert).

Nachdem der DNS wieder zur Verfügung stand, funktonierten die Aktionen wieder wie gewohnt in 2-3 Sekunden.

Allerdings ist es trotz allem etwas seltsam.
Sollte nicht eigentlich dann der sekundäre DNS benutzt werden?
(ist das Timeout so lange?).

Aber trotz allem, zum Thema DB.
Das DB-Cleanup Script bricht irgendwann ab.
"Transaction (Process ID 85) was deadlocked on lock resources with another process ..."
Ich vermute die vCenter Dienste sollten gestoppt sein?

Oder kann ich das ganze Table droppen?
(die Performancedaten wird nicht unbedingt benötigt, also ein nice to have).

[dacal]

siehe Edit

[Tschoergez]

Nachdem der DNS wieder zur Verfügung stand, funktonierten die Aktionen wieder wie gewohnt in 2-3 Sekunden.

!Treffer!

Fein wenn's wieder funktioniert!
Zu dem Problem mit den SQL-Skripten: Einfach per SQL die Table leeren würde ich nicht machen. Es ist nirgends dokumentiert, ob nicht doch irgendwo anders noch referenzen drauf sind.
Wenn möglich, probiers doch mal mit gestopptem vCenter (ein Backup der Datenbank hat man ja hoffentlich ).


Viele Grüße,
Jörg

[dacal]

Ok, die vCenter Dienste sind gestoppt.
Das Script läuft. Mal sehen ob es diesmal klappt.

[irix]

Ok, die vCenter Dienste sind gestoppt.
Das Script läuft. Mal sehen ob es diesmal klappt.

Denkdran vorher den Sicherungsmodus auf "Einfach" zustellen ansonsten explodiert je nach Umfang dein Transaktionslog.

Gruss
Joerg

[dacal]

Denkdran vorher den Sicherungsmodus auf "Einfach" zustellen ansonsten explodiert je nach Umfang dein Transaktionslog.

Danke für den Hinweis, war aber schon so eingestellt.

Das Script ist jetzt durch.
Ohne Fehler.

Gebracht hat es leider nur 325 MB.

Gerade musst ich mit Erschrecken feststellen, dass die
32-Bit Version von SQL Server 2005 installiert ist.