Physical Address Extension(PAE) og Address Windowing Extensions (AWE) på 32-bits OS

Generelt

PAE brukes for å gi operativsystemet tilgang til fysisk minne ut over 4GiB. Prosessorer som støtter dette har en adressebuss på 4 ekstra linjer på adressebussen, altså 36bits adressering. Dette gir en teoretisk mulighet til å adressere totalt 64GiB minne. Det virtuelle adresserommet er dog fortsatt 4GiB, men siden disse rommene tildeles per applikasjon får man utnyttet minnet. Dersom en enkelt applikasjon trenger mer enn 4GiB må man bruke AWE for å få tilgang på mer minne. AWE støtte må legges inn i programmet. AWE gir tilgang til flere vinduer mot fysisk minne, som hver er kan være opptil 4GiB. AWE har enkelte begrensinger, bl.a. kan ikke AWE minne deles mellom applikasjoner.
Det er verdt å merke seg at selv om hver prosess uten AWE har et 4GiB adressevindu, er det normalt bare 2GiB som er tilgjengelig for applikasjonen (se 4GT under).

4-Gigabyte tuning (4GT), også kalt /3GB

Som nevnt har 32 bits prosesser vanligvis bare tilgang til 2GiB av det 4Gib adressevinduet det får tildelt. Resten er reservert til operativsystemet. Dersom en server kjører minneintensive programmer (SQL etc) kan det være en fordel å endre dette slik at 3GiB reserveres til prosessen, og bare 1GiB til operativsystemet. Dersom serveren derimot primært kjører nettverksintensive eller filintensive applikasjoner kan dette føre til redusert ytelse.
Om du bruker /PAE og de intensive applikasjonene på serveren bruker /AWE bør du ikke bruke 4GT, da det kan redusere ytelsen. Dersom du har mer enn 16GiB fysisk minne skal 4GT ikke benyttes.
Dersom du får rare feilmeldinger relatert til Paged Pool memory eller Page table entries, deaktiver 4GT eller reduser /USERVA verdien. Man kan også med fordel gjøre memory manager mer aggressiv ved å legge inn følgende registernøkkel:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session  Manager\Memory Management
DWORD value PoolUsageMaximum = 60(decimal)

Dette vil gjøre at memory manager begynner å frigjøre minne i Paged Pool når den når 60% bruk. Standardverdien er 80%. Dette kan gjøre at ytelsen går litt ned, men man slipper at systemet krasjer på grunn av manglende kernelminne. Se KB312362 for detaljer.

Aktivere PAE

PAE aktiveres ved å legge til en /PAE switch i boot.ini. På windows server 2008 kan dette gjøres ved hjelp av kommandoen <pre>bcdedit /set pae forceenable</pre>.
Pass på å fjerne eventuelle ”/NOPAE”

Aktivere AWE

Dette varierer fra applikasjon til applikasjon. Vær obs på at selv om de fleste versjoner av MSSQL Server 2005 og nyere støtter AWE, så er det kun støttet i Enterprise-versjonen av MSSQL 2000.

Aktivere 4GT

Legge inn en /3GB switch i boot.ini, eventuelt legg inn en /USERVA XXXX, der XXXX er en verdi mellom 2048 og 3072 for å sette en mellomverdi.

Koble til en WSUS database med SQL Management studio

WESUS bruker en Windows Internal Database (WYukon) databasemotor. Dette er en embedded versjon av SQL server som gjerne ikke har management verktøy tilgjengelig. Dette er en smule upraktisk når man feks vil begrense minnebruk eller sjekke databaseintegritet. Som standard er den ikke aktivert for hverken remote eller lokal tilgang heller, så man må installere en versjon av SQL server management studio lokalt på WSUS-serveren og bruke et spesielt instansnavn:

 \\.\pipe\mssql$microsoft##ssee\sql\query

TS Tools v 3.9

Endelig har jeg funnet den godt skjulte lite dokumenterte funksjonen som gjør at programmet husker innstillingene fra forrige versjon når man oppgraderer til en ny versjon.

Ellers har programmet fått en funksjon som kontrollerer Pagefile størrelsen på alle aktive servere (Misc Macros, WMI Queries, Pagefile VS RAM). Denne sjekker størrelsen på synlig fysisk minne og totalstørrelsen på det virtuelle og sammenligner for å kalkulere “PFFactor”, som er størrelsen på pagefile målt i antall ganger synlig fysisk minne. Dvs, om man har 4GB ram og ei pagefile på 6GB er faktoren 1,5.  Pga at noe av minnet ikke er tilgjengelig for operativsystemet får vi sjelden slike fine tall, men en faktor som er litt mindre, feks 1,46.

På W2k3 server er anbefalt faktor 1.5 når man ser på fysisk minne, dvs at en faktor over 1,45 normalt betyr at  alt er ok . Om man er i tvil kan man lett sjekke anbefalt og virkelig verdi ved å gå inn på serveren det er tale om, se detaljer her.

Optimalisering

Anbefalinger, vanlige feil og løsninger

Informasjon og anbefalinger

Her finner du en del teknisk info og anbefalinger basert på erfaring. Kapittelet om løsninger forutsetter at du har lest dette kapittelet først.

Logiske/fysiske disker, oppdeling

Operativsystemet bør alltid ha en egen disk, fortrinnsvis C:. Man bør unngå å installere programvare på denne som ikke er en del av operativsystemet, og brukerdata skal fortrinnsvis ikke ligge her.

Brukerdata, det være seg dokumenter, profiler eller annet bør plasseres på en egen disk, for eksempel D:. Dette gjør at logiske feil på operativsystemdisken ikke like lett påvirker brukerdata, og forenkler senere utvidelse av kapasitet. (strømbrudd etc).

Om man bare har en fysisk disk eller ett raid array så er dette tilstrekkelig. Videre inndeling gir ingen særlig ytelsesgevinst. Har man derimot flere fysiske disker/array bør man lese videre. I det følgende brukes fysisk disk som betegnelse, men de samme fordeler gjelder for raid array, dvs ett array kan likestilles med en disk.

En logisk disk gir derimot ikke samme ytelsesforbedring dersom det er mer enn en logisk disk per array. Det samme gjelder for partisjoner på fysiske disker, det å dele opp en disk i flere partisjoner har liten innvirkning på ytelsen.

Databaser bør lagres på egen fysisk disk. Dersom databaseserveren har høy belastning bør videre oppdeling vurderes slik at transaksjonslogger og databasefiler splittes på egne fysiske disker.

Profiler, fellesområder og hjemmekataloger kan og med fordel skilles ut. Dersom man har mange brukere bør man splitte opp videre.

Active Directory kan også få egne fysiske disker, men om man har så mange brukere at man vurderer det, bør man heller splitte det ut på en egen server

Ledig plass

Operativsystemdisk bør aldri fylles mer enn 60%. Dersom dette skjer vil fragmentering av filer på disken akselerere drastisk, og det hjelper ikke å slette filer igjen. Det vil også medføre problemer med MFT, se eget kapittel. Operativsystemdisken bør for øvrig være på minst 75GB til W2k3.

Datadisker kan fylles til 80%, da fragmenteringsproblematikken vanligvis avgjøres av hvilken type data det er tale om. Ved 80% må man utvide kapasiteten. Datadisker med stor filtrafikk/mange endringer bør ha mer ledig plass.

  • >60% brukt = Fragmentering øker, permanent ytelsestap
  • >80% brukt = enda verre ytelse
  • >90% brukt = fare for systemfeil og datatap
  • >99% brukt = feil oppstår når som helst

MFT og MFT Zone

(Master File Table) er NTFS filsystemets innholdsfortegnelse og metadatakatalog. Den holder styr på hvilke filer som er lagret hvor og data om filene som navn, tillatelser, endringsdato osv. Denne er delt i 2 logiske deler, selve MFT og MFT Zone. MFT Zone er plass på disken som er reservert for utvidelse av MFT. Dersom MFT blir full, utvides den inn i MFT zone, slik at MFT blir litt større og MFT Zone litt mindre. Størrelsen på MFT Zone varierer, tidligere var standardverdien 12,5% av diskstørrelsen, men store disker og større filer har gjort at dette kan bli vel voldsomt. Dersom disken blir full vil filer bli lagret også i MFT Zone som da blir mindre. Dersom MFT blir fragmentert vil det få store konsekvenser for ytelsen. Om MFT Zone blir for liten kan man også oppleve en situasjon der det ikke er mulig å legge til filer på disken selv om det er ledig plass, fordi det ikke er plass til flere MFT entries.

NTFS Begrensinger

Navn: En absolutt sti (For eksempel C:\temp\test.txt) kan inneholde opptil 32767 tegn (UTF-16). En enkelt mappe eller fil kan ha et navn på opptil 255 tegn.

Filstørrelse: Teoretisk maksimum er 16EiB (Exabyte, 1024 basert)

Volumstørrelse: Teoretisk maksimum er 264 – 1 clustere, men i WinXP er den implementert med 232 – 1 clustere. Med en clusterstørrelse på 4KiB får man 16TiB.

Virtuelt minne og pagefile.sys

Når Windows installeres vil det lage en fil kalt pagefile.sys på rot systemvolumet, vanligvis på C:. Denne har en størrelse som kalkuleres ut fra hvor mye fysisk minne som er installert. Dersom man installerer mer fysisk minne blir ikke denne justert automatisk. Det vil medføre lavere ytelse, i ekstreme tilfeller kan ytelsen faktisk gå ned når man installerer mer fysisk minne. Derfor må man korrigere dette manuelt.

Innstillingen ligger under Systemegenskaper, Avansert, Ytelse, Avansert, Virtuelt minne, Endre. Anbefalt størrelse vises da på skjermen, og man kan velge øvre og nedre grense. Anbefaler at nedre grense settes lik anbefalt verdi, og at øvre grense settes til nedre grense * 1,5 for å hindre at pagefile.sys blir fragmentert. Om man har plassproblemer kan man plassere pagefile.sys på en annen disk enn systemdisken, men dette anbefales ikke. Det er dog bedre med pagefile.sys på en egen disk enn med en pagefile.sys som er for liten.

Se http://tweakhound.com/xp/virtualmemory.htm for informasjon om hvorfor du trenger en pagefile.sys uansett hvor mye fysisk minne du har.

Dersom du har 64 bits Windows 2008 eller nyere kan du bruke en mindre pagefile. Du kan sjekke hvor stor den bør være ved å installere Process Explorer (www.sysinternals.com), la den gå et par dager når serveren er under last, og deretter sjekke Peak Commit Charge. Det angir den høyeste summen av fysisk og virtuelt minne som har vært i bruk. Legg på 8Gib og trekk fra størrelsen på fysisk minne så har du et fint utgangspunkt.

image

MS SQL server minnekonfigurasjon

Verdiene det refereres til under har de offisielle navnene ”max server memory” og ”min server memory”.

MS SQL server skal egentlig være i stand til å håndtere minneallokering automatisk. Erfaring viser dog at dette er en sannhet med modifikasjoner. Standardinnstillingen for størrelsen på minnebufferen er fra 0 til størrelsen på fysisk minne, dvs om du har 4GiB RAM så settes den til 0-4GiB. Over tid vil derfor minnebruken på en slik server nærme seg fysisk RAM.

Dette er vanligvis ikke noe problem for operativsystemet, siden operativsystemet krever mer minne ved behov og får det rimelig kjapt, men ved høy belastning kan dette bli en flaskehals. Dersom det er andre programmer installert på maskinen som ikke ber om mer minne men bare tar det de får ved oppstart vil problemet bli desto større, siden disse programmene da kan få særs lite minne tildelt og muligens ikke vil fungere.

For å unngå slike problemer bør man alltid stille maksimalverdien slik at det er noen hundre MiB fysisk minne ledig ved normal belastning. Dette sikrer at man alltid har litt minne tilgjengelig for andre prosesser og for å ta unna topper. Dersom serveren har installert andre tjenester som kan kreve store ressurser bør man redusere maksverdien ytterligere. Samme problemet oppstår om man har mer enn en SQL server instans på samme maskin. For å finne de riktige verdiene må man overvåke minnebruken over tid.

Det er og viktig å være klar over at dette kun regulerer bufferstørrelsen, SQL tjenesten bruker også annet minne.

Minimumsverdien bør settes en del under maksverdien for å sikre at det alltid er minne som kan frigjøres om behovet skulle oppstå, samtidig som det ikke bør være 0 om man ønsker å prioritere SQL ytelse. 75% av maksverdien er et passelig tall.

Dersom serveren har en annen hovedoppgave og SQL tjenesten bare fyller en birolle stiller det seg annerledes. Man bør da sette maskverdien betydelig lavere. Skulle SQLserver tjenesten komme opp i en minnebruk som går over maksverdien samtidig som serveren har lite minne tilgjengelig generelt sett bør man sette inn mer minne og øve maksverdien. Om den derimot aldri når minimumsverdien kan man trygt redusere verdiene.

Løsninger

Dersom du ikke har fulgt anbefalingen over og lurer på om du har støtt på noen av de problemene som da kan oppstå finner du noen løsninger her.

Filfragmentering

Alle disker blir før eller siden rammet av filfragmentering, uavhengig av hvilket filsystem som benyttes. NTFS inneholder rutiner som forsøker å redusere dette bl.a. ved å reservere plass rundt ei fil slik at den kan vokse litt, men etter hvert som disken fylles eller endringene blir mange vil fragmentering oppstå. Windows 2K og nyere har innebygget et defragmenteringsprogram som også kan fortelle deg hvor ille ståa er.(Tilbehør, Systemverktøy, Diskdefragmentering) Bruk defragmenteringsfunksjonen for å forsøke å rydde opp, kjør den eventuelt flere ganger.

Om dette ikke hjelper, eller om det dreier seg om en server med stor belastning som fort blir fragmentert igjen, vurder å anskaffe et helautomatisk defragmenteringsverktøy som Execsoft Diskeeper.

MFT fragmentering

Bruk NTFSInfo sammen med diskdefragmentering for å finne tilstanden på MFT og MFT Zone. NTFSInfo kan lastes ned her: http://technet.microsoft.com/en-us/sysinternals/bb897424.aspx .

Resultat av ntfsinfo c:

NTFS Information Dump V1.01
Copyright (C) 1997 Mark Russinovich
http://www.sysinternals.com
Volume Size
-----------
Volume size : 152617 MB
Total sectors : 312560576
Total clusters : 39070072
Free clusters : 26494752
Free space : 103495 MB (67% of drive)
Allocation Size
----------------
Bytes per sector : 512
Bytes per cluster : 4096
Bytes per MFT record : 1024
Clusters per MFT record: 0
MFT Information
---------------
MFT size : 110 MB (0% of drive)
MFT start cluster : 786432
MFT zone clusters : 814624 - 5670208
MFT zone size : 18967 MB (12% of drive)
MFT mirror start : 19535036
Meta-Data files
---------------

Det er MFT Zone size som er det interessante i dette tilfellet. I eksempelet er den på 12% av diskstørrelsen og enorme 18,9GB og alt er i orden.

En analyse fra diskdefragmentering vil fortelle deg hvor stor del av MFT som er i bruk og hvorvidt den er fragmentert. Du kan få dette kjapt ved å kjøre kommandoen defrag c: -a –v. Eksempel på MFT delen av rapporten:

Fragmentering av hovedfiltabell (MFT - Master File Table)
Total MFT-størrelse = 110 MB
Antall MFT-poster = 108 425
Prosent MFT i bruk = 96
MFT fragmenter totalt = 2

Dette er et rimelig normalt resultat. Vanligvis vil MFT ha være på rundt 90% såfremt disken har vært i bruk ei stund og inneholder litt data, og MFT ha 2 fragmenter. Dersom MFT har flere fragmenter vil du få en betydelig redusering av ytelsen. Og skulle MFT Zone ha en størrelse som er mindre enn halvparten av MFT er det også et tegn på at noe er galt.

For å korrigere dette har man to alternativer: Enten formatere og legge tilbake data fra backup eller anskaffe et kommersielt defragmenteringsprogram som kan defragmentere MFT.

Du kan gjøre MFT Zone større på følgende måte:

  1. Kjør kommandoen fsutil behavior set mftzone n, der n er et tall fra 1-4. Større tall gir større sone, men 1 forsøker på XP å gi en sone på 12% noe som skulle være tilstrekkelig i de fleste tilfeller.
  2. For å få MFT Zone til å vokse, kopier inne noen filer slik at MFT blir full. Da vil systemet sjekke verdien som er satt over og forsøke å endre størrelsen på MFT Zone samtidig som MFT vokser med noen MB.

Dette løser dog ikke fragmenteringsproblemet du har, men vil gjøre sjansen mindre for at det skjer igjen, såfremt du ikke fyller opp disken igjen.

Pagefile.sys fragmentering

For å finne ut om pagefile.sys fila på en disk er fragmentert, kjør kommandoen defrag c: -a –v. Eksempel på Pagefile delen av rapporten:

Pagefile fragmentation
Pagefile size = 9,00 GB
Total fragments = 2

Her har man altså en pagefile.sys i 2 deler. Dette er ikke bra, den bør fortrinnsvis være i en del. Defragmentering krever at disken har et sammenhengende filområde stort nok til å holde pagefile.sys, så defragmenter vanlige filer først. For å defragmentere pagefile.sys må man ha spesielle verktøy, som Diskeeper eller Sysinternals PageDefrag (http://technet.microsoft.com/en-us/sysinternals/bb897426.aspx).

MSSQL på 32bits W2K3 server med mer enn 4GiB fysisk RAM

For å utnytte minne over 4GiB på 32Bits versjonen av w2k3 server må man slå på støtte for dette. Vær obs på at de forskjellige utgavene av w2k3 server har begrensinger for hvor mye minne de støtter. Man trenger også en cpu med støtte for PAE. For å slå det på utfør fålgende:

  1. Legg til en /PAE switch i Boot.ini (krever omstart).
  2. Kjør følgende tsql kommandoer:
    sp_configure 'show advanced options', 1
    RECONFIGURE
    GO
    sp_configure 'awe enabled', 1
    RECONFIGURE
    GO
    sp_configure 'max server memory', 7000 -–Verdien anbefales satt til Fysisk RAM – 1GiB på en dedikert sql server men dette må testes
    RECONFIGURE
    GO
  3. Du kan sjekke resultatet med følgende tsql
    USE master;
    GO
    EXEC sp_configure 'show advanced option', '1';
    RECONFIGURE;
    EXEC sp_configure;

TS Tools v1.7

  • Makro for å sjekke Suppress duplicate eventlog entries
  • Makro for å sette i Headless i System\CurrentControlSet\Services\i8042prt\Parameters til 1 for å ommgå feilmelding i eventlog ved boot.
  • Sjekker alle verdier under en nøkkel når man ikke angir value
  • Jobba en del med effektivisering og rydding i kode

TS Tools V1.4.3305

Advanced filecheck

Søker gjennom alle mapper som ligger ett nivå under mappe x etter en gitt fil, med støtte for minimumsstørrelse. Denne funksjonen er primært tenkt for å rote rundt i brukerprofiler og andre lignende mappestrukturer der man har ei mappe som inneholder et sett undermapper med lignende struktur. Man kan legge inn prefix og suffix i resultatet, og dermed bygge et skript for for eksempel å slette brukerregister over en gitt størrelse.

Lagt til makroer for å bygge skript:

Slette ntuser.dat filer (bruker advanced filecheck)
Slette cachede brukerprofiler med delprof (sendes til clipboard)

Minidump analyse etter blåskjerm

Last ned microsoft debugging tools, og installer om du ikke har dem allerede. Microsoft liker å flytte rundt på debugging tools, sist jeg lastet ned (november 2011) var de en del av Windows SDK for Windows 7.

  1. Kjør C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe (Lokasjon kan variere med hvor man lastet ned fra)
  2. Trykk Ctrl+D for å åpne en dumpfil
  3. kd> .sympath cache*c:\Symbols;srv*http://msdl.microsoft.com/download/symbols
  4. kd> .logopen [sti til og navn på loggfil]
  5. kd> .reload;!analyze -v;r;kv;lmnt;.logclose

Nå skal du ha ei snasen loggfil et sted som inneholder ei røys med info. MODULE_NAME og IMAGE_NAME er overskrifter som ofte viser til programmet/driveren som er synderen.

MDOP DaRT kan også med fordel benyttes dersom du har tilgang på det (lisensbasert). Den gir et veiviserbasert grensesnitt som er betraktelig lettere å jobbe med og som er i stand til å identifisere de fleste driverproblemer.

Stakkanalyse

imagePlukket opp et nyttig tips fra Mr. Russinovich: for å få mer info om prosesser på stakken kan man kjøre “dps [stakkadresse]”, og deretter fortsette å kjøre dps uten argument et par ganger dersom man ikke finner noe på første runde. Dette kan hjelpe til å identifisere tredjepartsdrivere uten korrekt symbolinformasjon.