Passende Windows O / S pagefile størrelsen for SQL Server

stemmer
16

Har noen vet en god tommelfingerregel for riktig pagefile størrelse for en Windows 2003 server som kjører SQL Server?

Publisert på 05/08/2008 klokken 17:07
kilden bruker
På andre språk...                            


8 svar

stemmer
11

Med all respekt for Remus (som jeg respekterer sterkt), jeg er sterkt uenig. Hvis siden filen er stor nok til å støtte en full dump, vil det utføre en fullstendig dump hver gang. Hvis du har en veldig stor mengde RAM, kan dette føre til en liten blip å ble en stor strømbrudd.

Du ønsker ikke serveren din til å skrive ut en TB RAM til disk hvis det er et engangsforbigående problem. Hvis det er et tilbakevendende problem, kan du øke siden filen for å fange en full dump. Jeg ville vente med å gjøre dette til du har blitt isntructed av PSS (eller noen andre kvalifisert til å analysere en full dump) ber deg om å ta en full dump. En ekstremt liten andel av DBA vet hvordan å analysere en komplett dump. En mini-dump er utelukkes for feilsøking fleste problemer som dukker opp uansett.

Pluss, hvis serveren er konfigurert til å tillate en 1 TB komplett dump og en tilbakevendende problemet oppstår, hvor mye ledig diskplass ville du anbefale å ha på hånden? Du kan fylle opp en hel SAN i en enkelt helg.

En side fil 1,5 * RAM var normen tilbake i de dager da du var heldig å ha en SQL Server med 3 eller 4 GB RAM. Dette er ikke tilfelle lenger. Jeg forlater siden filen på Windows standardstørrelsen og innstillinger på alle produksjonsservere (bortsett fra en SSAS server som opplever minne trykk).

Og bare for avklaring, har jeg jobbet med servere alt fra 2 GB RAM til 2 TB RAM. Etter mer enn 11 år, har jeg bare måtte increae sidevekslingsfilen for å fange en full dump en gang.

Svarte 05/10/2011 kl. 21:39
kilden bruker

stemmer
10

Uavhengig av størrelsen på RAM, du fortsatt trenger en pagefile minst 1,5 ganger mengden fysisk RAM. Dette gjelder selv om du har en 1 TB RAM maskin, trenger du 1,5 TB pagefile på disken (høres sprøtt, men er sant).

Når en prosess ber MEM_COMMIT minne via VirtualAlloc / VirtualAllocEx, må den forespurte størrelsen å være reservert i pagefile. Dette gjaldt i første Win NT-systemet, og er fortsatt sant i dag se Administrere virtuelt minne i Win32 :

Når minnet er begått, er fysiske sider med minne som er tildelt , og plassen er reservert i en pagefile .

Bart noen ekstreme rare tilfeller vil SQL Server alltid be om MEM_COMMIT sider. Og gitt det faktum at SQL bruker en dynamisk minnehåndtering politikk som forbeholder forhånd så mye buffer pool som mulig (reserver og begår i form av VAS), vil SQL Server be ved oppstart en stor bestilling av plass i pagefile. Hvis pagefile er ikke riktig størrelse feil 801/802 vil begynne å dukke opp i SQL er feillogg-fila og drift.

Dette fører alltid en viss forvirring, som administratorer feilaktig anta at en stor RAM eliminerer behovet for en pagefile. I sannhet skjer det motsatte, en stor RAM øker behovet for pagefile, nettopp på grunn av den interne driften av Windows NT minne manager. Reserverte pagefile er, forhåpentligvis, aldri brukt.

Svarte 22/11/2009 kl. 22:11
kilden bruker

stemmer
3

Ifølge Microsoft, "som mengden RAM i en datamaskin øker, behovet for en side fil reduseres." Artikkelen fortsetter deretter med å beskrive hvordan du bruker Ytelseslogger å finne ut hvor mye av siden filen er faktisk blir brukt. Prøv å sette din side fil til 1,5X systemminne for en start, så gjør det anbefalte overvåking og foreta justeringer derfra.

Hvordan finne riktig side filstørrelse for 64-biters versjoner av Windows

Svarte 03/08/2010 kl. 18:58
kilden bruker

stemmer
2

Vi var nylig å ha noen ytelsesproblemer med en av våre SQL Server som vi ikke var i stand til å fullstendig smalt ned, og faktisk brukt en av våre Microsoft-støtte billetter å ha dem hjelpe feilsøke. Den optimale pagefile størrelse å bruke med SQL Server kom opp, og Microsofts anbefaling er at det skal være 1 1/2 ganger mengden RAM .

Svarte 10/09/2009 kl. 05:05
kilden bruker

stemmer
2

Jo større jo bedre opp til størrelsen av arbeids sett programmet der du vil begynne å komme inn avtagende avkastning. Du kan prøve å finne dette ved å sakte øke eller redusere størrelsen til du ser en betydelig endring i cache hit priser. Men hvis cache hit rate er over 90% eller så er du sannsynligvis OK. Vanligvis bør du holde et øye med dette på et produksjonssystem for å sikre at det ikke har vokst ut av sin RAM-tildeling.

Svarte 23/12/2008 kl. 14:45
kilden bruker

stemmer
1

Etter mye forskning våre dedikerte SQL Servere som kjører Enterprise x64 på Windows 2003 Enterprise x64 har ingen side-fil.

Ganske enkelt, er siden filen en cache for filer som blir forvaltet av OS, og SQL har sin egen internminne styringssystem.

MS artikkel refererte kvalifiserer ikke at rådene er for OS kjører out-of-the-box tjenester som fildeling.

Å ha en side fil bare belaster disk I / O fordi Windows prøver å hjelpe, når bare SQL OS kan gjøre jobben.

Svarte 24/05/2011 kl. 12:47
kilden bruker

stemmer
1

Hvis du er ute etter høy ytelse, skal du unngå å bla helt, så størrelsen på siden filen blir mindre viktig. Invester i så mye RAM som mulig for DB server.

Svarte 11/08/2008 kl. 12:22
kilden bruker

stemmer
0

I dette tilfellet er den normale anbefaling på 1,5 ganger totale fysiske RAM ikke den beste. Denne meget generell anbefaling er gitt under forutsetning av at alt minne som brukes ved "normale" prosesser, som vanligvis kan ha sin minste brukte sidene flyttet til disken uten at det dannes store ytelsesproblemer for søkeprosessen minnet tilhører.

For servere som kjører SQL Server (vanligvis med meget store mengder RAM) er hoveddelen av den fysiske RAM forpliktet til SQL Server prosessen og bør være (hvis konfigurert riktig) låst i fysisk minne, og hindrer den fra å bli sidevekslet ut til file . SQL Server styrer sin egen hukommelse svært nøye med ytelse i tankene, ved hjelp av en stor del av RAM allokert til sin prosess som en data cache for å redusere disk I / O. Det gir ikke mening å side ut de data cache sider til pagefile, som den eneste hensikten med å ha disse dataene i RAM i første omgang er å redusere disk I / O. (Merk at Windows OS bruker også tilgjengelig RAM på samme måte som disk cache å fremskynde systemdrift.) Siden SQL Server allerede forvalter sin egen plass i minnet, bør dette minne ikke anses som "sideveksles", og ikke inkludert i en beregning for pagefile størrelse.

I forhold til MEM_COMMIT nevnt av Remus, er terminologien forvirrende fordi i virtuelt-lager språkbruk, "reservert" refererer aldri til selve fordeling, men for å forhindre bruk av en adresseplass (ikke fysisk plass) ved en annen prosess. Minne tilgjengelig for å være "forpliktet" er i utgangspunktet lik summen av fysisk RAM og pagefile størrelse, og gjør en MEM_COMMIT bare svekkelser beløpet tilgjengelig i forpliktende bassenget. Det trenger ikke tildele en matchende side i pagefile på den tiden. Når en engasjert minnesiden er faktisk skrevet til, er at når det virtuelle minnet systemet vil tildele et fysisk minne side og muligens bump annen minneside fra fysisk RAM til pagefile. Se MSDN er VirtualAlloc funksjon referanse.

Windows OS holder styr på minnepress mellom søknadsprosesser og sin egen disk cache mekanisme og bestemmer når det skal støte ikke-låst minne sider fra fysisk til pagefile. Min forståelse er at det å ha en pagefile som er altfor stor i forhold til den faktiske ikke-låst minne kan resultere i Windows overzealously bla ut programminne til pagefile, noe som resulterer i de programmene som lider konsekvensene av siden for målet (tidkrevende).

Så lenge serveren ikke kjører andre minnekrevende prosesser, bør en pagefile størrelsen på 4GB være nok. Hvis du har angitt SQL Server for å tillate låse sider i minnet, bør du også vurdere å sette SQL Server max minne innstillingen slik at det etterlater noen fysiske RAM tilgjengelig for OS for seg selv og andre prosesser.

802 feil i SQL Server tyder på at systemet ikke kan begå flere sider for data cache. Økning av pagefile størrelsen vil bare hjelpe i denne situasjonen så vidt Windows er i stand til side ut minne fra ikke-SQL Server prosesser. Slik at SQL Server minne til å vokse inn i pagefile i denne situasjonen kan bli kvitt feilmeldingene, men det er mot sin hensikt, på grunn av poenget tidligere om årsaken til databufferen i første omgang.

Svarte 03/04/2014 kl. 23:51
kilden bruker

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