windows servers vol geheugen belasting

[dolbymaster]

Hallo Mede tweakers,

Ik zit met een probleem waar ik onderhand niet meer aan uit kom,
op kantoor hebben wij een ESXI Server runnen met meerdere Windows servers waaronder 2008r2, sbs, etc.
Het rare aan de servers is, dat alle servers om stipt 16:00 volledig naar het max van hun toegewezen geheugen knallen, ik dacht dat het aan de Windows update service lag maar dat was het dus niet blijkbaar, tevens is het aparte dat op niet alle servers exchange draait en zelfs daarop het geheugen naar het maximale klapt

Zodoende hoop ik dat jullie eventuele tips hebben, waar ik eens naar kan zoeken om het probleem op te lossen.

Met vriendelijke groet,
Quentin

[HyperBart]

Goh...

Even de glazen bol er bij nemen: redelijk donker vandaag .

Heb je al eens task manager open gezwierd?

Ik roep maar het eerste wat in me opkomt: backups?

[marcop82]

MS SQL geïnstalleerd en de instelling voor "max memory" niet ingesteld op normale waarde ?

[dolbymaster]

Task manager al eens open gegooit, meerdere malen, en daar in komt store van exchange hoog in boven uit, maar dat verklaart niet waarom het ook op een kale server gebeurt, waar helemaal niks op staat

[dolbymaster]

marcop82 schreef op dinsdag 08 september 2015 @ 16:41:
MS SQL geïnstalleerd en de instelling voor "max memory" niet ingesteld op normale waarde ?

Daar kan ik nog eens naar kijken , misschien lost het bij een aantal servers wat problemen op.

[Killah_Priest]

dolbymaster schreef op dinsdag 08 september 2015 @ 16:41:
Task manager al eens open gegooit, meerdere malen, en daar in komt store van exchange hoog in boven uit, maar dat verklaart niet waarom het ook op een kale server gebeurt, waar helemaal niks op staat

En als je naar de processen op zo'n server kijkt ipv op je exchange server? En hoe zit het met de memory consumptie op de hypervisor? Gebruiken de VMs ook zoveel geheugen volgens de hypervisor of kijk je alleen naar de guests zelf vanuit de guests?

[dolbymaster]

zodra we het totaal verbruik van de ESXI server bekijken dan kont dat presies overeen met geheugen wat de windows servers op dat moment verstoken ja.

Tevens is het nog steeds een raadsel waarom het elke dag om stipt 16:00 uur is, morgen zal ik
op een van de kale servers broncontrole in de gate houden om te zien waar presies het geheugen van die server heen gaat.

[sig69]

Waarom één? Hou ze gewoon allemaal in de gaten.

[johnkeates]

Heb je geen monitoring? Geen APM? Niks? Wat voor shop draai je daar Je kan toch niet dit soort problemen tegen komen en dan gokken?

[KillerAce_NL]

Lijkt me niet zo moeilijk, gewoon metrics capturen rond die tijd...Komop ff googlen en je weet hoe.

[dolbymaster]

KillerAce_NL schreef op woensdag 09 september 2015 @ 07:30:
Lijkt me niet zo moeilijk, gewoon metrics capturen rond die tijd...Komop ff googlen en je weet hoe.

Ik ga een poging doen en wanneer ik meer informatie heb, dan laat ik het weer weten op het Forum

[McKaamos]

Lijkt me een vrij simpel gevalletje van 'meten is weten'.
Gewoon je processmonitor open zetten en kijken welk proces/processen er veel geheugen gebruiken.
Als het stipt om 16:00 is, zou ik in ieder geval gaan denken aan een taak die op de scheduler staat en die alle betreffende virtuele servers met elkaar delen. Denk aan een backupscript oid.

[sig69]

Het is bijna 16:00, ik ben benieuwd

[Question Mark]

Hoe ziet je ESX host er qua memory uit?

Is deze toevallig overcommit (total memory van de vm's is groter dan het fysieke memory in de host)? Ik heb wel eens vreemde effecten gezien als een ESX VM/Host het druk krijgt met "ballooning" van memory.

[dolbymaster]

Er staan geen backupscripts of andere scripts in de Taakscheduler,
tevens kom ik er iet aan uit, via bron monitor gekeken maar zie niks raars gebeuren in de processen van Windows.
De HP server die wij gebruiken heeft momenteel 192GB aan werk geheugen, en er staan 12 servers voor zover ik weet op welke tusse de 8 en 12 GB aan ram hebben, dus dat zou geen probleem moeten zijn neem ik aan.

[KillerAce_NL]

Ik kom er niet uit....daar kunnen we niks mee. Wat heb je gecaptured ? Je ESXI heeft niks te maken met de ram belasting IN de vm.

[_Arthur]

dolbymaster schreef op vrijdag 11 september 2015 @ 11:05:
tevens kom ik er iet aan uit

Dan wordt het tijd om iemand te zoeken die je hier bij kan assisteren.

[sig69]

dolbymaster schreef op vrijdag 11 september 2015 @ 11:05:
tevens kom ik er iet aan uit, via bron monitor gekeken maar zie niks raars gebeuren in de processen van Windows.

Dat kan niet als er iets geheugen gebruikt moet dat te zien zijn. Waar zit je te kijken, de task manager? Zet dan ook de kolom "working set" oid aan. Verder, als je zo'n setup draait is het onbegrijpelijk dat er niets van monitoring draait. Installeer new relic of whatever en je kan precies zien welk proces hoeveel gebruikt.

[alt-92]

Of als het allemaal echt geen drol mag kosten en weinig moeite moet zijn:
wsrm aanzetten (mits meerendeel 2008r2 based is)

[KillerAce_NL]

Kansloos topic, ts post geen vooruitgang en kan het niet zelf. Tijd dat hij zijn IT club in gaat schakelen.

[dolbymaster]

KillerAce_NL schreef op zondag 13 september 2015 @ 17:14:
Kansloos topic, ts post geen vooruitgang en kan het niet zelf. Tijd dat hij zijn IT club in gaat schakelen.

Ik doe men best om het hier op de hoogte te houden, maar ik heb vanaf thuis geen toegang tot de servers.
ik moet dus ook wachten tot ik weer op kantoor ben zoals nu.

[Question Mark]

KillerAce_NL schreef op vrijdag 11 september 2015 @ 11:19:
Je ESXI heeft niks te maken met de ram belasting IN de vm.

Toch wel, als TS vijf VM met 10 GB memory in een niet-expandable resource pool geplaatst heeft met 40 GB geheugen gaat VSPhere zich daar echt wel mee bemoeien... Afhankelijkvan de prioriteit en ingestelde reserveringen van een VM vindt al dan niet "ballooning" plaats binnen de VM.

Dat de host 192 GB memory heeft, en de VM's in totaal hier niet aan komen zegt op zich nog niet zo heel veel. Dit is sterk afhankelijk van de eventuele inrichting van resource-pools.

[KillerAce_NL]

Gezien de simpele setup verwacht ik dat niet (daarom het korte antwoord), maar het kan ja.
Heeft ie alleen performance problemen, maar zijn "probleme"is dat de vm's zélf qua ram vollopen.

[ Voor 41% gewijzigd door KillerAce_NL op 14-09-2015 11:32 ]

[Question Mark]

KillerAce_NL schreef op maandag 14 september 2015 @ 11:31:
Heeft ie alleen performance problemen, maar zijn "probleme"is dat de vm's zélf qua ram vollopen.

En dat gedrag kan prima overeen komen met ballooning. Het systeem blijft 8 GB aan geheugen zien, maar het "system" proces kan dan zondermeer bv. 4 GB (extra) in gebruik nemen. Dat is dan de ballooningdriver die geheugen aan het claimen is in opdracht van de VSphere host.

Het is bij "ballooning" niet zo dat de guest tijdelijk minder memory krijgt, de VM ziet nog steeds evenveel. De ballooning driver gaat memory "inpikken". Dit is overigens redelijk eenvoudig te zien in de VSphere client.

KillerAce_NL schreef op maandag 14 september 2015 @ 11:31:
Gezien de simpele setup verwacht ik dat niet (daarom het korte antwoord), maar het kan ja.

Juist bij simpele omgevingen zie ik nog wel eens dat beheerders resourcepools aan gaan maken omdat dan zo makkelijk VM's "in een mapje"gestopt kunnen worden voor het overzicht. Folders zijn nl. niet zichtbaar in de "host and clusters' view en resourcepools wel. Het wordt nog wel eens misbruikt.

[ Voor 24% gewijzigd door Question Mark op 16-09-2015 15:47 ]

[KillerAce_NL]

Ik weet wat ballooning is
Als men reources pools voor dit soort zaken misbruikt, dan kan dit gebeuren idd.

[dolbymaster]

Sorry voor het niet zo snel reaggeren, echter is gelukkig het probleem op gelost.
Mijn collega die heeft op de server de Resources voor Exchange aangepast, vervolgens een keer rebooten en we hebben al anderhalve week geen problemen meer

Ik zal het Maandag nog even uitgebreid proberen te documenteren mochten er meerdere mensen ook baad aan hebben

[Question Mark]

Op welke server is wat nu aangepast?

Als hij binnen Vsphere de resources voor de Exchange VM heeft aangepast, dan lijkt het er dus op dat er kennelijk toch sprake was van overcommitment en dus ballooning in de VM.

Zou je dit eens na willen vragen? (even voor de beeldvorming)