Ideal pentru Windows O / S dimensiune pagefile pentru SQL Server

voturi
16

Are orice știu o regulă bună pentru dimensiunea pagefile corespunzătoare pentru Windows 2003 Server SQL server care rulează?

Întrebat 05/08/2008 la 18:07
sursa de către utilizator
În alte limbi...                            


8 răspunsuri

voturi
11

Cu tot respectul pentru Remus (pe care îl respect foarte mult), nu sunt de acord. Dacă fișierul pagina dvs. este suficient de mare pentru a sprijini o groapa de plin, se va efectua o groapa plină de fiecare dată. Dacă aveți o cantitate foarte mare de memorie RAM, acest lucru poate provoca o blip mica a devenit o întrerupere majoră.

Tu nu vrei ca serverul să aibă pentru a scrie 1 TB de RAM pe disc în cazul în care există o problemă tranzitorie o singură dată. Dacă există o problemă recurentă, puteți mări fișierul pagină pentru a captura o groapa plina. Aș aștepta să fac acest lucru până când au fost isntructed de PSS (sau altcineva calificat pentru a analiza un depozit complet) vă cere pentru a captura o groapa completă. Un procent extrem de mic de DBAs știu cum să analizeze o groapa completă. Un mini-benă pentru depanare introduse sunt suficiente cele mai multe probleme care apar oricum.

În plus, în cazul în care serverul este configurat pentru a permite o groapa plina de 1 TB și o problemă recurentă apare, cât de mult spațiu liber pe disc ar vă recomandăm să aveți la îndemână? Ai putea umple un întreg SAN într-un singur week-end.

O pagină de fișier 1.5 * RAM a fost norma înapoi în zilele în care ați fost norocos să aibă un SQL Server cu 3 sau 4 GB de memorie RAM. Acest lucru nu este cazul mai. Am lăsați fișierul pagina la dimensiunea implicită Windows și setările pe toate serverele de producție (cu excepția unui server de SSAS care se confruntă cu o presiune de memorie).

Și doar pentru clarificare, am lucrat cu servere de la 2 GB de RAM la 2 TB de RAM. După mai mult de 11 de ani, am avut doar să increae fișierul de paginare pentru a captura o groapa de plin o singură dată.

Publicat 05/10/2011 la 22:39
sursa de către utilizator

voturi
10

Irelevant de dimensiunea memoriei RAM, ai nevoie de încă un pagefile de cel puțin 1,5 ori mai mare decât cantitatea de memorie RAM fizice. Acest lucru este valabil chiar dacă aveți o mașină de memorie RAM de 1 TB, veți avea nevoie de 1,5 pagefile TB pe disc (pare o nebunie, dar este adevărat).

Atunci când un proces cere de memorie MEM_COMMIT prin VirtualAlloc / VirtualAllocEx, dimensiunea solicitată trebuie să fie rezervat în fișierul de paginare. Acest lucru a fost adevărat în primul sistem Win NT, și este încă adevărat astăzi vedea Gestionarea memoriei virtuale în Win32 :

Când memoria este angajat, paginile fizice de memorie sunt alocate și spațiu este rezervat într - un pagefile .

Bare unele cazuri ciudate extreme, SQL Server va cere întotdeauna pentru paginile MEM_COMMIT. Și având în vedere faptul că SQL utilizează o gestionare dinamică de memorie politică care își rezervă în avans piscină tampon mult posibil (rezervele și se angajează în ceea ce privește SAV), SQL Server va solicita la pornire o rezervă mare de spațiu în fișierul de paginare. Dacă fișierul de paginare nu este corect erorile de dimensiuni 801/802 vor începe să apară în fișierul ErrorLog și operațiunile SQL lui.

Acest lucru face ca întotdeauna unele confuzii, în calitate de administratori în mod eronat să presupunem că o memorie RAM mare elimină necesitatea unui pagefile. Într-adevăr, dimpotrivă se întâmplă, o memorie RAM mare crește nevoia de pagefile, doar din cauza modului de funcționare a managerului de memorie pentru Windows NT. Fișierul de paginare rezervat este, sperăm, nu a folosit niciodată.

Publicat 22/11/2009 la 23:11
sursa de către utilizator

voturi
3

Potrivit Microsoft, „ca cantitatea de memorie RAM într - o crește de calculator, necesitatea unui fișier de pagină a scăzut.“ Articolul apoi merge mai departe pentru a descrie modul de utilizare Jurnale de performanță pentru a determina cât de mult a fișierului de pagini este de fapt utilizat. Încercați să setați fișierul pagină în memorie de sistem 1,5X pentru început, apoi face monitorizarea recomandată și să facă ajustări de acolo.

Cum de a determina dimensiunea corespunzătoare paginii de fișier pentru versiunile pe 64 de biți de Windows

Publicat 03/08/2010 la 19:58
sursa de către utilizator

voturi
2

Recent , am fost cu unele probleme de performanță cu unul dintre noastre SQL Server pe care nu am putut să complet înguste în jos, și de fapt , folosit unul dintre biletele noastre de suport Microsoft pentru a le ajuta la remedierea erorii. Dimensiunea optimă pagefile pentru a utiliza cu SQL Server a venit, și recomandarea Microsoft este ca aceasta să fie de 1 1/2 ori mai mare decât cantitatea de memorie RAM .

Publicat 10/09/2009 la 06:05
sursa de către utilizator

voturi
2

Cu cât mai bine până la dimensiunea setului de lucru al aplicației în care va începe să intre în diminuarea revine. Puteți încerca să găsească acest lucru prin creșterea lentă sau micșorarea dimensiunii până când vedeți o modificare semnificativă a ratelor cache hit. Cu toate acestea, în cazul în care memoria cache a lovit rata este de peste 90% sau cam asa esti, probabil, OK. În general, ar trebui să păstreze un ochi pe acest lucru pe un sistem de producție pentru a vă asigura că nu a depășit alocarea RAM.

Publicat 23/12/2008 la 15:45
sursa de către utilizator

voturi
1

După multe cercetări noastre servere dedicate SQL care rulează Enterprise x64 pe Windows 2003 Enterprise x64 nu au nici un fișier de pagină.

Pur și simplu, fișierul pagină este un cache pentru fișiere care devine gestionate de sistemul de operare, și SQL are propriul sistem de management al memoriei interne, a lui.

Articolul MS face referire nu se califică că sfatul este pentru sistemul de operare care rulează out-of-the-box de servicii, cum ar fi partajarea de fișiere.

Având un fișier pagină pur și simplu împovărează disc I / O, deoarece Windows încearcă să ajute, atunci când numai sistemul de operare SQL poate face treaba.

Publicat 24/05/2011 la 13:47
sursa de către utilizator

voturi
1

Dacă sunteți în căutarea pentru performanță înaltă, aveți de gând să doriți pentru a evita paginarea complet, astfel încât dimensiunea paginii fișierului devine mai puțin semnificativă. Investiți în la fel de mult ca RAM fezabil pentru serverul DB.

Publicat 11/08/2008 la 13:22
sursa de către utilizator

voturi
0

În acest caz, recomandarea normală de 1,5 ori mai mare RAM fizică totală nu este cel mai bun. Această recomandare foarte generală este furnizată în ipoteza că toată memoria este utilizată de procese „normale“, care pot avea, în general, paginile lor puțin utilizate mutat pe disc, fără a genera probleme masive de performanță pentru procesul de aplicare memoria aparține.

Pentru servere care rulează SQL Server (în general, cu cantități foarte mari de memorie RAM), majoritatea RAM fizică este angajată în procesul de SQL Server și ar trebui să fie (dacă este configurat corect) blocat în memoria fizică, împiedicând-o să fie chemat la fișierul de paginare . SQL Server gestionează propria sa memorie foarte atent cu performanță în minte, folosind o mare parte din RAM alocat procesului său ca cache-ul de date pentru a reduce disc I / O. Nu are sens să pagina acele date pagini în cache în fișierul de paginare, ca unic scop de a avea aceste date în memoria RAM, în primul rând este de a reduce disc I / O. (Rețineți că sistemul de operare Windows utilizează de asemenea RAM disponibile în mod similar ca disc de memorie cache pentru a accelera funcționarea sistemului.) Deoarece SQL Server administrează deja propriul spațiu de memorie, acest spațiu de memorie nu ar trebui să fie luate în considerare „paginabilă“, și care nu sunt incluse într-un calcul pentru pagefile mărimea.

În ceea ce privește MEM_COMMIT menționat de către Remus, terminologia este confuz , deoarece în limbajul de memorie virtuală, „rezervată“ nu se referă la alocarea efectivă, ci pentru a preveni utilizarea unui spațiu de adrese (spațiu nu fizic) de un alt proces. Memorie disponibilă pentru a fi „angajat“ este , în principiu egal cu suma de RAM și pagefile mărimea fizică, și de a face o MEM_COMMIT doar decrementează suma disponibilă în piscină angajată. Aceasta nu nu alocă o pagină de potrivire în fișierul de paginare de la acel moment. Când o pagină de memorie angajat este , de fapt scris, adică atunci când sistemul de memorie virtuală va aloca o pagină de memorie fizică și , eventual , sa o altă pagină de memorie din memoria RAM fizic la fișierul de paginare. Consultați MSDN funcția VirtualAlloc de referință.

Sistemul de operare Windows ține evidența presiunilor de memorie între procesele de aplicare și propriul mecanism de cache pe disc și decide când trebuie să scapam de pagini care blocate de memorie de la fizic la fișierul de paginare. Înțelegerea mea este că a avea un pagefile, care este mult prea mare în comparație cu spațiul real non-blocat de memorie poate avea ca rezultat în Windows paginare în memorie cu mult zel aplicație pentru fișierul de paginare, care rezultă în acele aplicații care suferă consecințele ratări ale paginii (performanță lentă).

Atâta timp cât serverul nu se execută alte procese de memorie-e foame, o dimensiune pagefile de 4 GB ar trebui să fie o multime. Dacă ați setat SQL Server pentru a permite paginilor de blocare în memorie, ar trebui să ia în considerare, de asemenea, stabilirea de setare de memorie max SQL Server, astfel încât lasă unele memorie RAM disponibilă pentru sistemul de operare pentru sine și alte procese.

802 erori în SQL Server indică faptul că sistemul nu poate comite mai multe pagini pentru cache-ul de date. Creșterea dimensiunii pagefile va ajuta doar în această situație în măsura în care Windows este în măsură să pagină din memorie din procesele non-SQL Server. Permiterea SQL Server de memorie să crească în fișierul de paginare în această situație s-ar putea scapa de mesajele de eroare, dar este contraproductiv, din cauza punctului anterior despre motivul pentru cache-ul de date, în primul rând.

Publicat 04/04/2014 la 00:51
sursa de către utilizator

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