Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

W2K8 VMs die hängen / VM Heartbeat Überwachung

Hilfe bei Problemen mit Installation & Benutzung des VMware ESX Server 4/VMware vSphere 4.0.

Moderatoren: irix, continuum, Dayworker, Tschoergez

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

W2K8 VMs die hängen / VM Heartbeat Überwachung

Beitragvon pirx » 11.02.2013, 15:53

Hallo,

wir haben in letzter Zeit häufiger VMs die stehen bleiben. D.h. in dem Fall, dass das W2K8 zwar noch läuft (kein Bluescreen), aber praktische alle Dienste hängen. SCOM erhält von diesen VMs keine Daten mehr, Windows beschwert sich z.B. über...

Code: Alles auswählen

"The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly.".


Die CPU Last geht praktisch auf 0 zurück. Auf ping Pakete antwortet die VM aber noch ganz brav. Der W2K8 Anmeldeschirm ist an der Console noch zu sehen, mehr geht dort idR nicht mehr.

Im Log auf dem ESXi Host sieht man das die Heartbeats zu der VM kurz bevor das Problem in Windows auffällt aufhören.

Code: Alles auswählen

2013-02-05T18:08:09.658Z| vmx| GuestRpcSendTimedOut: message to toolbox timed out.
2013-02-05T18:08:24.659Z| vmx| GuestRpcSendTimedOut: message to toolbox timed out.
2013-02-05T18:08:24.659Z| vmx| GuestRpc: app toolbox's second ping timeout; assuming app is down
2013-02-05T18:08:24.660Z| vmx| GuestRpc: Reinitializing Channel 0(toolbox)
2013-02-05T18:08:24.661Z| vmx| GuestMsg: Channel 0, Cannot unpost because the previous post is already completed
2013-02-05T18:08:24.661Z| vmx| GuestRpc: Channel 0 reinitialized.
2013-02-05T18:08:24.661Z| vmx| GuestRpc: Channel 0 reinitialized.
2013-02-05T18:11:24.663Z| vmx| GuestRpcSendTimedOut: message to toolbox timed out.
2013-02-05T18:11:24.663Z| vmx| Vix: [2769194 guestCommands.c:2194]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest


Das Problem tritt quer über alle verwendeten ESXi Versionen (zumindest 5.0 und 5.1) auf unterschiedlichen Clustern mit unterschiedlicher Hardware auf. Inzwischen 1-2 pro Woche. Auf physischen W2K8 Servern haben wir das bisher noch nicht beobachten können. In den Windows Log gibt es keinen Hinweis auf die Ursache des Problems.

Hat jemand so einen Fall schon mal gehabt oder hat ein Idee wer der Verursacher sein könnte?

Es wird kein HA für VMs genutzt, d.h. die betroffenen VMs werden nicht automatisch neu gestartet wenn die Heartbeats ausbleiben. Deswegen wollte ich einen Alarm erstellen, der die Heartbeats prüft. Das geht out of the box über den "VM Heartbeat" Trigger Typ in den vCenter Alarm Settings. Das dumme ist, dass der Alarm auch bei einem Reboot einer VM getriggert wird, da die Tools dann noch nicht aktiv sind. Bei diesem Alarm Typ kann man auch keine "Condition Lenght" konfigurieren.

Habe ich was übersehen, oder der Alarm im vCenter damit einfach völlig sinnlos?

Benutzeravatar
Moderator
Beiträge: 14663
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 11.02.2013, 17:02

Was verwendet ihr fuer ein Storage-system ?
Gibt es in den kernel-logs Hinweise auf timeouts oder hohe Latenzen fuer die Storage-pfade ?

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 11.02.2013, 17:28

continuum hat geschrieben:Was verwendet ihr fuer ein Storage-system ?
Gibt es in den kernel-logs Hinweise auf timeouts oder hohe Latenzen fuer die Storage-pfade ?


Es sind unterschiedliche Systeme. HP EVAs (FC), HP Lefthands (iSCSI). Bei der letzten VM zeigt der Performance Graph für die Zeit als das Problem auftrat ein Latenz von unter 5ms...

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 12.02.2013, 09:59

Heute Nacht gegen 21:55 Uhr (UTC) hat es wieder eine VM erwischt.

Code: Alles auswählen


UTC Zeit

2013-02-11T20:45:01.663Z| vcpu-2| W110: VIDE: Truncating 0x5a from 65520 bytes to 32768
2013-02-11T20:45:01.674Z| vcpu-0| I120: CDROM: Emulate GET CONFIGURATION RT 1 starting feature 0
2013-02-11T20:45:01.674Z| vcpu-0| W110: VIDE: Truncating 0x5a from 65520 bytes to 32768
2013-02-11T21:16:21.945Z| vcpu-2| I120: CDROM: Emulate GET CONFIGURATION RT 1 starting feature 0
2013-02-11T21:16:21.946Z| vcpu-2| W110: VIDE: Truncating 0x5a from 65520 bytes to 32768
2013-02-11T21:16:21.947Z| vcpu-2| I120: CDROM: Emulate GET CONFIGURATION RT 1 starting feature 0
2013-02-11T21:16:21.947Z| vcpu-2| W110: VIDE: Truncating 0x5a from 65520 bytes to 32768
2013-02-11T21:54:56.763Z| vcpu-1| I120: CDROM: Emulate GET CONFIGURATION RT 0 starting feature 0

2013-02-11T21:55:03.037Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
2013-02-11T21:55:18.037Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
2013-02-11T21:55:18.037Z| vmx| I120: GuestRpc: app toolbox's second ping timeout; assuming app is down
2013-02-11T21:55:18.038Z| vmx| I120: GuestRpc: Reinitializing Channel 0(toolbox)
2013-02-11T21:55:18.038Z| vmx| I120: GuestMsg: Channel 0, Cannot unpost because the previous post is already completed
2013-02-11T21:55:18.038Z| vmx| I120: GuestRpc: Channel 0 reinitialized.
2013-02-11T21:55:18.038Z| vmx| I120: GuestRpc: Channel 0 reinitialized.
2013-02-11T21:55:18.366Z| vmx| I120: Tools: Tools heartbeat timeout.
2013-02-11T21:58:18.039Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
2013-02-11T21:58:18.039Z| vmx| I120: Vix: [11763 guestCommands.c:1926]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest


syslog

Code: Alles auswählen

Feb 11 21:55:01esx0042 crond[8689]: crond: USER root pid 2283798 cmd /sbin/hostd-probe
Feb 11 21:55:01 esx0042 syslog[2283799]: starting hostd probing.
Feb 11 22:55:00 esx0042 Section for VMware ESX,  esx0042 hostd-probe: id=2283799, version=5.1.0, build=914609, option=Release
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 warning 'Default'] Unrecognized log/level 'audit' using 'info'
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 info 'Default'] Logging uses fast path: true
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 info 'Default'] Handling bora/lib logs with VmaCore facilities
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 info 'Default'] Initialized channel manager
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 info 'Default'] Current working directory: /var/log/vmware
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 info 'Default'] Vmacore::InitSSL: handshakeTimeoutUs = 20000000
Feb 11 21:55:01 esx0042 Rhttpproxy: [69403B90 verbose 'Proxy Req 43415'] New proxy client TCP(local=127.0.0.1:80, peer=127.0.0.1:62466)
Feb 11 21:55:01 esx0042 hostd-probe: [FF9A8B90 info 'Libs'] VThreadBase detected multiple threads.
Feb 11 21:55:01 esx0042 hostd-probe: [FF9A8B90 warning 'Libs'] SSL_VerifyCbHelper: Certificate verification is disabled, so connection will proceed despite the error
Feb 11 21:55:01 esx0042 hostd-probe: [FF9A8B90 warning 'Libs'] SSL_VerifyCbHelper: Certificate verification is disabled, so connection will proceed despite the error
Feb 11 21:55:01 esx0042 hostd-probe: [FF9A8B90 warning 'Libs'] SSL_VerifyCbHelper: Certificate verification is disabled, so connection will proceed despite the error
Feb 11 21:55:01 esx0042 Rhttpproxy: [69140B90 verbose 'Proxy Req 43416'] New proxy client TCP(local=127.0.0.1:80, peer=127.0.0.1:53293)
Feb 11 21:55:01 esx0042 hostd-probe: [FF9E9B90 warning 'Libs'] SSL_VerifyCbHelper: Certificate verification is disabled, so connection will proceed despite the error
Feb 11 21:55:01 esx0042 hostd-probe: [FF9E9B90 warning 'Libs'] SSL_VerifyCbHelper: Certificate verification is disabled, so connection will proceed despite the error
Feb 11 21:55:01 esx0042 hostd-probe: [FF9E9B90 warning 'Libs'] SSL_VerifyCbHelper: Certificate verification is disabled, so connection will proceed despite the error
Feb 11 21:55:01 esx0042 hostd-probe: [FF8C2CB0 quiet 'Default'] Successfully acquired hardware: ProLiant DL380 G7
Feb 11 21:55:01 esx0042 Hostd: [477C5B90 verbose 'SoapAdapter'] Responded to service state request
Feb 11 21:55:03 esx0042 Hostd: [FF944D20 verbose 'vm:/vmfs/volumes/509d067b-4780f4a0-29bc-d8d385fa8958/VMNAME2110/VMNAME2110.vmx'] Tools guest daemon status changed to: 2
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'VpxaHalCnxHostagent' opID=WFU-652e529d] [WaitForUpdatesDone] Received callback
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'VpxaHalCnxHostagent' opID=WFU-652e529d] [VpxaHalCnxHostagent::ProcessUpdate] Applying updates from 431908 to 431909 (at 431908)
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'hostdvm' opID=WFU-652e529d] [VpxaHalVmHostagent] 12: GuestInfo changed 'guest.disk'
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'halservices' opID=WFU-652e529d] [VpxaHalServices] VmGuestDiskChange Event for vm(13) 12
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'vpxavpxaInvtVm' opID=WFU-652e529d] [VpxaInvtVmChangeListener] Guest DiskInfo Changed
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'VpxaHalCnxHostagent' opID=WFU-652e529d] [WaitForUpdatesDone] Starting next WaitForUpdates() call to hostd
Feb 11 21:55:03 esx0042 Vpxa: [72449B90 verbose 'VpxaHalCnxHostagent' opID=WFU-652e529d] [WaitForUpdatesDone] Completed callback
Feb 11 21:55:04 esx0042 Vpxa: [71F20B90 verbose 'VpxaHalCnxHostagent' opID=WFU-71d98878] [WaitForUpdatesDone] Received callback
Feb 11 21:55:04 esx0042 Vpxa: [71F20B90 verbose 'VpxaHalCnxHostagent' opID=WFU-71d98878] [VpxaHalCnxHostagent::ProcessUpdate] Applying updates from 431909 to 431910 (at 431909)
Feb 11 21:55:04 esx0042 Vpxa: [71F20B90 verbose 'hostdvm' opID=WFU-71d98878] [VpxaHalVmHostagent] 15: GuestInfo changed 'guest.disk'





Bild

Bild

Bild

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 18.09.2014, 15:12

Hey, ich habe das Problem über Google gefunden...
bei mir ist es ähnlich, jedoch nur bei einer VM. Da es der Fileserver ist, der sich in der Regel nur langweilt... wunderte mich das enorm. Es ist nun aber schon das 3. Mal passiert... was hast Du denn für eine Lösung gefunden...

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 19.09.2014, 22:41

Pirx seine Antwort ist bereits 19 Monate alt und die Lösung ihm daher sicher wieder entfallen...
Da wir deine Hard- und Software nicht kennen und du keinerlei Logs verlinkt hast, dürfte eine mögliche Lösung auch recht schwer werden.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 22.09.2014, 11:05

Entschuldigung, da es genau die gleichen Meldungen sind, hab ich mir das gespart.

Ich gehe davon aus, das diese zwar nichts bringen, denn der Timeout der VMware Tools ist sicher auch nur eine Folge des Problems... Also eine folge davon, das der Gast selbst nicht mehr in der Lage ist etwas zu tun. Es kommt zwar noch eine Antwort auf ICMP also PING, alle anderen Prüfungen über Icinga, und Versuche eine Verbindung aufzubauen scheitern. Es macht allerdings den Eindruck, als könnten teilweise bestehende Verbindungen noch arbeiten.

Es ist wie gesagt der Dateiserver mit mehreren Laufwerken, ich habe Arbeitsplätze gefunden die noch auf dem Laufwerk arbeiten konnten, wenn auch nur noch kurz. An anderen Plätzen war alles tot, RDP geht nicht, Dienste liefen nicht, geöffnete Dateien waren nach dem Ausschalten des Servers defekt.

Man konnte sich auch das Bild "Drücken Sie Strg+Alt+Entf" über die Konsolte ansehen, aber man konnte nichts mehr machen, keine Tastenkombinationen senden etc. Es bliebt also nur noch das ausschalten.

Hier die Informationen zum Server
- ESXi 5.1.0 2000251
- Thomas Krenn Server
- LSI MegaRaid SAS 9260-4i
- LocalStorage (15000er SAS Platten auf dem Datenspeicher)
- Installation auf einem schnellen USB-Strick (von Thomas Kress)
- 2x Intel Xeon E5620 @ 3,4 Ghz
- Mainboard SuperMicro X8DT3
- 96 GB Arbeitsspeicher

Hier die Informationen zum Gast
- VMware Tools (9.0.12 build 1897911)
- VM-Version 8
- 2 vCPUs (langweilen sich)
- 2GB Arbeitsspeicher (dauerhafte Nutzung von nuir 1GB in den letzten 12 Monaten)
- Windows Server 2008R2
- LSI Logic SAS
- 5 vDisks
- 1 vmxnet3


Die Last sollte wenn überhaupt seit 2 Wochen auf dem ESXi weniger sein, denn zwei Exchaneg 2010 und ein Exchaneg 2003 sind seit zwei Wochen auf einem anderen ESXi umgezogen. Wobei das auch keine Gründe der Last sondern organisatorische hatte.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 22.09.2014, 11:59

Nun ist es erneut passiert. Habe nun mal mehr vCPUs und Arbeitsspeicher zugewiesen. Auch wenn ich mir das so nicht erklären kann. Nun also 4GB Arbeitsspeicher und 4 vCPUs

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 22.09.2014, 12:15

Hallo,

IIRC war es bei uns eine Anwendung die zu den Zeiten die Hardwareinventarisierung der Server durchgeführt hat, u.a. mit WMI Aufrufen. Irgendetwas davon hat die VMs zum stehen gebracht, bei Physik ist das nicht passiert. Ein Update der Anwendung hat das Problem gelöst.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 22.09.2014, 12:20

Also in der Tat ein Problem genau auf der VM? Oder ein Problem mit einer Software die auf diese VM zugreift? Oder noch ganz anders, war es ein Problem durch eine "Überlastung" des ESXi?

Denn es ist so gut wie nichts auf dem Gerät installiert... Außer die Bereitstellung von Laufwerken mit der entsprechenden Rolle von Micrsoft Server 2008 R2.

Danke aber schon mal für die Rückmeldung...

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 22.09.2014, 13:21

Das Problem trat bei mehreren VMs auf, bei denen Systeminformationen durch eine Applikation auf einem anderen System abgefragt wurden. Es waren immer wieder unterschiedliche VMs.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 22.09.2014, 13:52

Ich habe gerade mal einen alten ESXi genommen einen Gast genommen der "Knapp" bemessen und "viel" gemacht... Das was in den Logs steht, war "identisch" zu unseren Problemen... und reagieren konnte der Gast natürlich auch nicht mehr!

Also scheint es in der Tat etwas zu sein was auf dem Gast enorme Last verursacht. Wenn bei euch nun natürlich dieser Dienst und die Abfragen über diesen Dienst auf vielen Gästen passieren, wäre bei einem Problem in der Software natürlich auch erklärt warum es mehrere Gäste gab die betroffen waren.

Ich habe nun zwar keine Ahnung was auf meinem Gast für ein Problem vorhanden ist, gehe nun aber davon aus das ein "verschieben" auf einen anderen ESXi oder ähnliches nichts bringen würde...

Danke für Die Hilfe!

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 22.09.2014, 23:42

Sieh dir mal mit Sysinternals Process-Explorer oder deren neuem SysMon nach, was da wie wo wann abgeht.
Auch wenn der Windows-Taskmanager inzwischen viel an Funktionalität dazugelernt hat, kommt man mit beiden Tools wesentlich weiter.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 23.09.2014, 08:26

Danke für den Tipp. Hab ich schon gemacht... aber einen Grund für etwas ist dort nicht zu sehen.

Wird nun wohl oder Übel beim nächsten Problem per Ausschlussverfahren die Anwendungen Stück für Stück auf einen anderen Gast umziehen. Ansonsten könnte es ja reichen das nun die Prozessoren und Arbeitsspeicher den ich zugewiesen habe das Problem schon lindert...

Aber ich bleibe am Ball...

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 23.09.2014, 20:24

Bei Netzwerkproblemen die vHW zu Verdoppeln (vRAM, vCPU), wird dir nicht weiterhelfen und je nach Host sowie weiterer auf dem Host laufenden VMs sogar eher für deren verlangsamte Ausführung sorgen.

Mit welcher NIC sind sowohl der Host als auch die Gäste ausgestattet?
VMware unterstützt TOE nur rudimentär. Je nach Gast sorgt ein Abschalten desselben für weniger Probleme.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 24.09.2014, 08:15

Das dies natürlich Physikalische Grenzen hat ist mir bewusst. Nur waren bevor das Problem angefangen ist ein stark belasteter Exchange 2010 mit auf dem Host. Dieser hatte 4 vCPUs und 8 GB Arbeitsspeicher. Das sollte also drin sein.

Davon abgesehen ist auf den anderen "wenigen" VMs nicht wirklich was los. In der Regel habe ich halt nur die Auslastung und Statistik von Icinga genutzt um einer VM auch nicht einfach "irgendwas" zu geben, sondern genug um im Betrieb zu funktionieren, aber nicht einfach irgendwas.

Aber dennoch danke für den Tipp.
Wenn wir aber schon bei dieser Theorie sind. Gibt es dazu eigentlich genaue Richtlinien. Best Practieses auf deutsch? Habe dazu schon viel gelesen wie man es sizen soll... aber fast alles hat sich irgendwie wiedersprochen in einigen Punkten.


In jedem Fall ist auch vom Host die CPU, Arbeitsspeicherausnutzung wie auch die IO Werte bei weiten noch nicht unter Last.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 24.09.2014, 08:22

Ach ja, ganz vergessen... es war ja auch nie so recht von "Netzwerkproblemen" die Rede. Nur stellt man bei Servern im Netzwerk nun mal als erstes fest das sie nicht mehr zu erreichen sind. Da er auch über die Konsole von VMware nicht mehr erreichbar war... gehe ich nun nicht wirklich von einem Netzwerkproblem aus. Alle anderen Server warten auch normal erreichbar....

Oder habe ich was übersehen?

Profi
Beiträge: 982
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 24.09.2014, 12:25

Hallo zusammen,

ich würde mich hier eher auf die VM konzentrieren, denn der ESXi Server stellt ja die angeforderten Resourcen weiterhin bereit.
Und da sich der ESXi Server ja offenbar weiter managen läßt liegt das Problem doch eher innerhalb der VM.

Gruß,
Ralf

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 25.09.2014, 09:30

Also langsam wird es komisch... es ist nun wieder passiert... aber ich habe keine Ahnung warum... aktuell ist dort wirklich nur ein Fileserver von Microsoft, die anderen Dienste habe ich angehalten bzw. die Clients sind nicht verbunden...

dann werde ich wohl mal einen neuen Server installieren und die Laufwerke umziehen müssen :-(

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 29.09.2014, 13:18

Also, ich habe erstaunlicherweise gerade in meinem Monitoring gesehen das 1,2 GB Arbeitsspeichernutzung angezeigt werden. Es sind aber im Taskmanager auf dem Gast 1,7 und wurden jeden Tag ein wenig mehr...

Da ich dann davon ausgegangen bin das es mit steigender Laufzeit mehr wird... hab ich immer das Fenster auf und lasse den Server sich auch nicht mehr sperren... so dass ich im Zweifel schnell dran komme :-)


Nun hab ich gesehen das der meiste Arbeitsspeicher von "svchost.exe" genutzt wird und habe einfach mal in Google gesucht was das sein könnte. Also nicht die EXR Datei sondern warum die so viel Arbeitsspeicher zieht... denn auf anderen Servern macht Sie das nicht... dann wurde der BITS Dienst und der WUAUSERV genannt. Beide angehalten und der Speicher wurde freigegeben...


Nun such ich mal weiter, aber eine steigende Nutzung von Arbeitsspeicher und späteres Swappen des Gastes in Verbindung mit Last könnte schon für einen solchen Ausfall sorgen... nun schau ich mal warum der Windows Update Dienst und BITS so viel braucht....

Benutzeravatar
King of the Hill
Beiträge: 12046
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 30.09.2014, 23:48

Bist du dir sicher, daß sowohl BITS als auch WUAUSERV für die RAM-Last verantwortlich sind?
Ich frag nur, weil bei M$ üblicherweise mehrere Instanzen von "svchost" gestartet werden und falls inzwischen der Taskmanager keine Prozeß-Aufschlüsselung beherrscht, sieht man zumindest mit Sysinternals Process-Explorer was sich hinter jedem "svchost"-Instanz verbirgt.

WUAUSERV ist meines Wissens für sämtliche M$-Updates zuständig und je nach Einstellung wird ein solcher Server meist auch als Update-Server für alle Domänen-Mitglieder genutzt. Je nach Einstellung zieht dieser dann für sämtliche konfigurierten OS über den BITS-Hintergrunddienst die M$-Updates und hält diese lokal im Netzwerk vor.

Member
Beiträge: 60
Registriert: 10.05.2009, 01:22

Beitragvon rep » 01.10.2014, 07:37

Also ich habe den BITS Dienst und auch den Update Service angehalten. Dann wurde die svchost.exe (mit den erhöhten Speicherwerten) sehr klein... genau sehen konnte ich das nicht. Habe das aus Aktion=Reaktion geschlossen. ;-)

Ebenfalls ist die TrustedInstaller.exe stark dabei gewesen die ja auch was mit Updates zu tun hat. Ich habe dann die Dienste nach dem Neustart erneut angehalten, den Update Service bereinigt (C:\Windows\SoftwareDistribution) und die Dienste gestartet. Dann nach 30 Minuten noch ein Reboot und gewartet....

Dann war der TrustedInstaller irgendwann weg, und auch der Speicher der svchost.exe wurde normal. Bin nun wieder seit Tagen auf einem Pegel von "1,2 - 1,3 GB Speicher" für den ganzen Server".

Der WSUS, also der Server für die Windows Updates auch für andere Computer im Netz wird aber nicht dynamisch verteilt. Das ist eine Rolle. Diese ist nicht auf dem Server, sondern auf einem anderen Server. Aktuell ist das sogar noch ein Windows Server 2003. Aber das spielt hier keine Rolle... es scheint in der Tat ein quer sitzendes Update, nicht vollendetes Update oder sonst was mit dem Update Dienst auf einem "Client" zu tun gehabt zu haben..

So viel, da muss man ehrlich sein, die Vermutung... aber ich werde dennoch den Server die nächsten Wochen etwas genauer unter die Lupe nehmen...


Gruß
rep


Zurück zu „vSphere 4 / ESX 4“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast