Megfelelő a Windows O / S lapozófájl mérete az SQL Server

szavazat
16

Létezik-e olyan tudja, egy jó ökölszabály a megfelelő lapozófájl méretét a Windows 2003 szerver fut az SQL Server?

A kérdést 05/08/2008 18:07
a forrás felhasználó
Más nyelveken...                            


8 válasz

szavazat
1

Ha keres a nagy teljesítményt, akkor fog el akarja kerülni lapozás teljesen, így az oldal fájlméret kevésbé jelentős. Fektessen be annyi RAM megvalósítható a DB szerver.

Válaszolt 11/08/2008 13:22
a forrás felhasználó

szavazat
2

Minél nagyobb, annál jobb méretig a dolgozó sor az alkalmazásra, ahol meg fogja kezdeni, hogy bekerüljön csökkenő hasznot. Meg lehet próbálni, hogy megtalálja ezt a lassan növekvő vagy csökkenő mérete, amíg meg nem jelenik egy jelentős változás cache találati arány. Azonban, ha a cache találati arány meghaladja a 90% -ot, vagy akkor valószínűleg az OK gombra. Általában meg kell tartani a szemét ezen a termelési rendszer, hogy biztosan nem kinőtte RAM elosztását.

Válaszolt 23/12/2008 15:45
a forrás felhasználó

szavazat
2

Mi nemrég némi teljesítmény problémák egyik SQL Server, hogy nem voltunk képesek teljesen leszűkítik, és ténylegesen használt egyik Microsoft támogatási jegyeket, hogy azokat segítsen a problémamegoldásban. Az optimális lapozófájl méretét használni az SQL Server jött, és a Microsoft ajánlása az, hogy legyen 1 1/2 alkalommal a RAM mennyisége .

Válaszolt 10/09/2009 06:05
a forrás felhasználó

szavazat
10

Nem fontos a RAM mérete, még mindig szükség van egy lapozófájl legalább 1,5-szer annyi fizikai RAM. Ez akkor is igaz, ha van egy 1 TB RAM gép, akkor kell 1,5 TB lapozófájl lemez (őrültségnek hangzik, de igaz).

Amikor egy folyamat kérdezi MEM_COMMIT memória keresztül VirtualAlloc / VirtualAllocEx, a kívánt méretre kell foglalni a lapozófájl. Ez igaz volt az első Win NT rendszeren, és még ma is igaz látni virtuális memóriát a Win32 :

Amikor a memória elkötelezett, a fizikai oldal a memória kiosztása és hely van fenntartva a lapozófájl .

Csupasz néhány extrém furcsa eseteket, az SQL Server mindig kér MEM_COMMIT oldalakon. És mivel az a tény, hogy az SQL használ Dynamic Memory Management politika fenntartja előre annyi puffer medence lehet (a tartalékok és a követ szempontjából VAS), SQL Server fogja kérni az indításkor egy hatalmas helyfoglalást a lapozófájl. Ha a lapozófájl nem megfelelő méretű hibák 801/802 indul felbukkan az SQL ErrorLog fájlba műveleteket.

Ez mindig okoz némi zavart, mivel az adminisztrátorok tévesen azt gondolják, hogy a nagy RAM szükségtelenné teszi a lapozófájl. Az igazság az ellenkező történik, egy nagy RAM inkább szükség van a lapozófájl, csak azért, mert a belső működését a Windows NT memória menedzser. A fenntartott lapozófájl van, remélhetőleg soha nem használt.

Válaszolt 22/11/2009 23:11
a forrás felhasználó

szavazat
3

A Microsoft szerint „mint a RAM a számítógép növekszik, hogy szükség van egy lapozófájl csökken.” Ezután a cikk folytatja, hogy leírja, hogyan kell használni Performance Naplók, hogy mennyi a lapozófájlja ténylegesen használják. Próbálja meg az oldalt fájlt 1,5X rendszermemória a kezdet, majd tegye a javasolt ellenőrzési és kiigazításokat onnan.

Hogyan határozzák meg a megfelelő oldalon fájl mérete 64 bites Windows-verziók

Válaszolt 03/08/2010 19:58
a forrás felhasználó

szavazat
1

Miután sok kutatást elkötelezett SQL Server fut Enterprise x64 Windows 2003 Enterprise x64 nincs lapozófájl.

Egyszerűen, a lapozófájl egy cache fájlok gets által kezelt operációs rendszer, és az SQL megvan a saját belső memória rendszere.

Az MS hivatkozott cikk nem felel meg, hogy a tanács, az OS fut out-of-the-box szolgáltatások, mint például fájlmegosztás.

Miután a lapozófájl egyszerűen terheli a lemez I / O, mert a Windows próbál segíteni, ha csak az SQL OS is ezt a munkát.

Válaszolt 24/05/2011 13:47
a forrás felhasználó

szavazat
11

Minden tiszteletem a Remus (akit én tiszteletben nagyban), egyáltalán nem értek egyet. Ha a lapozófájl elég nagy ahhoz, hogy támogassa a teljes lerakó, akkor végezzen teljes lerakó minden alkalommal. Ha van egy nagyon nagy mennyiségű RAM, ez is okozhat egy kis felvillanás a lett jelentős kiesés.

Ha nem szeretné, hogy a szervert, hogy, hogy írjon ki 1 TB RAM lemezre, ha van egy egyszeri átmeneti a probléma. Ha van egy visszatérő probléma, akkor növeli a lapozófájl, hogy rögzítse a teljes dump. Azt várom, hogy ezt addig, amíg már isntructed PSS (vagy valaki más képzett elemezni a teljes tároló) kérheti, hogy rögzítse a teljes dump. Egy rendkívül kis százaléka DBAs tudja, hogyan kell elemezni a teljes dump. A mini-dump elegendő ahhoz, hibaelhárítási legtöbb probléma, hogy felbukkan egyébként.

Plusz, ha a szerver úgy van beállítva, hogy 1 TB teljes kiírása és egy visszatérő probléma akkor jelentkezik, mennyi szabad lemezterület azt javasoljuk, hogy a kezét? Lehet, töltse ki a teljes SAN egyetlen hétvége alatt.

A lapozófájl 1,5 * RAM volt a norma vissza a napokat, mikor volt szerencsés, hogy egy SQL Server 3 vagy 4 GB RAM-mal. Ez nem így van többé. Itt hagyom a lapozófájl a Windows alapértelmezett méret és beállításait az összes termelési szerverek (kivéve egy SSAS kiszolgáló memóriaproblémái nyomás).

És csak a pontosítás, akivel valaha dolgoztam szerverek kezdve 2 GB RAM-mal és 2 TB RAM. A több mint 11 éve, már csak meg kellett increae a lapozófájl, hogy rögzítse a teljes lerakó egy időben.

Válaszolt 05/10/2011 22:39
a forrás felhasználó

szavazat
0

Ebben az esetben a normál ajánlása 1,5-szerese a teljes fizikai RAM nem a legjobb. Ez nagyon általános ajánlás van ellátva, feltételezve, hogy minden memória által használt „normál” folyamatokat, amelyek általában a legkevésbé használt átnevezett lapok lemezre anélkül hatalmas teljesítmény problémák a pályázati eljárás a memória tartozik.

A kiszolgálók számára az SQL Server (általában nagy mennyiségű RAM), a többség a fizikai RAM elkötelezett az SQL Server folyamatot, és legyen (ha megfelelően konfigurálva) zárva fizikai memóriát, megakadályozza, hogy kihelyezni a lapozófájl . SQL Server kezeli a saját memóriájában nagyon óvatosan teljesítményt szem előtt tartva, hogy nagy része a RAM memóriát a folyamat, mint egy adat cache csökkentésére lemez I / O. Ez nincs értelme az oldalra ki ezeket az adatokat cache oldalak a lapozófájl, mint az egyetlen célból, hogy ezeket az adatokat a RAM az első helyen, hogy csökkentse lemez I / O. (Megjegyzendő, hogy a Windows operációs rendszer is használja a rendelkezésre álló RAM hasonlóan lemezgyorsítónak, hogy gyorsítsák fel a rendszer működését.) Mivel az SQL Server már kezeli a saját memória, ez memóriaterület nem tekinthető „lapozható”, és nem szerepelnek a számítás lapozófájl méret.

Tekintetében MEM_COMMIT által említett Remus, a terminológia zavaró, mert a virtuális memória szóhasználatban „fenntartott” soha kifejezés tényleges megosztását, hanem használatának megakadályozása egy címtartomány (nem fizikai tér) egy másik folyamat. Rendelkezésre álló memória, hogy „elkötelezett” alapvetően összegével egyenlő a fizikai RAM-ot és lapozófájl méretét, és ezzel a MEM_COMMIT csak eggyel csökkenti a rendelkezésre álló összeg a lekötött medencében. Ez nem nem osztja a megfelelő oldalt a lapozófájl abban az időben. Amikor egy elkötelezett memória az oldal valójában írt, hogy ha a virtuális memória rendszer osztja a fizikai memória oldal és esetleg tolni egy másik memória oldalon fizikai RAM a lapozófájl. MSDN féle VirtualAlloc funkció referencia.

A Windows operációs rendszer nyilvántartja az emlékezet közötti nyomáson alkalmazási folyamattal és saját lemez cache mechanizmus, és úgy dönt, ha kell botlik el nem zárt memória oldalak fizikai a lapozófájl. Úgy értesültem, hogy van egy lapozófájl, hogy túl nagy, mint a tényleges, nem zárva memória okozhat a Windows overzealously lapozás ki alkalmazás memória a lapozófájl, így ezek az alkalmazások következményeitől szenvedő oldal hiányzik (lassú teljesítmény).

Mindaddig, amíg a kiszolgáló nem fut más memória-éhes folyamatok, a lapozófájl mérete 4GB kell sok. Ha beállította az SQL Server, hogy zár lapok a memóriában, akkor is meg kellene vizsgálni beállítás SQL Server max memória beállítást, hogy hagy némi fizikai RAM az operációs rendszer saját maga és más folyamatok.

802 hiba az SQL Server jelzi, hogy a rendszer nem követett el több oldalt az adatok cache. Növelése lapozófájl méretét csak segíteni ebben a helyzetben, amennyiben a Windows képes oldalt ki memóriát nem SQL Server folyamatokat. Amely lehetővé teszi az SQL Server memória nőni a lapozófájl ebben a helyzetben lehet megszabadulni a hibaüzenetek, de nem célravezető, mivel a korábbi pontjánál okáról az adatok cache az első helyen.

Válaszolt 04/04/2014 00:51
a forrás felhasználó

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