Destul de mult timp ne-am luptat pentru programul WinDraw de performanță. și anume, pentru interacțiunea dintre WinDraw și MS SQL Server.
În timpul acestei lupte, am făcut mai multe descoperiri importante:
1. Utilizarea dbo.ZipUnPack în interogări (care este, pe partea de SQL Server) Builder Stimulsoft Reports.Net rapoarte a condus la faptul că eroarea System.OutOfMemoryException apare mult mai frecvent. Transferul punerea în aplicare a acestei metode pe partea de server a aplicației (de exemplu, folosind Atechnology.Components.ZipArchiver.UnZip2 (byte [] classnative)), ne-am crescut în mod semnificativ activitatea SQLServer de timp fără a restarta.
Pentru toate aceste motive, și multe sfaturi pe internet (dar de cele mai multe sfaturi referit la activitatea 1C program cu SQL Server, dar problema a fost foarte similar cu al nostru) - Sa decis să încerce să utilizeze platforma x64 și software-ul.
Pentru mai mult de o lună, nu am primit System.OutOfMemoryException eroare. în timp ce memoria RAM este folosit aproape în întregime!
Pe această bază setul de software consideră că este necesar, în același timp, accesul la SQL Server pentru mai mult de 30 de utilizatori.
ZY În viitorul apropiat vom încerca să activați opțiunea Address Windowing Extensions (AWE) și să descrie rezultatul!
Un pic de informații tehnice!
Mecanismul de adrese Windowing Extensions (AWE), utilizate în SQL Server, este format din două părți, alocă memorie fizică, și afișează pe un spațiu de adrese virtuale (VAS) a procesului. În cazul în care memoria fizică este alocată, sistemul de operare nu va fi capabil să-l solicite, în timp ce utilizarea acestuia nu este procesul este finalizat sau procesul va elibera memoria returnat sistemului său de operare. Aplicația poate gestiona și chiar preveni complet flipping. cartografiere / mecanism de unmapping avantaj faptul că una și aceeași pagină fizică pot fi afișate pe diferite părți ale SAV. Pe platformele pe 64 de biți în unmapping nu este necesar ca SAV, avem suficient pentru a ține toată memoria fizică disponibilă.
Din teoria sistemelor de operare, pentru a descrie afișarea paginilor VAS în paginile fizice, sistemul funcționează intrările din tabelul de pagini - intrare în tabelul (PTE). In interiorul paginii fizice descrisă de numărul blocului de pagini - Pagina numărul cadrului (PFN). De la PFN poate obține toate informațiile de pe pagina fizică, pe care îl reprezintă. De exemplu, PFN prezintă unele neuniforma Memory Access (NUMA) - nod deține această pagină. Sistemul de operare are o bază de date care stochează setul de PFN, care operează sistemul. Dacă pagina în SAV este reflectată în, există PTE, care poate sau nu poate indica afectate PFN. Conceptual, pagina este PTE, poate fi în memorie sau nu, de exemplu, în cazul în care acesta este schimbat la disc. În primul caz este legat de PFN activat, iar în al doilea - nr. La rândul său, o dată pagina fizică este legată de o pagină în SAV, revenirea PFN PTE.
Atunci când sistemul de operare stabilește Elibereazå primește / dă pagina PTE implicate, sau ar trebui să primească anumite informații cu privire la aceasta (de exemplu, alocarea NUMA), aceasta trebuie să implice blocarea setul de lucru al procesului - pentru a asigura o stabilitate la ancora PTE PFN. Acest mâner de blocare este destul de scump si poate strica scalabilitatea procesului.
În alocarea de pagini fizice, mecanism de utilizare AWE ne oferă un set de PFN intrări direct din baza de date PFN. Este nevoie de sistemul de operare pentru a stabili un sistem de blocare pe o bază de date la momentul distribuirii de intrări PFN PFN. Utilizarea AWE mecanism de afișare, puteți afișa allotsiruemye intrările PFN pe proces SAV. Atunci când există o astfel de hartă, PTE este alocat, legat de PFN și sunt marcate ca blocarea. În acest caz, sistemul de operare ar trebui să fie o singură dată stabilit procesul de blocare set de lucru. La afișarea paginilor obișnuite, sistemul de operare face la cerere și, prin urmare, ar trebui să fie pentru a obține setul de lucru și de blocare în datele de bază de date PFN pentru fiecare pagină. Deoarece paginile din memorie sunt blocate în momentul PTE sistemului de paginare va fi ignorat.
Pe platformele pe 64 de biți mai bine pentru a apela aceste pagini bloca pagini (pagini blocate), și vă rugăm să nu le confunde cu pagini, de înghețare a fondurilor API VirtualLock. Așa cum este descris mai sus, în paginile blocate, există două proprietăți importante - acestea nu sunt implicate în paginare, realizat de sistemul de operare, iar la momentul de distribuție acestea captează setul de lucru și a stabilit o singură blocare de pe baza de date pentru PFN.
Prima proprietate nu are nici un efect evident asupra sistemelor de înaltă performanță, cum ar fi sistemele cu arhitectura NUMA. Aceasta duce la rezident de memorie explicită. Amintiți-vă că sistemul stabilește paginile la cerere. nod va fi utilizat pentru distribuirea de memorie fizică, care se execută referindu-se la fluxul de memorie. Numai după aceea pagina poate fi schimbat de către sistemul de operare în timpul schimbului. În plus, se poate ajunge înapoi în memorie, sistemul de operare va aloca din nou nod pagina fizică pe care firul continuă să lucreze cu această memorie. În acest caz, nodul poate fi destul de diferite. Un astfel de comportament ar duce la o sarcină suplimentară pentru aplicațiile care sunt utilizate pentru NUMA pagini de rezidență. Blocarea pagină vă permite să rezolve această problemă, le-a proteja pe deplin de paginare.
Cea de a doua proprietate - confiscarea a setului de lucru și blocați baza de date numai PFN, permite aplicațiilor să ruleze mai rapid și de a crește scalabilitatea rampei de încărcare.
Arhitectura NUMA, SQL Server Buffer Pool înregistrează fiecare pagina de alocare dedicată unitatea ei. Acest lucru se realizează prin utilizarea QueryWorkingSetEx. Odată ce pagina este alocată, numit acest API, care vă permite să cunoască detaliile reședința paginii. Acest lucru se face doar o singură dată. Prin urmare, pagini blocate pentru includerea SQL Server pe platforma pe 64 de biți îmbunătățește lucrul cu sarcina sawtooth, și crește performanța și scalabilitatea pe perioade mai lungi de timp. Atunci când SQL Server într-un mod pagini blocat, nu aveți nevoie să vă faceți griji cu privire la performanța sistemului în ansamblu, în funcție de memoria de eliminare a SQL Server, atunci când acesta este implicat în mecanismul de paginare sistemului de operare de ascultare pentru a alerta sistem responsabil pentru memorie API, și reducerea lor de lucru stabilit când a fost cerut de el.
Să rezuma acest articol: platformele pe 64 de biți VAS, avem suficient pentru a ține toată memoria fizică disponibilă, astfel încât probabilitatea de a obține o excepție System.OutOfMemoryException este practic exclusă.