Forseti2003 14 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 Guten Morgen in die Runde. Ich hab hier aktuell ein Problem, was sich seit einigen Tagen schon hinzieht, jegliche Maßnahmen oder Prüfungen die ich durchführe, greifen dabei aber ins Leere. Folgende Grundlage: Es wird ein vmware ESXi 5.1 Host betrieben, dieser hat 130 GB RAM und 64 GHz an CPU-Leistung (2x12) und ist mit 2x 1 GBit ans Netzwerk angeschlossen. Darauf laufen aktuell rund 10 Server, davon sind 7 Terminalserver im Einsatz mit ca. 65-80 Personen. Die Terminalserver laufen unter Windows Server 2008 SP1 und einer unter 2008 RC2. Symptome: Die TS verhalten sich recht unterschiedlich. Bei einigen laufen alle Programme langsam (unabhängig der CPU-Last im Task Manager oder vom Leistungsbericht des ESXi Hosts) bei anderen nur vereinzelte Programme. Die Probleme sind aber meist immer für den jeweiligen TS gleich - sprich es verlagert sich nicht von TS zu TS. Uhrzeitlich laufen die TS morgens auch noch recht stabil und beginnen über den Tag dann langsamer zu werden (evtl. User abhängiges Verhalten). Bisher durchgeführte Maßnahmen: - vereinzelte Dienste abgeschaltet (Tablet Eingabe, Smartcard) - CPU von 4x1 auf 4x2 aufgestockt (bringt zwar etwas, aber der erwartete Performance-Schub stellt sich nicht ein) - RAM auf den größeren TS auf 20 GB aufgestockt, die kleineren bei 8 GB belassen (sofern Enterprise, die Standard OS laufen eh nur auf 4 GB - dafür aber fast normal schnell) - Microsoft Updates eingespielt Jetzt die Frage: 1) Kann ich irgendwie am ESXi Host eine Prüfung durchführen, mit der ich feststelle wo eventuell da der Flaschenhals ist? 2) Wie kann ich im Betriebssystem den Grund der "Blockade" ermitteln? Die normalen Leistungsanzeigen wie RAM, CPU oder Netzwerk zeigen nicht direkt außergewöhnliche Werte. Vielleicht hat jemand eine Idee oder kennt ein ähnliches Problem? Grüße Forseti Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 Erzähle doch zunächst mal im Detail, welche Hardware Du genau verwendest. Mit dem kostenlosen ESXI kannst Du meiner Meinung nach nicht alle Cores in den Prozessoren verwenden. BTW: Welche Intel CPU hat 12 Cores eingebaut ? Falls Du AMD Opteron verwendest, wundert mich das nicht so... Über die ServiceConsole kannst DU ESXTOP aufrufen. Details, als was man damit machen kann, findest Du in der VmWare KB Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 Zum Einsatz kommt ein Dell R715 AMD Opteron, die ESXi 5.1 ist lizenziert und kann alle Cores ansprechen. Was spricht gegen den Opteron? Gemäß vmWare ist er ja zertifiziert. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 Jetzt schreibe doch noch, war genau alles im Server eingebaut ist. Welche Opterons, welche Storage Controller, usw. Wir hatten auch mal Opterons. Opterons sind einfach total lahm. Ich frage ich gerade, wie Du 130 GB RAM auf die Prozessoren aufgeteilt hast. Ist im BIOS auch wirklich NUMA aktiviert ? Empfehlung: Sämtliche Powermanagement-Funktion im BIOS auf "STATIC High Performance" stellen (nennt sich bei HP so, bei Dell k.a.) In den VM's unter "Power Options" "Hgh Performance" auswählen (englisches Windows) . Auch ein schlecht designter Storage kann hier sehr negativ wirken. Das sollte man schon in den VM's im Ressource Monitor herausfinden können. Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 Das ist kein Problem: CPU: AMD Operton 6348 / 12 Cores - 2,8 GHz RAM: 8x16 GB RAM Der Storage sind 6 HDD Festplatten mit einem internen Raidcontroller Dell PERC H700 auf Raid 10 Basis. BIOS müßte ich am Server noch prüfen, war eine vorkonfigurierte Einheit, hab daher das BIOS nicht geprüft. Aber das NUMA interessiert mich jetzt doch, unter 3.5 gab es sowas noch nicht, was ist das, bzw. was sollte ich da einstellen? Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access Machen alle neueren Opterons und die neueren Intel-Xeons. Wichtig: Alle Prozessoren bekommen den gleichen RAM gesteckt (bei Dir also 4x16). Die Boards haben dazu getrennte Speicherbänke. Zumindest bei HP kann man NUMA im BIOS abschalten. Was man aber eher nicht tun sollte. Zum Storage: Mal hier anfangen: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008205 Ich finde den für so viele VM's etwas unterbelichtet. Zum Opteron: Schau mal hier http://www.cpubenchmark.net/multi_cpu.html Dort steht der 6344 in der Liste ( nur minimal langsamer als Deiner) Nun vergleiche mit Xeon E5, der i.d.R. weniger Cores hat, und daher die bessere (und wichtige) Single-Thread-Performance.. -Zahni Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 Also NUMA müßte bei meinem DELL aktiv sein, da die VM im Arbeitspeicher das Register für NUMA hat und auch (sofern ich die ausschalte) konfigurieren lässt. Bei dem Storage ist aktuell nur ein Gerät aktiv, der vmhba1 als SCSI, gemäß der Beschreibung bringt er folgende Werte: vmhba1 - NPTH: 2 / AQLEN: 975 / CMDS/s: 122,81 / READ/s: 2,05 / WRITES/s: 95.4 So, durch NUMA und ESXTOP durchlawiniert (nehme mir vor, definitiv mich da besser einzulesen) - drei Terminalserver springen in den Nodes umher, das sind auch die wo am größten sind und am meisten Last benötigen. Da steht bei NHN dann 1,2 / 0,3 oder 0,1 - Wert verändert sich. Die restlichen VM's haben jeweils nur einen Node und springen darin umher. NUMA /MB: 32758 (12452), 32768 (9809), 32768 (17129), 32752 (1276) Sieht eigentlich fast so aus, wie in der Anleitung. Was könnte ich nun noch prüfen oder lässt sich daraus schon was sagen? Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 Vielleicht solltest Du Dir vom VMWare Support helfen lassen ? Aus der Ferne ist das nur ein gestochere im Nebel. 122 IOPS ist nicht gerade doll. Ist das der Durchschnittswert ? Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 ja,..eigentlich nichts was mich vom Hocker reißen würde. Aber da ich ja mir Deine LInks und Beiträge zu Herzen genommen habe, bin ich noch auf was gestoßen. ESXTOP vermeldet bei der CPU folgende Werte (Beispiel einer der Server die am stärksten von der Performance betroffen sind): NWLD 13 / %USED 330,12 / %RUN 377,40 / %SYS: 2,43 / %RDY: 63 / %CSTP: 137 / %WAIT: 780,97 Der TS hat 8 Cores zugewiesen bekommen. Gemäß dem vmWare KB wäre ja der Wert Used und RUN somit in Ordnung (CPU * 100%) - der Wert für WAIT ist aber dann zu hoch. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 In stark belasteten System ist es keine so gute Idee 8 Vcpu's zu vergeben. Sonst dauert der Context-Switch zu lange. Ich halte in Deiner Umgebung 4 für das Maximum. Beachte, dass sich die Vcpu's immer auf der gleichen CPU befinden müssen. Hast Du Enterprise Plus ? Meiner Meinung nach geht nur diese Version mit 12 Core pro Sockel. Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 Aktuell ist es die vSphere 5 Standard - aber er meckert mir nicht bei der Hardware, das er was kappen würde. Anbei ein Link, darin steht auch das es keine Core-Begrenzung mehr gibt: http://www.thomas-krenn.com/de/wiki/VMware_vSphere_5_Editionen_Funktionsunterschiede Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 Stimmt, diese Limitierung gibt es bei Vsphere 5.1 nicht mehr. Mein Fehler. Beide CPU's sind aber lizensiert ? ESXi wird pro Sockel lizensiert. Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 jep, beide Sockels sind sauber lizenziert. Was mich halt aktuell extrem verwundert ist, das ich wenig IOPS hab, nur 90 von 131 GB RAM überhaupt in der Zuteilung sind (davon aktiv genutzt 30 GB) - die CPU "nur" 43 GHz von 67 GHz nutzt aber sich so verhält als wenn die Ressourcen am Anschlag wären und dadurch dann den WAIT erzeugen. Zitieren Link zu diesem Kommentar
NeMiX 76 Geschrieben 12. September 2013 Melden Teilen Geschrieben 12. September 2013 Nur als Tipp: Terminalserver skalieren meiner Erfahrung nach nicht wirklich mit mehr Ram und/oder CPU. Lieber klein halten (4GB Ram, 2vCPU) und dann in die Breite gehen. Dank Templates geht das ja relativ schnell. Ansonsten würde ich am Storage ansetzen. Was für HDDs hast du dadrin? Ist eine BBU verbaut und wie sind die Cache Settings auf dem Controller. Evtl. mal ins Raid Bios gehen und schauen ob da alles sauber läuft. Zitieren Link zu diesem Kommentar
Forseti2003 14 Geschrieben 12. September 2013 Autor Melden Teilen Geschrieben 12. September 2013 Das mit den TS ist klar, wir mußten aber die alten Server erstmal so übernehmen um den Livebetrieb angenehm zu halten. Später werden wir das über eine einfache TS-Farm abwickeln und können dann die TS besser dimensionieren. Festplatten sind TOSHIBA AL13SEB600 - 600 GB SAS - 10.500 rpm / BBU ist vorhanden. 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.