Prestatieproblemen met cache- en geheugenbeheer oplossen

Vóór Windows Server 2012 lieten twee primaire potentiële problemen de bestandssysteemcache groeien totdat het beschikbare geheugen bijna onder bepaalde werkbelastingen werd uitgeput. Wanneer deze situatie tot gevolg heeft dat het systeem traag is, kunt u bepalen of de server een van deze problemen ondervindt.

Tellers om te monitoren

• Geheugen\Long-Term Gemiddelde levensduur van stand-bycache (s) < 1800 seconden

• Geheugen\Beschikbaar (in bytes, KB of MB)

• Geheugen\Systeemcache Residenten-Bytes

Als geheugen\Beschikbare Mbytes laag is en tegelijkertijd geheugen\systeemcache residente bytes veel van het fysieke geheugen verbruikt, kunt u RAMMAP gebruiken om erachter te komen waarvoor de cache wordt gebruikt.

Systeembestandscache bevat gegevensstructuren van NTFS-metagegevens

Dit probleem wordt aangegeven door een groot aantal actieve metabestandpagina's in RAMMAP-uitvoer, zoals wordt weergegeven in de volgende afbeelding. Dit probleem is wellicht waargenomen op drukke servers met miljoenen bestanden die worden geopend, waardoor NTFS-metabestandsgegevens niet uit de cache worden vrijgegeven.

Het probleem werd vroeger verholpen door het dynCache-hulpprogramma . In Windows Server 2012+ is de architectuur opnieuw ontworpen en dit probleem mag niet meer bestaan.

Systeembestandscache bevat geheugen-gemapte bestanden

Dit probleem wordt aangegeven door een hoog aantal actieve gemapte bestandspagina's in de RAMMAP-uitvoer. Dit geeft meestal aan dat sommige toepassing op de server talloze grote bestanden opent met de CreateFile-API met FILE_FLAG_RANDOM_ACCESS een vlagset.

FILE_FLAG_RANDOM_ACCESS vlag is een hint voor CacheBeheer om in kaart gebrachte weergaven van het bestand zo lang mogelijk in het geheugen te houden (totdat het Geheugenbeheer geen signaal van een lage geheugentoestand afgeeft). Tegelijkertijd instrueert deze vlag Cache Manager om het vooraf ophalen van bestandsgegevens uit te schakelen.

Deze situatie is in zekere mate verholpen door verbeteringen in het bijsnijden van werksets in Windows Server 2012+, maar het probleem zelf moet voornamelijk worden aangepakt door de leverancier van de toepassing door FILE_FLAG_RANDOM_ACCESS niet te gebruiken. Een andere oplossing voor de leverancier van de app is het gebruik van lage geheugenprioriteit bij het openen van de bestanden. Dit kan worden bereikt met behulp van de SetThreadInformation-API . Pagina's die met een lage geheugenprioriteit worden geopend, worden agressiever uit de werkset verwijderd.

Cachebeheer, vanaf Windows Server 2016, vermindert verder dit probleem door FILE_FLAG_RANDOM_ACCESS te negeren bij het nemen van besluitvorming, zodat het wordt behandeld als elk ander bestand dat zonder de FILE_FLAG_RANDOM_ACCESS vlag is geopend (Cachebeheer respecteert nog steeds deze vlag om het vooraf laden van bestandsgegevens uit te schakelen). U kunt nog steeds opzwelling van de systeemcache veroorzaken als u een groot aantal bestanden hebt geopend met deze vlag en deze bestanden in een echt willekeurige volgorde worden benaderd. Het wordt ten zeerste aanbevolen om FILE_FLAG_RANDOM_ACCESS niet te worden gebruikt door toepassingen.

Drempelwaarde voor vuile pagina's voor externe bestanden wordt consistent overschreden

Dit probleem wordt aangegeven als een systeem af en toe vertragingen ondervindt tijdens schrijfbewerkingen van een externe client. Dit probleem kan optreden wanneer een grote hoeveelheid gegevens wordt geschreven van een snelle externe client naar een trage serverbestemming.

Vóór Windows Server 2016, in een dergelijk scenario, als de drempelwaarde voor vuile pagina's in de cache wordt bereikt, werken verdere schrijfbewerkingen alsof er write-through was. Dit kan ertoe leiden dat een grote hoeveelheid gegevens naar de schijf wordt weggeschreven, wat lange vertragingen kan veroorzaken als de opslag traag is, resulterend in time-outs voor de externe verbinding.

In Window Server 2016 en forward wordt een beperking ingesteld om de kans op time-outs te verminderen. Er wordt een afzonderlijke drempelwaarde voor vuile pagina's voor externe schrijfbewerkingen geïmplementeerd en er wordt een inline-flush uitgevoerd wanneer deze wordt overschreden. Dit kan leiden tot af en toe vertragingen tijdens zware schrijfactiviteit, maar elimineert het risico op een time-out in de meeste gevallen. Deze drempelwaarde voor externe vuile pagina's is standaard 5 GB per bestand . Voor sommige configuraties en workloads presteert een ander aantal beter.

Als de standaardgrootte van 5 GB niet goed werkt voor uw configuratie, is het raadzaam om de limiet in stappen van 256 MB te verhogen totdat de prestaties bevredigend zijn. Houd rekening met het volgende:

• Opnieuw opstarten is vereist voor wijzigingen in deze registersleutel om van kracht te worden.

• De eenheden van RemoteFileDirtyPageThreshold zijn het aantal pagina's (met paginaformaat zoals beheerd door Cachebeheer). Dit betekent dat deze moet worden ingesteld op de gewenste grootte in bytes, gedeeld door 4096.

• Aanbevolen waarden zijn 128 MB <= N <= 50% beschikbaar geheugen.

• Deze drempelwaarde kan volledig worden uitgeschakeld door deze in te stellen op -1. Dit wordt niet aanbevolen omdat dit kan leiden tot time-outs voor externe verbindingen.

Als u bijvoorbeeld de limiet wilt instellen op 10GiB dat 10.737.418.240 bytes / 4096 = 2.621.440 is, wat een decimale DWORD-waarde van 2621440 is.

Deze drempelwaarde kan worden beheerd met behulp van de volgende registerwaarde.

• Sleutel: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
  • Type: DWORD
  • Waardenaam: RemoteFileDirtyPageThreshold
  • Waardegegevens: Decimaal - aantal pagina's (paginagrootte zoals beheerd door Cachebeheer).