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!
"Virtuelle Maschine neu konfigurieren" dauert sehr
"Virtuelle Maschine neu konfigurieren" dauert sehr
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)
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
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
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
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
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
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
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
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
Erstmal Danke für die prompte Rückmeldung.
Gerade gemacht, => nur 1 GB.
Nein, nichts bekannt.
Auch gerade geprüft, die Transactionlogs sind nur 100 MB, also auch i.O.
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.
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
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
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:
-
- King of the Hill
- Beiträge: 12949
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
dacal hat geschrieben:..
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
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).
- Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
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
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.
Zurück zu „vCenter / VMware VirtualCenter“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste