bouncer86 5 Geschrieben 21. Juni 2013 Melden Teilen Geschrieben 21. Juni 2013 Hallo, wir haben 4 Terminalserver Win 2008 R2 mit XenApp 6.5 aktuelle Hotfixe und Win Updates für ca. 30 Benutzer. Die Terminalserver laufen auf 3 VMware ESX 5.1 Servern. Die VMware Server sind jetzt nicht die neusten, aber eben auch nicht die ältesten. Alle mit 2x 4 Core Intel E5405 CPUs(2GHZ) und 64 GB RAM. Natürlich laufen dort noch andere VM's drauf. Die Terminalserver selbst sind mit 4 vCPU's und 8 GB RAM ausgestattet. Das Storage welches ein Single DataCore Server ist (mit 64GB RAM als Write Cache) und entsprechend genügend SAS 10k Festplatten im RAID5 Verbund ist per FC 8 GBit angebunden. Wenn ich mir die RAM Auslastung ansehe, kommen die TS Server nicht an ihre Grenzen. CPU Auslastung liegt im Schnitt bei ca. 30-40%. Im Windows System schaue ich mir die Storage Antwortzeiten an und bin hier nicht höher als 20ms. Also eigentlich sieht alles super aus. Doch trotzdem beklagen sich die Anwender, das alles total träge ist. Sicherlich kann euch die Glaskugel jetzt nicht sagen an welcher Stelle der Battleneck ist. Aber habt ihr eine Idee bzw. eine Vorgehensweise, wie ich dem Problem auf die schliche kommen kann? Zitieren Link zu diesem Kommentar
boomi 10 Geschrieben 21. Juni 2013 Melden Teilen Geschrieben 21. Juni 2013 Hallo, bei solchen Probleme würde ich als erstes mal in Ereignislog gucken ob da fehler drin sind, etwar ein Prozess der das System ausbremst. Dann würde ich mal mit den Performance monitor ein log der Terminalserver erstellen um zu schauen welche Performancewerte der Server so im laufe des Tages hat. Zitieren Link zu diesem Kommentar
testperson 1.660 Geschrieben 21. Juni 2013 Melden Teilen Geschrieben 21. Juni 2013 (bearbeitet) Hi, wie sind denn die anderen VMs mit vCPUs bestückt? Und wie sind die VMs auf den Hosts verteilt? Was für Workloads/Server werden sonst noch virtuell Betrieben? Ich würde mal das Stichwort CPU Ready Time in den Raum werfen ohne genauere Einblicke zu haben. Generell würde ich auch sagen immer so wenig wie möglich vCPUs zu verteilen, heißt also 4 vCPUs für nen TS finde ich etwas oversized (Ohne genaure Infos über eingesetzte Software zu kennen) . Gruß Jan bearbeitet 21. Juni 2013 von testperson Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 22. Juni 2013 Melden Teilen Geschrieben 22. Juni 2013 Moin, die ersten Verdächtigen neben der RAM, CPU Auslastung und HDD Antwortzeit wären bei mir IOPS Disk Queue CPU Queue Zitieren Link zu diesem Kommentar
bouncer86 5 Geschrieben 22. Juni 2013 Autor Melden Teilen Geschrieben 22. Juni 2013 Also CPU ready Times hab ich gestern auch dran gedacht. Die lagen bei über 5000 ms. Hatte gestern dann auf 2vcpus reduziert. Die Times sind um Faktor 4 gesunken. Ich bin mal auf kommende Woche gespannt. Was meint ihr mit CPU und disk Queue?wo kann ich die am sinnvollsten messen? iops würden sich ja nur berechnen lassen. Messen ist ja schwierig da andere vms auf dem gleichen raid laufen Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 22. Juni 2013 Melden Teilen Geschrieben 22. Juni 2013 Also CPU ready Times hab ich gestern auch dran gedacht. Die lagen bei über 5000 ms. Hatte gestern dann auf 2vcpus reduziert. Die Times sind um Faktor 4 gesunken. Ich bin mal auf kommende Woche gespannt. Das sieht nach einer massiven Überbuchung der physischen CPU Kerne aus. Was meint ihr mit CPU und disk Queue?wo kann ich die am sinnvollsten messen? Am Besten in den betroffenen VMs. Die CPU bzw. Disk Queue gibt an, wieviele Jobs auf die Ressource warten müssen. Grundsätzlich sind alle Werte größer 1 ein Indikator für einen potentiellen Engpass. iops würden sich ja nur berechnen lassen. Messen ist ja schwierig da andere vms auf dem gleichen raid laufen Das ist genau das Thema bei einem shared storage. Wiele IOPS kann das Backend maximal bereitstellen (Am Besten hat man eine Messung vor der Inbetriebnahme durchgeführt ansonsten muss man den theoretischen Wert schätzen) und wieviel IOPS werden aktuell genutzt. Ich kenne DataCore zwar nicht, aber jedes vernünftige Backend sollte in der Lage sein, solche Daten zu liefern. Eventuell liegt die Ursache gar nicht bei den RDS Hosts sondern bei einem anderen System, das gerade Amok läuft (SQL, Mail oder auch ein suboptimal konfigurierter AntiVirus). Bei den RDS Hosts tritt lediglich das Symptom der 'Trägheit' auf. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 22. Juni 2013 Melden Teilen Geschrieben 22. Juni 2013 (bearbeitet) Sorry, aber Dein Xeon ist nach heutigen Maßstäben unterirdisch: http://www.cpubenchmark.net/high_end_cpus.html (Du musst ans Ende scrollen) Aktuelle XEON's sind um ein Vielfaches schneller. Auch dürften die einige Prozessor-Features bieten, welche die Leistung in virtuellen Umgebungen verbessern. Mit der Hardware könntest Du es mal mit eine TS probieren, aber ohne Vitalisierung. Du solltest auch sicherstellen, dass die neusten ESXi-Updates installiert sind (Update 1 zzgl. div Updates) bearbeitet 22. Juni 2013 von zahni Zitieren Link zu diesem Kommentar
bouncer86 5 Geschrieben 22. Juni 2013 Autor Melden Teilen Geschrieben 22. Juni 2013 Hallo, also meine Ready Time ist jetzt bei unter 100ms. Das sieht jedenfalls schon mal besser aus. Wie gesagt, mal abwarten wie es kommende Woche ist. Meine Disk Queue, ich hoffe in Perfmon (logischer Datenträger\Aktuelle Warteschlängenlänge ist der richtige Wert) steht auf 0 und kommt da auch nicht drüber hinaus. Meine Prozessor Queue (System\Prozessor Warteschlangenlänge) liegt zwischen 3 und 6. Sollte also noch halbwegs im Rahmen liegen.(Bei 2 vCPU's) Anti Virus hab ich schon ausgeschaltet, das brachte nichts. Ich weiß, die Systeme sind nicht die neusten, aber es gibt derzeit leider keine neue Hardware. Aber ich tippe langsam auch auf überbuchte vCPU's. Kann mir jemand bitte erklären, wie das mit den vCPU's genau ist? Ein Terminalserver, wo viele Benutzer drauf arbeiten sollte ja in der Regel von mehreren CPU's profitieren.Da mehrere Threads gleichzeitig verarbeitet werden können. Aber vCPU und physische Kerne ist ja nicht das selbe. Wenn ich zu viele vCPU's verbuche, war es da nicht so, dass beim abarbeiten immer auch 4 physische Kerne gleichzeitig belegt werden müssen und solange das nicht möglich ist, werden die Berechnungen der VM zurück gestellt? Aber es ist ja schon etwas sehr seltsam, wenn 2 vCPU's irgendwo schneller sind als 4 ;) Danke für eure Mühe. Ich habe noch folgenden interessanten Technet Artikel über Performance Monitoring gefunden, den gehe ich heute noch durch. http://technet.microsoft.com/de-de/magazine/2008.08.pulse.aspx Zitieren Link zu diesem Kommentar
bouncer86 5 Geschrieben 22. Juni 2013 Autor Melden Teilen Geschrieben 22. Juni 2013 Mh interessant ist auch, ich finde im Perfmon keinen vergleichbaren Counter. D.h. auf einem XenServer oder Hyper-V wird es dann ja schwer solch einen Fehler rauszufinden. Oder hab ich den Counter nur übersehen? Welcher ist es? Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 22. Juni 2013 Melden Teilen Geschrieben 22. Juni 2013 Mit ESXTOP auf der Console. Zitieren Link zu diesem Kommentar
bouncer86 5 Geschrieben 23. Juni 2013 Autor Melden Teilen Geschrieben 23. Juni 2013 Mit ESXTOP auf der Console. Unter esx weiß ich wo ich's finde. Aber es gibt ja auch xenserver oder hyper v. Da hab ich keinen vergleichbaren counter gefunden. Daher die frage ob ihr wisst wo ich diesen unter Win, also innerhalb der VM finde? Oder nicht möglich dort zu messen? Zitieren Link zu diesem Kommentar
NeMiX 76 Geschrieben 23. Juni 2013 Melden Teilen Geschrieben 23. Juni 2013 Du könntest mal mit VMTurbo mitmessen was bei dir IOPS zieht. Ersten 30 Tage sind kostenlos und helfen manchmal bei etwas diffusen Performanceproblemen. Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 23. Juni 2013 Melden Teilen Geschrieben 23. Juni 2013 Im Prinzip gibt es diese oder vergleichbare Performance-Werte auch bei Windows. Hier findest Du ein paar nützliche Downloads zum Thema Performance für 2008R2 und 2012: http://msdn.microsoft.com/en-us/library/windows/hardware/jj248719.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/gg463392.aspx 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.