Î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.