Aanbevolen procedures voor cache van Linux-bestandssysteem voor Azure NetApp Files
Dit artikel helpt u inzicht te hebben in aanbevolen procedures voor de cache van het bestandssysteem voor Azure NetApp Files.
Bestandssysteemcache kan niet worden gebruikt
U moet de volgende factoren begrijpen over het niet-inschakelen van bestandssysteemcaches:
- Door een vuile buffer te leegmaken, blijven de gegevens in een schone toestand bruikbaar voor toekomstige leesbewerkingen totdat geheugendruk leidt tot verwijdering.
- Er zijn drie triggers voor een asynchrone flush-bewerking:
- Op basis van tijd: Wanneer een buffer de leeftijd bereikt die door deze tunable is gedefinieerd, moet deze worden gemarkeerd voor reiniging (dat wil gezegd, leegmaken of schrijven naar opslag).
- Geheugendruk: Zie
vm.dirty_ratio | vm.dirty_bytes
voor meer informatie. - Sluiten: Wanneer een bestandsgreep wordt gesloten, worden alle vuile buffers asynchroon leeggemaakt naar de opslag.
Deze factoren worden bepaald door vier tunables. Elke tunable kan dynamisch en permanent worden afgestemd met tuned
of sysctl
in het /etc/sysctl.conf
bestand. Het afstemmen van deze variabelen verbetert de prestaties voor toepassingen.
Notitie
Informatie die in dit artikel wordt besproken, is ontdekt tijdens validatieoefeningen van SAS GRID en SAS Viya. Als zodanig zijn de tunables gebaseerd op lessen die zijn geleerd uit de validatieoefeningen. Veel toepassingen profiteren op dezelfde manier van het afstemmen van deze parameters.
vm.dirty_ratio | vm.dirty_bytes
Deze twee tunables definiëren de hoeveelheid RAM die bruikbaar is voor gewijzigde gegevens, maar nog niet naar stabiele opslag geschreven. De andere instelling die niet kan worden ingesteld, wordt automatisch ingesteld op nul; RedHat adviseert om een van de twee tunables handmatig in te stellen op nul. De optie vm.dirty_ratio
(de standaardwaarde van de twee) wordt door Redhat ingesteld op 20% of 30% van het fysieke geheugen, afhankelijk van het besturingssysteem, wat een aanzienlijke hoeveelheid is die rekening houdt met de geheugenvoetafdruk van moderne systemen. Er moet rekening worden gehouden met het instellen van instellingen vm.dirty_bytes
in plaats van vm.dirty_ratio
voor een consistentere ervaring, ongeacht de geheugengrootte. Doorlopend werken met SAS GRID heeft bijvoorbeeld 30 MiB bepaald, een geschikte instelling voor de beste algehele prestaties van gemengde werkbelastingen.
vm.dirty_background_ratio | vm.dirty_background_bytes
Deze tunables definiëren het beginpunt waar het Linux write-back-mechanisme begint met het leegmaken van vuile blokken naar stabiele opslag. Redhat is standaard ingesteld op 10% van het fysieke geheugen, dat, op een groot geheugensysteem, een aanzienlijke hoeveelheid gegevens is om te beginnen met leegmaken. Met SAS GRID als voorbeeld, was de aanbeveling historisch gezien ingesteld vm.dirty_background
op een grootte van 1/5 of vm.dirty_ratio
vm.dirty_bytes
. Gezien hoe agressief de vm.dirty_bytes
instelling is ingesteld voor SAS GRID, wordt hier geen specifieke waarde ingesteld.
vm.dirty_expire_centisecs
Dit kan niet definiëren hoe oud een vuile buffer kan zijn voordat deze moet worden gelabeld voor asynchroon schrijven. Neem bijvoorbeeld de CAS-workload van SAS Viya. Een tijdelijke schrijf-dominante workload heeft vastgesteld dat het instellen van deze waarde op 300 centiseconden (3 seconden) optimaal was, met 3000 centiseconden (30 seconden) als standaardwaarde.
SAS Viya deelt CAS-gegevens in meerdere kleine segmenten van elk een paar megabytes. In plaats van deze bestandsingangen te sluiten nadat u gegevens naar elke shard hebt geschreven, blijven de ingangen open en worden de buffers binnen de toepassing toegewezen aan het geheugen. Zonder een sluiting is er geen spoeling totdat de geheugendruk of 30 seconden wordt doorgang. Wachten op geheugendruk bleek suboptimaal te zijn, net als bij het wachten tot een lange timer is verlopen. In tegenstelling tot SAS GRID, die naar de beste totale doorvoer zocht, keek SAS Viya ernaar om schrijfbandbreedte te optimaliseren.
vm.dirty_writeback_centisecs
De kernel flusher-thread is verantwoordelijk voor het asynchroon leegmaken van vuile buffers tussen elke flush thread-slaapstand. Dit kan de hoeveelheid verbruikte slaap tussen spoelsels niet definiëren. Gezien de waarde van 3 seconden vm.dirty_expire_centisecs
die wordt gebruikt door SAS Viya, stelt SAS dit niet in op 100 centiseconden (1 seconde) in plaats van de standaardwaarde van 500 centiseconden (5 seconden) om de beste algehele prestaties te vinden.
Impact van een niet-afgestemde bestandssysteemcache
Wanneer u rekening houdt met de standaardbewerkingen voor virtueel geheugen en de hoeveelheid RAM in moderne systemen, vertraagt write-back mogelijk andere opslaggerelateerde bewerkingen vanuit het perspectief van de specifieke client die deze gemengde werkbelasting aanstuurt. De volgende symptomen kunnen worden verwacht van een niet-afgestemde, schrijfintensieve Linux-machine met cache.
- Directorylijsten
ls
duren lang genoeg om niet meer te reageren. - Leesdoorvoer voor het bestandssysteem neemt aanzienlijk af in vergelijking met schrijfdoorvoer.
nfsiostat
rapporten schrijven latenties in seconden of hoger.
Mogelijk ondervindt u dit gedrag alleen door de Linux-machine die de gemengde schrijfintensieve workload uitvoert. Verder wordt de ervaring gedegradeerd tegen alle NFS-volumes die zijn gekoppeld aan één opslageindpunt. Als de koppelingen afkomstig zijn van twee of meer eindpunten, vertonen alleen de volumes die een eindpunt delen dit gedrag.
Het instellen van de cacheparameters van het bestandssysteem, zoals beschreven in deze sectie, is weergegeven om de problemen op te lossen.
Virtueel geheugen bewaken
Als u wilt weten wat er met virtueel geheugen en de write-back gaat, kunt u het volgende codefragment en de volgende uitvoer overwegen. Dirty vertegenwoordigt de hoeveelheid vuil geheugen in het systeem en writeback vertegenwoordigt de hoeveelheid geheugen die actief naar de opslag wordt geschreven.
# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done`
De volgende uitvoer is afkomstig van een experiment waarbij de vm.dirty_ratio
vm.dirty_background
verhouding respectievelijk is ingesteld op 2% en 1% van het fysieke geheugen. In dit geval begon het leegmaken bij 3,8 GiB, 1% van het 384-GiB-geheugensysteem. Writeback lijkt sterk op de schrijfdoorvoer naar NFS.
Cons
Dirty: 1174836 kB
Writeback: 4 kB
###
Dirty: 3319540 kB
Writeback: 4 kB
###
Dirty: 3902916 kB <-- Writes to stable storage begins here
Writeback: 72232 kB
###
Dirty: 3131480 kB
Writeback: 1298772 kB
Volgende stappen
- Aanbevolen procedures voor directe I/O voor Linux voor Azure NetApp Files
- Aanbevolen procedures voor koppelen in Linux NFS voor Azure NetApp Files
- Best practices voor gelijktijdigheid van Linux voor Azure NetApp Files
- Aanbevolen procedures voor lezen in Linux NFS
- Best practices voor virtuele Azure-machine-SKU's
- Prestatiebenchmarks voor Linux