Bei uns tritt es immer wieder mal auf, dass man Dutzende Male den Browser aktualisieren muss, bis endlich der Login für den VMware Server erscheint. Dabei steht im Tab nur drin "Loading..." aber es tut sich nichts mehr.
Strg+F5 oft (heute morgen sicher so 20-30 mal) gedrückt, bringt dann irgendwann das Fenster mit dem Login-Bildschirm. Dann kann man sich einloggen und so arbeiten, als wär nichts gewesen.
Host-System:
Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (2x 4 Kerne)
32 GB RAM
2x 750 GB Samsung HDDs in Software-Raid
OS: Debian Lenny (2.6.26-2-amd64)
VMware-Server 2.0.1 (VMware-server-2.0.1-156745.x86_64)
Getestet mit aktuellem Firefox und Internet Explorer 7
Ein ähnliches, aber ungleich weniger gravierendes Problem, haben wir mit all unseren VMware Servern immer wieder mal. Da reicht es aber, 1-3 mal zu aktualisieren, dann hat man den Login und es ist auch deutlich seltener als bei dem genannten Host. Ich vermute mal, die 20-25 darauf laufenden Maschinen könnten zu dem Problem beitragen (ist unser Testserver für die Entwickler).
Gibts denn vielleicht eine Art Timeout für das Interface, das man hochdrehen kann, damit der Tomcat länger wartet und es doch noch lädt oder sowas in der Richtung?
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!
Web Interface hängt (Loading...)
-
Dayworker
- King of the Hill
- Beiträge: 13651
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Ihr seid mit euren 20-25 VMs schon fast am oberen Ende der von VMware max empfohlenen Anzahl an VMs pro Kern (4VMs pro Kern). Von daher sind die langen Ladezeiten für mich völlig normal, besonders wenn alle VMs im Round-Robin-Verfahren über alle CPU-Kerne zirkulieren.
Am Tomcat hab ich über sein Konfig-Prog leider keine Möglichkeit für eine Zeit-Verlängerung gefunden, aber ich schätze mal über seine conf-Datei(en) gehts dann doch irgendwie. Der Restart des Web-Access wird bei deiner VM-Last wohl nicht sehr viel bringen.
Du könntest die Lage etwas entspannen bzw die Antwortzeiten des Web-Access minimieren, wenn du eine HDD, einen Kern und 1GB RAM nur für den Host reservierst und die VMs dann möglichst gleichmäßig über weiter Spindeln/HDDs im Datastore verteilst. Ansonsten läßt sich möglicherweise noch viel über einige Änderungen (Stichwort "swappiness" in der Forensuche) an config.ini/*.vmx erreichen.
Am Tomcat hab ich über sein Konfig-Prog leider keine Möglichkeit für eine Zeit-Verlängerung gefunden, aber ich schätze mal über seine conf-Datei(en) gehts dann doch irgendwie. Der Restart des Web-Access wird bei deiner VM-Last wohl nicht sehr viel bringen.
Du könntest die Lage etwas entspannen bzw die Antwortzeiten des Web-Access minimieren, wenn du eine HDD, einen Kern und 1GB RAM nur für den Host reservierst und die VMs dann möglichst gleichmäßig über weiter Spindeln/HDDs im Datastore verteilst. Ansonsten läßt sich möglicherweise noch viel über einige Änderungen (Stichwort "swappiness" in der Forensuche) an config.ini/*.vmx erreichen.
irix, VI Client hab ich kürzlich mal getestet. Damit konnte ich aber VMs nur starten und stoppen, aber nicht konfigurieren, gab immer eine Fehlermeldung bzgl. Hardware-Version (egal ob 4er oder 7er), daher gleich wieder verworfen.
Neustarten des Web Access bringt tatsächlich wenig, japp *g*
Diverse Optimierungen haben wir schon durchgeführt:
vm.swappiness = 0
in der config:
MemAllowAutoScaleDown = "false"
MemTrimRate=0
mainMem.partialLazyRestore = "FALSE"
mainMem.partialLazySave = "FALSE"
prefvmx.minVmMemPct = "100"
Das Reservieren wäre noch eine Idee, müssten wir zwar noch eine kleine HDD einbauen, weil für nen Linux-OS 750 GB reservieren halte ich für etwas übertrieben, aber daran sollte es (hoffentlich) nicht scheitern.
Kern und RAM reservieren mach ich am leichtesten wie?
Der weil such ich mal nach den conf-Dateien des Tomcats.
Neustarten des Web Access bringt tatsächlich wenig, japp *g*
Diverse Optimierungen haben wir schon durchgeführt:
vm.swappiness = 0
in der config:
MemAllowAutoScaleDown = "false"
MemTrimRate=0
mainMem.partialLazyRestore = "FALSE"
mainMem.partialLazySave = "FALSE"
prefvmx.minVmMemPct = "100"
Das Reservieren wäre noch eine Idee, müssten wir zwar noch eine kleine HDD einbauen, weil für nen Linux-OS 750 GB reservieren halte ich für etwas übertrieben, aber daran sollte es (hoffentlich) nicht scheitern.
Kern und RAM reservieren mach ich am leichtesten wie?
Der weil such ich mal nach den conf-Dateien des Tomcats.
Falls es auch mal wer sucht:
/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/conf
Da liegen die conf-Dateien des Tomcats für VMware
Die Timeouts stehen auf 20 Sekunden. Da das Laden nach 1-2 Sekunden beendet ist, dürfte das nicht das Problem sein, auch wenn der Default sonst 60 Sekunden ist. Also hilft wohl nur reservieren oder die Menge an VMs reduzieren.
/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/conf
Da liegen die conf-Dateien des Tomcats für VMware
Die Timeouts stehen auf 20 Sekunden. Da das Laden nach 1-2 Sekunden beendet ist, dürfte das nicht das Problem sein, auch wenn der Default sonst 60 Sekunden ist. Also hilft wohl nur reservieren oder die Menge an VMs reduzieren.
-
Dayworker
- King of the Hill
- Beiträge: 13651
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Um VMs auf bestimmte Kerne zu reservieren, könnte es im VI-Client eine weiter Möglichkeit geben. Meine erprobte Lösung sähe vor per Task-Manager die CPU-Affinität der VMs auf bei dir 7 Kerne zu begrenzen und den letzten Kern allein für den Host & seine restlichen Programme zu nutzen.
Dazu habe ich einige Vorarbeit leisten müssen. Der Quad aus meiner Sig läuft also mit jeweils einer an einen Kern gepinnten VM und läßt einen Kern für das Host-OS frei. Ich habe es dann soweit getrieben, daß jede VM ihren eigenen Kern hat. D.h., soweit die restlichen Host-Dienste/Anwendungen mitspielten, residiert der Process "vmware-vmx" (die VM) jeweils allein auf einem Kern und der ganze Rest auf dem freien Kern.
Das Ärgerliche dabei ist nur, daß nach einem Reboot alles von vorn losgeht.
Die Lösung könnte aber auch der VI-Client bieten. Er bietet in den erweiterten Einstellungen wahrscheinlich auch die Möglichkeit der CPU-Affinität. Das wahrscheinlich kommt deshalb, weil ich es mangels Quad auf einem Server2-Testgerät nicht sinnvoll ausprobieren konnte.
Die restlichen Einstellmöglichkeiten wie Pools oder Reservierungen ala ESX für CPU/RAM sind beim VMserver2 leider funktionslos.
Dazu habe ich einige Vorarbeit leisten müssen. Der Quad aus meiner Sig läuft also mit jeweils einer an einen Kern gepinnten VM und läßt einen Kern für das Host-OS frei. Ich habe es dann soweit getrieben, daß jede VM ihren eigenen Kern hat. D.h., soweit die restlichen Host-Dienste/Anwendungen mitspielten, residiert der Process "vmware-vmx" (die VM) jeweils allein auf einem Kern und der ganze Rest auf dem freien Kern.
Das Ärgerliche dabei ist nur, daß nach einem Reboot alles von vorn losgeht.
Die Lösung könnte aber auch der VI-Client bieten. Er bietet in den erweiterten Einstellungen wahrscheinlich auch die Möglichkeit der CPU-Affinität. Das wahrscheinlich kommt deshalb, weil ich es mangels Quad auf einem Server2-Testgerät nicht sinnvoll ausprobieren konnte.
Die restlichen Einstellmöglichkeiten wie Pools oder Reservierungen ala ESX für CPU/RAM sind beim VMserver2 leider funktionslos.
Hallo,
ich denke Euer Problem liegt hauptsächlich an den HDDs. Bei so vielen VMs kommt es vor, dass mehrere gleichzeitig auf die HDDs zugreifen und dann vielleicht auch noch der Host dazukommt, und schon hast Du Dein RAID für etliche Sekunden blockiert. In dieser Zeit läuft dann eventuell auf Host und Guests nichts mehr. Ich würde erst einmal ein RAID 0+1 versuchen, dann hast Du schon mal 4 Spindeln von denen gleichzeitig gelesen, und wenn richtig auf die Busse verteilt, auch gleichzeitig geschrieben werden kann. Sollte das immer noch nicht reichen, einfach noch eine 80 GB HDD für das System zusätzlich einbauen.
ich denke Euer Problem liegt hauptsächlich an den HDDs. Bei so vielen VMs kommt es vor, dass mehrere gleichzeitig auf die HDDs zugreifen und dann vielleicht auch noch der Host dazukommt, und schon hast Du Dein RAID für etliche Sekunden blockiert. In dieser Zeit läuft dann eventuell auf Host und Guests nichts mehr. Ich würde erst einmal ein RAID 0+1 versuchen, dann hast Du schon mal 4 Spindeln von denen gleichzeitig gelesen, und wenn richtig auf die Busse verteilt, auch gleichzeitig geschrieben werden kann. Sollte das immer noch nicht reichen, einfach noch eine 80 GB HDD für das System zusätzlich einbauen.
Ja die HDDs sind definitiv unser Bottleneck. iotop mit Werten selten unterhalb 0,5 MB/s im "Idle"-Betrieb (also ohne große Kopieraktionen) zeigt schon, dass da sehr sehr viele Zugriffe passieren. Dürfte auch der Grund sein, warum wir schon 3 der 4 Platten ausgetauscht haben *hust*
Werd mich mal mit meinem Chef über eine kleine Extra-HDD für das OS unterhalten, das sollte zumindest mal die Erreichbarkeit des Web Access verbessern.
RAM habe ich gesehen, nimmt er eh nur 90%, steht also was von 29xxx MB drin, der Rest sollte locker reichen für ein netinst-Debian.
Werd mich mal mit meinem Chef über eine kleine Extra-HDD für das OS unterhalten, das sollte zumindest mal die Erreichbarkeit des Web Access verbessern.
RAM habe ich gesehen, nimmt er eh nur 90%, steht also was von 29xxx MB drin, der Rest sollte locker reichen für ein netinst-Debian.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste