Gulp 260 Geschrieben 7. August 2008 Melden Teilen Geschrieben 7. August 2008 RAID 5 ist nicht wirklich optimal für VM's, zumal in den VM's DB's laufen die immer recht Plattenintensiv sind. Interessant wäre noch wie die Platten angebunden sind (SAS, SCSI oder S-ATA). Der Kern dürfte aber sein, dass der Unterbau nicht mehr mit den I/O Anfragen der VM's nachkommt und daher Deine Festplattenlast kommt. Das habe ich schon des öfteren mit VM's erlebt, gerade wenn eine DB virtualisiert wird (auch wenn es "nur" die Express Editions sind). Wenn das zutreffen sollte gibt es allerdings nicht allzuviele Alternativen, ausser den Unterbau schneller zu machen, auf andere Hardware als Host ausweichen, die VM's auf weitere Rechner verteilen oder die VM's als physikalische Maschinen betreiben. Grüsse Gulp Zitieren Link zu diesem Kommentar
daffy 10 Geschrieben 7. August 2008 Autor Melden Teilen Geschrieben 7. August 2008 Hi Gulp, das RAID 5 nicht optimal ist, ist mir bewußt. Es wird der LSI SAS Controller verwendet. Meinst du mit "die VM's als physikalische Maschinen betreiben" den ESX (bevorzugt den ESXi)-Server? Läuft das dann ohne Änderung der VMs performanter bei gleicher Hardware? Gruß Zitieren Link zu diesem Kommentar
Gulp 260 Geschrieben 7. August 2008 Melden Teilen Geschrieben 7. August 2008 Nicht unbedingt, kann aber schon einen Unterschied machen. Bei DB's in VM's bin ich bisher immer skeptisch gewesen, weil ich hier fast immer seltsame Lags in VM's oder sonstige komische Phänomene festgestellt habe, die ich bei gleicher Konfiguration auf identischer Hardware nie nachstellen konnte (da läuft zB auch gerade ein Call bei MS zur Klärung). Man kann zwar beispielsweise die 8.3 Namensgebung und das Speichern des Änderungsdatum in NTFS per Registry ausschalten um das Filesystem etwas zu beschleunigen und an sich performanter zu machen, aber ich habe selbst in ESX Szenarien SQL Server, die ich irgendwann auf physikalische (echte) Hardware auslagern musste. Dabei handelt es sich allerdings auch um recht umfangreiche DB's mit zeitkritischen Selects oder Inserts und immer um SQL Standard oder Enterprise und seltenst um SQL Express. Mit "physikalisch betreiben" meine ich die Auslagerung der VM in eine echte Maschine und nicht mehr den Betrieb als VM. Bei DB's musst Du ja immer rechnen, dass es die DB Datei und das Transactionlog gibt in die recht dauerhaft geschrieben werden (je nach Last der DB), hier empfiehlt man sowieso das Transactionlog auf einer eigenen schnellen Platte vorzuhalten. Zudem kommt hinzu, dass bei der VM ja immer ein virtueller Plattencontrollertreiber noch dazwischenhängt, der durchaus auch noch Performance fressen kann, auch wenn Vmware versichert, dass es hier kaum Verzögerungen geben sollte. Bei DC's oder wenig bis mittel ausgelasteten Fileservern habe ich eigentlich immer ganz gute Erfahrungen mit VM's gesammelt, bei DB's (ausser WSUS) bevorzuge ich echte Hardware, auch den Terminalserver würde ich aus dem Bauch heraus nicht unbedingt in einer VM betreiben wollen. Grüsse Gulp Zitieren Link zu diesem Kommentar
daffy 10 Geschrieben 7. August 2008 Autor Melden Teilen Geschrieben 7. August 2008 Der Terminalserver ist schon wegen dem Speicher nicht optimal, war ja nur ein Versuch der dann produktiv geworden ist :-). Hier gibts wenige veröffentliche Anwendungen, also nicht so die Last. Aber das eigentliche Problem schein mir bisher weiterhin der Host zu sein. Wer sich die Grafik anschaut, der kann Feststellen dass die Linie, die unter der Decke klebt von diesem Host ausgeht und die anderen Maschinen damit auch mehr Performance lassen. Was mir dabei auffällt: Nach dem Systemstart und zwischendurch steigt der Wert sprunghaft von quasi 0 auf 100 und fällt auch so wieder. Das sehe ich eben nicht im I/O-Bereich, aber es ist auch kein zusätzlicher Prozeß festzustellen in dieser Zeit. Ihr seht mich ziemlich ratlos :confused: Zitieren Link zu diesem Kommentar
Gulp 260 Geschrieben 7. August 2008 Melden Teilen Geschrieben 7. August 2008 Nun genau das ist aber meiner Erfahrung nach typisch und ich halte das immer noch für ein I/O Problem. Solche periodischen Spitzen hatte ich auch, die verschwanden letztlich erst, als der Host nur noch 2 wenig ausgelastete Fileserver als VM's gehostet hat. Dass der Host unter der Decke klebt ist ja eigentlich auch zu erwarten, schliesslich muss er neben seinen eigenen I/O's auch noch 5 mehr oder minder starke I/O Anfragen der Gäste letztlich mit abarbeiten, sprich er muss in Lastzeiten etwa das 5- bis 6-fache I/O Volumen abfangen können (was meist genau in die Spitzen in Deinem Diagramm ausarten dürfte ;-) ). Grüsse Gulp Zitieren Link zu diesem Kommentar
daffy 10 Geschrieben 12. August 2008 Autor Melden Teilen Geschrieben 12. August 2008 Rückmeldung: Hallo, habe meine Probleme gelöst, nachdem ich einige Einstellungen vorgenommen habe. Da es zur Zeit zu viel wäre die genaue Ursache festzulegen, stelle ich hier nochmal alle neu eingestellten Lösungsansätze vor. 1. Remove virtual USB device from guest hardware 2. Remove virtual CD-ROM from guest hardware 3. Disable VMware memory optimizations C:\Documents and Settings\All Users\Application Data\VMware\VMware Server\config.ini prefvmx.useRecommendedLockedMemSize = "TRUE" prefvmx.minVmMemPct = "100" 4. guest ".vmx" file sched.mem.pshare.enable = "FALSE" mainMem.useNamedFile = "FALSE" MemTrimRate = "0" MemAllowAutoScaleDown = "FALSE" 5. If you run Windows 2003 SP2 Disable TCP Chimney (Some problems occur after installing Windows Server 2003 SP2) 1. Click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type: Netsh int ip set chimney DISABLED 3. Press the ENTER key. Gruß daffy Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.