Windows SBS 2008 geheugen

[PeeCee]

Beste mede tweakers,

Wij hebben op de zaak een Dell R410 welke naar mijn idee redelijk een grote pagefile bevat(Windows SBS 2008).
De pagefile is 24.556MB en gebruikt nu 12.153MB (Vrijdag, helft bedrijf vrij)..

Nu heeft de machine 12 GB aan geheugen en vroeg ik mij af of het verstandig is om een upgrade uit te voeren naar 24 GB geheugen?

De server wordt erg intensief gebruikt en ondervind op een doordeweekse dag veel hard faults(Nu vrijdag, helft bedrijf is vrij en nog zie ik veelal 2 per seconden).

Ik zelf denk dat gezien het gebruik van 8 GB contene gebruik fysiek geheugen en 11 GB page file gebruik een upgrade wel op z'n plaats is.
Hierbij vraag ik mij wel wat wat er gebeurd met de Page file. Wordt deze nu kleiner, doet windows er niets mee of wordt deze groter wanneer ik er meer fysiek geheugen in de machine stop.

Ik zou graag willen weten wat jullie advies is?

Mijn dank

[Craven]

Wat draai je allemaal op die bak dat je denkt dat je er 24gb geheugen voor nodig gaat hebben? Exchange en SQL pakken bvb automatisch een hele sloot geheugen ongeacht of ze het nodig hebben of niet. Check je task manager is wat er allemaal veel geheugen verbruikt.

[PeeCee]

Het is SBS, dus eigenlijk alles gaat er over die machine. E-mail, DNS, DHCP, Sharepoint, TS-gateway, SMB, ADS, SQL en WDS.

En inderdaad, Exchange 2007 en MSSQL verdampen een hoop geheugen, maar ook IIS.

De grootverbruikers zijn:
IIS: 1250 MB
Exchange: 1510 MB (2 databases a 35 GB en 22 GB)
MSSQL: 1625
DNS: 155
MDCS: 141

Totaal: 6306 MB

Verder veel kleine processen. Maar wel een kanttekening dat het vandaag vrijdag is en van de 26 mailboxen er maar 10 open staan en dus Exchange het redelijk rustig heeft.

Normaal draait de machine op 8 tot 10 GB fysiek geheugen gebruik.

[kKaltUu]

Craven schreef op vrijdag 04 november 2011 @ 16:37:
Wat draai je allemaal op die bak dat je denkt dat je er 24gb geheugen voor nodig gaat hebben? Exchange en SQL pakken bvb automatisch een hele sloot geheugen ongeacht of ze het nodig hebben of niet. Check je task manager is wat er allemaal veel geheugen verbruikt.

Inderdaad, je weet dat de server flink belast wordt, maar weet je ook waarom? SQL en Exchange zijn de grootste slurpers, maar als je er custom pakketten op hebt draaien kan het ook zijn dat je server flink belasten. Meten = weten e.d....
Daarnaast, het kan natuurlijk nooit kwaad om extra geheugen erbij te prikken in je server (en in de tussentijd uitpluist wat er het meest verbruikt).

[PeeCee]

Ik zal morgen eens om 11 uur kijken. Dan is iedereen er en zien we heel snel wat er echt aan het slurpen is. Ik zet zelf 100 Euro in op Exchange

[chrisros]

dan hoop ik dat je wint, kan je meteen nieuw ram kopen

[PeeCee]

Ik heb vandaag even de server in de gaten gehouden en de grootverbruikers blijven.
SQL en Exchange nemen iets meer geheugen in beslag, maar verder blijft het net onder de 10 GB gebruik.

Ook de gebruikte ruimte van de pagefile grooit niet heel veel (+300 MB).

Heeft het zin om hier het geheugen te verdubbelen. En wat doet dit met de pagefile?

chrisros schreef op zondag 06 november 2011 @ 22:47:
dan hoop ik dat je wint, kan je meteen nieuw ram kopen

Haha, kost wel iets meer.

[Grvy]

Heeft denk ik meer zin om van het SBS Model af te stappen en naar iets als ESXI (Free) te kijken waarop je dan kan gaan balancen..

[Rolfie]

Grvy schreef op maandag 07 november 2011 @ 16:30:
Heeft denk ik meer zin om van het SBS Model af te stappen en naar iets als ESXI (Free) te kijken waarop je dan kan gaan balancen..

En dan?
SBS kost bijna niets. En alle losse producten kost een vermogen.

[_Arthur]

Klagen de gebruikers over performance?

En meer geheugen bijsteken zal er voor zorgen dat SQL en Exchange meer gaan cachen.

[Grvy]

Rolfie schreef op maandag 07 november 2011 @ 16:51:
[...]

En dan?
SBS kost bijna niets. En alle losse producten kost een vermogen.

Zoals ik zeg.. kan je gaan balancen? dan zit niet iedereen die alleen SQL nodig heeft ook onnodige load te veroorzaken op de Exchange etc..

[Jazzy]

Grvy schreef op maandag 07 november 2011 @ 16:30:
Heeft denk ik meer zin om van het SBS Model af te stappen en naar iets als ESXI (Free) te kijken waarop je dan kan gaan balancen..

Balancen van wat? Meerdere virtuele servers op de zelfde hardware? Dat kost alleen maar meer aan overhead dus heeft een negatief effect.

De load verdelen over meerdere servers? Wat heeft dat virtualisatieproduct er dan mee te maken? Verder heeft de TS (zijn baas) al geïnvesteerd in SBS 2011, die investering kan hij weggooien als hij de veel duurdere losse producten moet aanschaffen om de rollen over twee servers te kunnen verdelen.

[Grvy]

Jazzy schreef op maandag 07 november 2011 @ 19:35:
[...]
Balancen van wat? Meerdere virtuele servers op de zelfde hardware? Dat kost alleen maar meer aan overhead dus heeft een negatief effect.

De load verdelen over meerdere servers? Wat heeft dat virtualisatieproduct er dan mee te maken? Verder heeft de TS (zijn baas) al geïnvesteerd in SBS 2011, die investering kan hij weggooien als hij de veel duurdere losse producten moet aanschaffen om de rollen over twee servers te kunnen verdelen.

Correct me if i'm wrong maar met SBS mag je Server 2008 standard virtueel draaien voor zover ik weet.. en daar kan hij dus de SQL opzetten (of de andere groot verbruiker) waardoor je wellicht niet extra geheugen nodig heeft omdat ESX/Hyper-v wat slimmer omgaan met geheugen distributie.

[NIK0]

Poeh ik val per toeval in dit topic dus even mijn $0.02

Zoals eerder gezegd vraagt de TS niet naar een virtualisatieoplossing. Dan praat je over een dik bedrag wil jij gaan loadbalancen. Je praat dan iig over een 2e Dell R410 met een sloot geheugen. (en als je ECHT wilt loadbalancen dan praat je ook over shared storage).
De impact van de hedendaagse hypervisors is nog maar een paar % dus dat zou geen issue mogen zijn.

Windows is gek op geheugen dus daar kun je bijna nooit fout gaan. Check ook even of je disken geen bottleneck vormen.
Indien er geen gebruikersklachten zijn kun je je afvragen of het de investering waard is..
Succes..!

[ Voor 18% gewijzigd door NIK0 op 07-11-2011 19:59 ]

[Grvy]

NIK0 schreef op maandag 07 november 2011 @ 19:56:
Poeh ik val per toeval in dit topic dus even mijn $0.02

Zoals eerder gezegd vraagt de TS niet naar een virtualisatieoplossing. Dan praat je over een dik bedrag wil jij gaan loadbalancen. Je praat dan iig over een 2e Dell R410 met een sloot geheugen. (en als je ECHT wilt loadbalancen dan praat je ook over shared storage).
De impact van de hedendaagse hypervisors is nog maar een paar % dus dat zou geen issue mogen zijn.

Windows is gek op geheugen dus daar kun je bijna nooit fout gaan. Check ook even of je disken geen bottleneck vormen.
Indien er geen gebruikersklachten zijn kun je je afvragen of het de investering waard is..
Succes..!

Ah shit; idd shared storage.. dat was ik vergeten.. dat is aardig duur ja.. my bad..

[nielsl]

Grvy schreef op maandag 07 november 2011 @ 19:40:
[...]


Correct me if i'm wrong maar met SBS mag je Server 2008 standard virtueel draaien voor zover ik weet.. en daar kan hij dus de SQL opzetten (of de andere groot verbruiker) waardoor je wellicht niet extra geheugen nodig heeft omdat ESX/Hyper-v wat slimmer omgaan met geheugen distributie.

Dan moet je de premium add-on aanschaffen. Overigens is dat wel een vrij goedkope manier om een tweede server op te tuigen. Voor de rest sluit ik me aan bij bestaande opmerkingen over alsnog 2 virtuele hosts draaien en de problemen mbt overhead.

[Question Mark]

Even terug naar je probleem...

PeeCee schreef op vrijdag 04 november 2011 @ 16:24:
De server wordt erg intensief gebruikt en ondervind op een doordeweekse dag veel hard faults(Nu vrijdag, helft bedrijf is vrij en nog zie ik veelal 2 per seconden).

Hard page faults zijn pas een indicatie van memory-tekort als deze meer dan 40% van alle page-faults bedragen:

code:

 Pages Input/sec / Page Faults/sec = % Hard Page Faults

bron: Performance Monitor Counters

Zolang dit niet het geval is, is er niet zoveel aan de hand. Kijk dus eerst even of je uberhaubt wel een probleem hebt. Zoals ook al eerder gezegd is, zowel Exchange als SQL proberen vanwege performance zoveel mogelijk geheugen te claimen. Dat je dan een hoog geheugengebruik ziet op een systeem waar zowel SQL als Exchange op draait is dan ook niet meer dan logisch.

PeeCee schreef op vrijdag 04 november 2011 @ 16:24:
Hierbij vraag ik mij wel wat wat er gebeurd met de Page file. Wordt deze nu kleiner, doet windows er niets mee of wordt deze groter wanneer ik er meer fysiek geheugen in de machine stop.

Ligt er compleet aan wat je zelf instelt. Je hebt de keuze uit:

• System managed pagefile
• Manual, waarbij je een minimale en maximale waarde aan kunt geven (per disk)
• No pagefile

[PeeCee]

Bedankt voor jullie reacties.

Van de premium SBS licentie wordt reeds gebruik gemaakt voor een w2k8 TS-Server 32bit. Verder heb ik zelf al zitten kijken naar een oplossing m.b.v. een tweede R410, SAN en Xen. De kosten zijn hoog en overkill voor ons formaat bedrijf. SBS gaat tot 75 gebruikers en pas over 20 nieuwe medewerkers/TS-gebruikers ga ik hier serieus naar kijken. (Er is geen kantoor ruimte meer over btw )

Verder hebben we wel gebruikers die klagen over een trage outlook icm Exchange en soms wat traag reagerende server wanneer bestanden worden gelezen van netwerkschijven. Ook zelf merk wel dat de server wat traag reageerd soms.

Gezien die 2 tot 3 hard-faults per seconden denk ik persoonlijk niet dat het geheugen dan uitgebreid hoeft te worden.
Wel ik denk ik dat het tijd wordt om de machine eens flink op te schonen gezien ooit geinstalleerde onderdelen nooit meer gebruikt worden zoals Sharepoint(SQL-geheugen/schijfruimte sleurper). Dit gezien we een aparte w2k3 machine hebben voor de SQL van het CRM.

[_Arthur]

Wat is de disk / raid config van die server? En welke disks worden er gebruikt?

Want ik gok dat het een combinatie is: meer geheugen zorgt voor meer caching en dus minder het aanspreken van de disks.

Wat zijn de disks queue lengths bv? Meet die eens met perfmon.

[ Voor 54% gewijzigd door _Arthur op 09-11-2011 09:48 ]

[PeeCee]

Goede vragen Arthur

De W2K8 SBS draait vanaf een in RAID-1 SAS schijven 15k aangesloten op een SAS 6/iR.

Bedrijfsbestanden, Exchange EDB's en SQL opslag komen van een DAS via een PERC 6/E controllere. De schijven staan in RAID-5 6x 418,62 GB 15k met Hot-Spare.

Resultaten Perfmon (2 uur).

Disk

Performance Counter	Instance	Mean	Minimum	Maximum
]Avg. Disk Bytes/Read	C:	27,118	0	262,144
Avg. Disk Bytes/Transfer	C:	22,883	0	16,739,840
Avg. Disk Bytes/Write	C:	13,032	0	16,739,840
Avg. Disk Queue Length	C:	0.136	0	29
Avg. Disk Read Queue Length	C:	0.086	0	29
Avg. Disk Write Queue Length	C:	0.051	0	16
Current Disk Queue Length	C:	0.12	0	42
Avg. Disk Bytes/Read	D:	18,324	0	1,177,873
Avg. Disk Bytes/Transfer	D:	15,812	0	4,025,259
Avg. Disk Bytes/Write	D:	14,489	0	6,033,792

Memory

Performance Counter	Mean	Minimum	Maximum
Available MBytes	304	98	462
Cache Bytes	5,862,640,131	5,832,658,944	5,916,786,688
Cache Bytes Peak	5,947,498,496	5,947,498,496	5,947,498,496
Cache Faults/sec	56	0	60,365
Page Faults/sec	2,731	0	82,715
Page Reads/sec	6	0	4,179
Page Writes/sec	0.002	0	15
Pages Input/sec	24	0	7,507
Pages Output/sec	0.464	0	3,475
Pages/sec	24	0	7,507

Ik hoop dat ik nu nog beter geadviseerd kan worden

[Jazzy]

De average disk queue lenght geeft aan dat het systeem staat te wachten op de opslag (disks, controller, etc.) en zou onder de 5 moeten blijven. Een maximale waarde van 29 (op C:) geeft aan dat er pieken zijn waarop het systeem flink staat te wachten op de opslag.

Ik mis die waarde voor D:, ik neem aan dat dit het volume is waar de data op staat, maar die zal ook wel pieken vertonen angezien je met RAID-5 wat minder performance kunt halen.

[PeeCee]

D mist inderdaad waardes. Deze worden wel opgevraagd in perfmon, maar niet getoond. Ik schat dat hij die waardes niet kan lezen van de controller..

[_Arthur]

PeeCee schreef op woensdag 09 november 2011 @ 14:26:
D mist inderdaad waardes. Deze worden wel opgevraagd in perfmon, maar niet getoond. Ik schat dat hij die waardes niet kan lezen van de controller..

Onzin: die waardes komen van het OS en niet uit de controller. In perfmon moet je alle disks queue lengths kunnen meten.

Als Exchange etc etc op je D:\ staat wil je daar ook echt de disks queue lengths van hebben.

Verder wat Jazzy zegt over de C:\. in dit geval met 2 disks zou dit eigenlijk al niet hoger dan 4 (gemiddeld/piek) mogen zijn.

Even kort door de bocht: 12GB extra ram zal in dit geval zal er voor zorgen dat je disks minder aangesproken zullen worden en dus je disks queue lenghts een heel eind naar beneden gaan.

Hoe staat verder je read/write ahead policies op die Perc6/E? En zit er een BBU aan?

[ Voor 3% gewijzigd door _Arthur op 09-11-2011 15:14 ]

[_JGC_]

Wat je hardwareconfig betreft: je C-schijf met SAS6/IR is een LSI 1078 controller zonder BBU en zonder cache. Om de performance-ramp iets groter te maken dan het lijkt staat standaard de writeback op de disks ook uitgeschakeld, waardoor je erg veel wachttijd krijgt. Je kunt cache inschakelen met lsiutil, maar houd er rekening mee dat als je hele zooi crasht, dat de inhoud van je diskcache dan foetsie is.

[Question Mark]

Ik ben even benieuwd hoelang die pieken duren in je disk queue length. Een korstondige piek is helemaal niet erg en te verwachten op een systeem waar verschillende applicaties veel disk I/O genereren.

Het is even van belang of deze pieken een aantal minuten of een aantal seconden duren. Zoals Jazzy al aangeeft wordt een average queue length van >5 als problematisch beschouwd. Daar zit je volgens je tabel lang niet aan op je C-schijf.

[PeeCee]

Whaha, had even gemist dat hij enkel top 10 van 83 weergaf. Nu ga ik niet alles posten, maar hierbij het volledige tabelletje:

Disk

Performance Counter	Instance	Mean	Minimum	Maximum
]Avg. Disk Bytes/Read	C:	25,898	0	262,144
Avg. Disk Bytes/Transfer	C:	20,486	0	16,739,840
Avg. Disk Bytes/Write	C:	10,393	0	16,739,840
Avg. Disk Queue Length	C:	363	0	29
Avg. Disk Read Queue Length	C:	0.054	0	29
Avg. Disk Write Queue Length	C:	363	0	16
Current Disk Queue Length	C:	0.116	0	42
Avg. Disk Bytes/Read	D:	18,324	0	1,177,873
Avg. Disk Bytes/Transfer	D:	15,812	0	4,025,259
Avg. Disk Bytes/Write	D:	14,489	0	6,033,792
Avg. Disk Queue Length	D:	0.177	0	44
Avg. Disk Read Queue Length	D:	0.026	0	11
Avg. Disk sec/Write	D:	0.012	0	0.259
Avg. Disk Write Queue Length	D:	0.151	0	44
Current Disk Queue Length	D:	0.177	0	82

[PeeCee]

Question Mark schreef op woensdag 09 november 2011 @ 15:39:
Ik ben even benieuwd hoelang die pieken duren in je disk queue length. Een korstondige piek is helemaal niet erg en te verwachten op een systeem waar verschillende applicaties veel disk I/O genereren.

Het is even van belang of deze pieken een aantal minuten of een aantal seconden duren. Zoals Jazzy al aangeeft wordt een average queue length van >5 als problematisch beschouwd. Daar zit je volgens je tabel lang niet aan op je C-schijf.

Ik weet niet of ik dit uit perfmon kan halen, maar gezien het in de grafiek redelijk te zien is, heb ik hier een plaatje van gemaakt. Dit is alleen C.

De D schijf heeft alleen maar korte pieken, maar een grote hoeveelheid.

[PeeCee]

Is het misschien verstandig om niet alleen geheugen uit te breiden?

Ik zat zelf te denken aan het volgende met ook het extra geheugen:

Opzet

-	Disk	Data
Bestaand	C	Windows + program files
Bestaand	D	Bedrijfsdata (profielen, netwerkschijven enz)
Nieuw	E	Exchange + SQL

[ Voor 23% gewijzigd door PeeCee op 10-11-2011 09:59 ]

[Verwijderd]

Hier hebben we SBS 2011 op een HP Proliant G6 server met 16GB intern geheugen met twee keer Intel Xeon E5620 processors en 6 SAS schijven. Twee van 140GB 15K in raid-1 voor OS en de andere 4 van 600GB 10K in raid-10 voor data en de Exchange database.

Hier is hij retesnel dus misschien dat je raid-5 configuratie alles vertraagd?

[PeeCee]

Verwijderd schreef op donderdag 10 november 2011 @ 11:33:
Hier hebben we SBS 2011 op een HP Proliant G6 server met 16GB intern geheugen met twee keer Intel Xeon E5620 processors en 6 SAS schijven. Twee van 140GB 15K in raid-1 voor OS en de andere 4 van 600GB 10K in raid-10 voor data en de Exchange database.

Hier is hij retesnel dus misschien dat je raid-5 configuratie alles vertraagd?

Ik denk dat de RAID-5 vertraagd is doordat er onderanderen Exchange, SQL en bedrijfsbestanden op staan. Dit is zo gegroeid omdat de C schijf vol begon te raken en we 100 GB tekort kwamen.

Een upgrade van het geheugen ga ik zo i zo doen. Schijven is nog even de vraag, ook gezien de fabriek huidig onder water staat.

[PeeCee]

Een klein schopje, maar vond dat deze topic aangevuld moet worden met resultaat.

Het geheugen van de machine is sinds vannochtend verdubbelt en nu 24 GB. De "Avg. Disk Queue Length" op de schijven is afgenomen naar een max van 5 op de C schijf en 6 op de D schijf.

Wel valt mij op dat windows aangeeft nog steeds niet meer dan 8~9 GB aan geheugen te gebruiken. Verder is de server nu wel sneller.

De volgende actie wordt twee schijven bij plaatsen om de DAS verder te ontlasten, maar moet even wachten tot de fabrieken weer draaien

Bedankt voor jullie hulp

[_Arthur]

PeeCee schreef op woensdag 16 november 2011 @ 15:24:
Wel valt mij op dat windows aangeeft nog steeds niet meer dan 8~9 GB aan geheugen te gebruiken. Verder is de server nu wel sneller.

Exchange zal steeds meer in zijn cache plaatsen waardoor uiteindelijk veel meer geheugen 'in gebruik' zal zijn dan direct na een reboot.

[_JGC_]

Maakt idd niet uit hoeveel geheugen je erin stopt, Exchange vreet het allemaal op. Als je nog meer dingen dan alleen Exchange en AD hebt draaien op die server zou je kunnen overwegen om de cache van Exchange te limiteren. Ik had laatst een SBS 2011 server met 24GB die zo traag als poep was, bleek dat Exchange gewoon het meeste opgevreten had. Als er dan ook nog MSSQL Express en Interbase op draaien is het niet meer vooruit te branden.

[_Arthur]

Hoe en wat over JGC zijn opmerking lees je hier; _Arthur in "Het algemene Exchange 2010 topic"

Met 24GB geheugen, zal Exchange 2010 tot 14GB aan cache gebruiken op een SBS 2011 omgeving. Wat relatief veel is tov de andere services die er opdraaien.

Exchange 2010 cached ook meer tov het beschikbare geheugen. Exchange 2007 gebruikt (te lezen hier: http://www.msexchange.it/...he-size-in-exchange-2007/) ongeveer 50% (16GB ram = 8GB cache). Waarbij 2010 steeds meer cached als er meer geheugen beschikbaar is (met 16GB ook 8GB en met 24GB 14GB, zie ook: http://technet.microsoft.com/en-us/library/ee832793.aspx

[GB2]

Om meer performance te halen zou ik de raidkaart voorzien van extra geheugen...wel zorgen voor cache batterij....

[PeeCee]

GB2 schreef op vrijdag 18 november 2011 @ 20:13:
Om meer performance te halen zou ik de raidkaart voorzien van extra geheugen...wel zorgen voor cache batterij....

Dit is punt twee op mijn lijst.

De Dell PERC heeft een lege batterij en de firmware moet geupdate worden.
Het geheugen is voldoende maar er is nu geen write cache, door de lege batterij, Windows dit heeft uitgeschakeld.

Dit is een probleem voor Dell gezien ze nog ong. 3 jaar aan ons vast zitten voor full support.

[_JGC_]

Geen write cache op je RAID controller is gewoon killing, logisch dat je performance problemen hebt. Hup, snel een nieuwe BBU erin.

[PeeCee]

_JGC_ schreef op zaterdag 19 november 2011 @ 11:15:
Geen write cache op je RAID controller is gewoon killing, logisch dat je performance problemen hebt. Hup, snel een nieuwe BBU erin.

Valt wel mee.. Ondanks dat Windows het uitschakeld heb ik het weer ingeschakeld.. Hangt UPS aan.

Maar inderdaad moet die BBU gefixed worden, i know.. time needed

[Beatboxx]

Dat is toch gewoon een zaak voor Dell?

[PeeCee]

Beatboxx schreef op zaterdag 19 november 2011 @ 18:28:
Dat is toch gewoon een zaak voor Dell?

Jip... Need to call (again)...