Geschikte Windows O / S pagefile grootte voor SQL Server

stemmen
16

Heeft elke weet dat een goede vuistregel voor de juiste grootte pagefile voor een server waarop SQL Server Windows 2003?

De vraag is gesteld op 05/08/2008 om 18:07
bron van user
In andere talen...                            


8 antwoorden

stemmen
11

Met alle respect voor Remus (die ik respecteer sterk), ik zeer oneens. Als uw pagina-bestand is groot genoeg om een ​​volledige dump te ondersteunen, zal het een volledige dump iedere keer uit te voeren. Als u een zeer grote hoeveelheid RAM-geheugen, kan dit leiden tot een kleine blip op een grote uitval werd.

Je wilt niet dat uw server te hebben om uit te schrijven van 1 TB aan RAM-geheugen op de harde schijf als er een eenmalige voorbijgaande kwestie. Als er een terugkerend probleem, kunt u de pagina bestand te verhogen tot een volledige dump vast te leggen. Ik zou wachten om dit te doen totdat je zijn isntructed door PSS (of iemand anders gekwalificeerd is om een ​​volledige dump te analyseren) verzoeken u om een ​​volledige dump vast te leggen. Een zeer klein percentage van de DBA's weten hoe ze een volledige dump te analyseren. Een mini-dump is sufficent voor het oplossen van de meeste problemen die pop-up toch.

Plus, als je server is geconfigureerd om een ​​1 TB volledige dump mogelijk te maken en een terugkerend probleem optreedt, hoeveel vrije schijfruimte zou je aanraden om bij de hand? Je zou kunnen vullen een hele SAN in één weekend.

Een pagina-bestand 1,5 * RAM was de norm terug in de dagen dat je het geluk om een ​​SQL Server met 3 of 4 GB RAM-geheugen waren. Dit is niet langer het geval. Ik laat de pagina bestand in Windows standaard grootte en instellingen op alle productie-servers (met uitzondering van een SSAS-server die is met het geheugen druk).

En net voor verduidelijking, ik heb met servers, variërend van 2 GB RAM-geheugen tot 2 TB aan RAM werkte. Na meer dan 11 jaar, heb ik alleen maar moest het wisselbestand increae naar een volledige dump een keer vast te leggen.

antwoordde op 05/10/2011 om 22:39
bron van user

stemmen
10

Irrelevant van de grootte van het RAM-geheugen, je moet nog steeds een pagefile ten minste 1,5 keer de hoeveelheid fysiek RAM. Dit geldt zelfs als je een 1 TB RAM machine, dan heb je 1,5 TB pagefile op de harde schijf nodig heeft (klinkt gek, maar het is waar).

Wanneer een proces MEM_COMMIT geheugen via VirtualAlloc / VirtualAllocEx vraagt, het gewenste formaat moet worden gereserveerd in de pagefile. Dit was het geval in de eerste Windows NT-systeem, en het is nog steeds zo te zien beheren Virtueel geheugen in Win32 :

Als het geheugen wordt gepleegd, zijn de fysieke pagina's van het geheugen toegewezen en ruimte is gereserveerd in een pagefile .

Bare sommige extreme vreemde gevallen, zal SQL Server altijd vragen om MEM_COMMIT pagina's. En gezien het feit dat SQL maakt gebruik van een Dynamic Memory Management beleid dat van tevoren zo veel buffer pool mogelijk behoudt (reserves en pleegt in termen van VAS), zal SQL Server te vragen bij het opstarten een enorme reservering van ruimte in de pagefile. Als de pagefile is niet goed sized fouten 801/802 zal beginnen opduiken in SQL's errorlog file en operaties.

Dit zorgt ervoor dat altijd enige verwarring, als beheerders ten onrechte van uitgaan dat een groot RAM elimineert de noodzaak voor een pagefile. In werkelijkheid gebeurt het tegenovergestelde, een groot RAM vergroot de noodzaak van pagefile, alleen vanwege de innerlijke werking van het Windows NT-memory manager. De gereserveerde pagefile wordt, hopelijk, nooit gebruikt.

antwoordde op 22/11/2009 om 23:11
bron van user

stemmen
3

Volgens Microsoft "zoals de hoeveelheid RAM in een computer toeneemt, de noodzaak van een pagina bestand af." Het artikel gaat dan door te beschrijven hoe Prestatielogboeken gebruiken om te bepalen hoeveel van de pagina bestand daadwerkelijk wordt gebruikt. Probeer het instellen van uw pagina bestand naar 1.5X systeemgeheugen om te beginnen, doe dan de aanbevolen controle en aanpassingen vanaf daar.

Hoe kan ik de juiste grootte pagina bestand voor 64-bits versies van Windows bepalen

antwoordde op 03/08/2010 om 19:58
bron van user

stemmen
2

We waren onlangs met een aantal problemen met de prestaties met één van onze SQL Server die we waren niet in staat om volledig te smal neer, en eigenlijk gebruikte een van onze Microsoft support tickets om ze te helpen bij het oplossen. De optimale pagefile formaat te gebruiken met SQL Server kwam, en de aanbeveling van Microsoft is dat het nu 1 1/2 keer de hoeveelheid RAM .

antwoordde op 10/09/2009 om 06:05
bron van user

stemmen
2

Hoe groter hoe beter tot de omvang van de werkende set van de toepassing waarin u zult beginnen te krijgen in de afnemende meeropbrengst. U kunt proberen om dit te vinden door langzaam verhogen of verlagen van de grootte tot je een significante verandering in de cache hit tarieven. Echter, als de cache hit rate is meer dan 90% of zo bent u waarschijnlijk OK. Over het algemeen moet u een oogje houden op deze op een productie-systeem om ervoor te zorgen dat het niet aan zijn toewijzing van RAM ontgroeid.

antwoordde op 23/12/2008 om 15:45
bron van user

stemmen
1

Na veel onderzoek onze toegewijde SQL Servers met Enterprise x64 op Windows 2003 Enterprise x64 geen pagina bestand.

Gewoon, de pagina-bestand is een cache voor bestanden die wordt beheerd door het besturingssysteem en SQL heeft zijn eigen interne geheugen management systeem.

De MS artikel waarnaar wordt verwezen niet in aanmerking komt dat het advies is voor de OS running out-of-the-box diensten, zoals het delen van bestanden.

Het hebben van een pagina bestand belast gewoon de disk I / O, omdat Windows probeert te helpen, wanneer alleen de SQL OS het werk kan doen.

antwoordde op 24/05/2011 om 13:47
bron van user

stemmen
1

Als u op zoek bent naar hoge prestaties, gaat u wilt vermijden paging volledig, zodat de pagina bestandsgrootte wordt minder belangrijk. Investeer in zoveel RAM als haalbaar is voor de DB server.

antwoordde op 11/08/2008 om 13:22
bron van user

stemmen
0

In dit geval is de normale aanbeveling van 1,5 keer de totale fysieke RAM-geheugen is niet de beste. Deze zeer algemene aanbeveling verschaft onder de aanname dat al het geheugen wordt gebruikt door "normale" werkwijzen, die in het algemeen kunnen hun minst gebruikte pagina verplaatst naar schijf zonder dat enorme prestatieproblemen voor het inschrijven het geheugen behoort.

Voor servers SQL Server (meestal met zeer grote hoeveelheden RAM) wordt het grootste deel van de fysieke RAM inzetten voor de SQL Server-proces en moet (indien correct geconfigureerd) opgesloten in het fysieke geheugen te voorkomen dat het wordt uitgevoerd opgeroepen om pagefile . SQL Server beheert haar eigen geheugen zeer zorgvuldig met de prestaties in het achterhoofd, met behulp van een groot deel van het RAM-geheugen om het proces als een data cache disk I / O te verminderen toegewezen. Het heeft geen zin om pagina uit deze gegevens cache pagina's naar de pagefile, als het enige doel van het hebben van die gegevens in het RAM in de eerste plaats is om disk I / O te verminderen. (Merk op dat het Windows-besturingssysteem maakt ook gebruik van het beschikbare RAM op dezelfde manier als disk cache te versnellen werking van het systeem.) Omdat SQL Server al beheert zijn eigen geheugenruimte, dient deze geheugenruimte niet worden beschouwd als "pagineerbare", en niet in een berekening voor de pagefile grootte.

Met betrekking tot MEM_COMMIT genoemd Remus, de terminologie verwarrend omdat in het virtuele geheugen spraakgebruik "gereserveerde" niet verwijst naar feitelijke samenstelling, maar verhinderen het gebruik van een adresruimte (niet fysieke ruimte) door een ander proces. Geheugen beschikbaar "toegewijd" te zijn is in principe gelijk aan de som van de fysieke RAM-geheugen en pagefile grootte en het doen van een MEM_COMMIT net verlaagt het beschikbare bedrag in de gepleegde zwembad. Het maakt niet een bijpassende pagina toe te wijzen in de pagefile op dat moment. Wanneer een toegewezen geheugen pagina daadwerkelijk wordt geschreven, dat is wanneer het virtueel geheugen systeem een fysiek geheugen pagina zal toewijzen en eventueel bump ander geheugen pagina van fysieke RAM-geheugen naar de pagefile. Zie MSDN's VirtualAlloc functie referentie.

De Windows-besturingssysteem houdt geheugen drukken tussen applicatie processen en zijn eigen disk cache mechanisme en beslist wanneer het niet-afgesloten geheugen pagina's van fysieke naar de pagefile moeten stoten. Ik heb begrepen dat het hebben van een pagefile dat is veel te groot in vergelijking met de werkelijke niet-afgesloten geheugenruimte kan resulteren in Windows overzealously paging uit het geheugen van de pagefile, wat resulteert in die toepassingen lijden onder de gevolgen van de pagina missers (traag).

Zolang de server is niet actief andere geheugen-hongerige processen, zou een pagefile grootte van 4 GB genoeg zijn. Als u SQL Server hebt ingesteld op het vergrendelen van pagina's in het geheugen mogelijk te maken, moet u ook rekening houden met het instellen van SQL Server max geheugen instelling, zodat het aantal fysieke RAM-geheugen beschikbaar om de OS laat voor zichzelf en andere processen.

802 fouten in SQL Server geven dat het systeem niet meer pagina's voor de data cache kan begaan. Het verhogen van de pagefile grootte zal alleen helpen in deze situatie voor zover Windows is in staat om pagina uit het geheugen van niet-SQL Server-processen. Het toestaan ​​van SQL Server geheugen uit te groeien tot de pagefile in deze situatie zou zich te ontdoen van de foutmeldingen, maar het contraproductief is, te wijten aan de punt eerder over de reden voor de data cache in de eerste plaats.

antwoordde op 04/04/2014 om 00:51
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more