Mărimea corespunzătoare a paginii O / S pentru Windows Server

Recent am avut câteva probleme de performanță cu unul din serverul nostru SQL, pe care nu am reușit să-l restrângem în totalitate și, de fapt, am folosit unul dintre biletele de suport Microsoft pentru a le ajuta să depisteze problemele. Dimensiunea optimă a paginii de pagină pentru a fi utilizată cu SQL Server a apărut, iar recomandarea Microsoft este să fie 1 1/2 ori suma RAM .

Dacă nu aveți importanță pentru dimensiunea memoriei RAM, aveți nevoie de un fișier de pagină cel puțin de 1,5 ori mai mare decât valoarea RAM fizică. Acest lucru este valabil chiar dacă aveți o mașină RAM de 1 TB, veți avea nevoie de un fișier de pagină de 1,5 TB pe disc (sună nebun, dar este adevărat).

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

Când memoria este angajată, fizică   paginile de memorie sunt alocate și   spațiul este rezervat într-un fișier de pagină .

Bare unele cazuri extrem de ciudat, SQL Server va cere intotdeauna pentru MEM_COMMIT pagini. Și având în vedere faptul că SQL utilizează o politică Gestionarea dinamică a memoriei care rezervă în avans cât mai mult posibil (rezerve și comitete în ceea ce privește VAS), SQL Server va cere la pornirea unei rezervări imense de spațiu în fișierul de pagină. Dacă fișierul de pagină nu este corect dimensionat, erorile 801/802 vor începe să apară în fișierul și operațiile ERRORLOG din SQL.

Aceasta întotdeauna cauzează o anumită confuzie, deoarece administratorii în mod eronat presupun că un RAM mare elimină necesitatea unui fișier de pagină. În realitate se întâmplă contrariul, un RAM mare mărește nevoia de pagini de pagină, doar din cauza funcționării interioare a managerului de memorie Windows NT. Dosarul de pagini rezervat este, sperăm, niciodată folosit.

Potrivit Microsoft, "deoarece volumul de memorie RAM într-un calculator crește, nevoia de reducere a unui fișier de pagină". În continuare, articolul descrie modul de utilizare a jurnalelor de performanță pentru a determina cât de mult din fișierul de pagină este de fapt utilizat. Încercați să setați fișierul de pagină în memoria de sistem 1.5X pentru început, apoi efectuați monitorizarea recomandată și efectuați ajustări de acolo.

Cum se determină dimensiunea adecvată a fișierului de pagină pentru versiunile pe 64 de biți de Windows

Cu cat este mai mare, cu atat mai mult pana la dimensiunea setului de lucru al aplicatiei in care veti incepe sa ajungeti in randamentele diminuate. Puteți încerca să găsiți acest lucru crescând sau micșorând lent dimensiunea până când veți vedea o schimbare semnificativă în ratele de cache-hit. Cu toate acestea, dacă rata de succes a cache-ului este peste 90%, probabil că sunteți în regulă. În general, ar trebui să țineți cont de acest lucru pe un sistem de producție pentru a vă asigura că nu a depășit alocarea RAM.

Dacă doriți o performanță ridicată, veți dori să evitați să efectuați pagini complet, astfel încât dimensiunea fișierului paginii devine mai puțin semnificativă. Investiți în cât mai multă memorie RAM posibilă pentru serverul DB.

După multă cercetare, serverele dedicate SQL care rulează Enterprise x64 pe Windows 2003 Enterprise x64 nu au nici un fișier de pagină.

Pur și simplu, fișierul de pagină este o memorie cache pentru fișierele care sunt gestionate de sistemul de operare, iar SQL are propriul sistem de gestionare a memoriei interne.

Articolul din MS la care se face referire nu califică faptul că sfatul este pentru sistemul de operare care rulează în afara serviciilor, cum ar fi partajarea de fișiere.

Având un fișier de pagină pur și simplu încarcă discul I / O deoarece Windows încearcă să ajute, când numai sistemul de operare SQL poate face lucrarea.

Cu tot respectul față de Remus (pe care îl respect foarte mult), nu sunt deloc de acord. Dacă fișierul dvs. de pagină este suficient de mare pentru a suporta un depozit complet, acesta va efectua o încărcare completă de fiecare dată. Dacă aveți o cantitate foarte mare de memorie RAM, acest lucru poate provoca o scurtă blip pentru a deveni o întrerupere majoră.

Nu doriți ca serverul dvs. să scrie 1 TB de memorie RAM dacă există o problemă tranzitorie unică. Dacă există o problemă recurentă, puteți crește fișierul de pagină pentru a captura o greșeală completă. Aș aștept să fac acest lucru până când ați fost înființat de PSS (sau altcineva calificat să analizeze o dumpă completă) vă solicită să capturați o groapă completă. Un procent extrem de mic de DBA-uri știu cum să analizeze o dumpă completă. Un mini-dump este suficient pentru depanarea majorității problemelor care apar oricum.

În plus, dacă serverul dvs. este configurat să permită o memorie completă de 1 TB și apare o problemă recurentă, cât spațiu liber pe disc le-ați recomanda la dispoziție? Ai putea umple un întreg SAN într-un singur weekend.

Un fișier de pagină 1.5 * RAM a fost norma înapoi în zilele când ați avut norocul de a avea un server SQL cu 3 sau 4 GB de memorie RAM. Nu mai este cazul. Am lăsat fișierul de pagină la dimensiunea și setările implicite Windows pe toate serverele de producție (cu excepția unui server SSAS care se confruntă cu presiune în memorie).

Și doar pentru clarificare, am lucrat cu servere variind de la 2 GB de RAM la 2 TB de RAM. După mai mult de 11 ani, am fost nevoit să introduc doar fișierul de paginare pentru a captura o singură încărcare completă o singură dată.

În acest caz, recomandarea normală de 1,5 ori total RAM fizic nu este cea mai bună. Această recomandare foarte generală este furnizată presupunând că toată memoria este folosită de procese "normale", care pot fi mutate în general pe paginile cele mai puțin utilizate, fără a genera probleme de performanță masive pentru procesul de aplicare al memoriului.

Pentru serverele care execută SQL Server (în general, cu cantități foarte mari de RAM) majoritatea RAM-ului fizic se angajează în procesul SQL Server și ar trebui să fie blocată (dacă este configurată corect) în memoria fizică, împiedicându-i să fie pagerate în fișierul de pagină . SQL Server își gestionează memoria proprie foarte atent, având în vedere performanța, folosind o mare parte din memoria RAM alocată procesului său ca o cache de date pentru a reduce dischetele I / O. Nu are sens să afișați paginile cache-ului de date în fișierul paginii, deoarece singurul scop al acestor date în memoria RAM este de a reduce discul I / O. (Rețineți că sistemul de operare Windows utilizează, de asemenea, o memorie RAM disponibilă ca și cache-ul pentru a accelera funcționarea sistemului.) Deoarece SQL Server își gestionează deja propriul spațiu de memorie, acest spațiu de memorie nu ar trebui considerat "vizibil" și nu este inclus într- mărimea.

În ceea ce privește memoria MEM_COMMIT menționată de Remus, terminologia este confuză deoarece, în memoria virtuală, "rezervat" nu se referă niciodată la alocarea reală, ci la împiedicarea utilizării unui spațiu de adresă (nu a unui spațiu fizic) printr-un alt proces. Memoria disponibilă pentru a fi "angajată" este, în esență, egală cu suma RAM-ului fizic și a mărimii paginii, iar efectuarea unui MEM_COMMIT scade doar suma disponibilă în grupul de angajamente. nu alocă o pagină de potrivire în fișierul de pagină la momentul respectiv. Atunci când o pagină de memorie dedicată este de fapt scrisă, atunci atunci când sistemul de memorie virtuală va aloca o pagină de memorie fizică și, eventual, va bate o altă pagină de memorie din RAM fizic în fișierul de pagină. Vedeți referința Funcția VirtualAlloc a MSDN.

Sistemul de operare Windows monitorizează presiunile de memorie dintre procesele de aplicație și mecanismul propriu de stocare a cache-ului și decide când trebuie să strice paginile de memorie neînchise de la fizic la fișierul de pagină. Înțelegerea mea este că un fișier de pagină care este mult prea mare în comparație cu spațiul de memorie real fără blocare poate determina ca Windows să pagerage în mod exagerat memoria aplicației în fișierul paginii, rezultând astfel că acele aplicații suferă consecințele pierderilor de pagină (performanță lentă).

Atâta timp cât serverul nu rulează alte procese care suferă de memorie, o dimensiune a paginii de 4 GB ar trebui să fie suficientă. 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 alte pagini pentru cache-ul de date. Creșterea mărimii paginii de pagină va ajuta doar în această situație, în măsura în care Windows este capabil de a afișa memorie din procesele non-SQL Server. Permițând ca memoria SQL Server să crească în fișierul de pagină în această situație ar putea scăpa de mesajele de eroare, dar este contraproductivă, din cauza punctului anterior despre motivul cache-ului de date în primul rând.