Aanbevolen procedures voor cache van Linux-bestandssysteem voor Azure NetApp Files

  • Artikel

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. Als u bijvoorbeeld SAS GRID gebruikt, is de aanbeveling historisch ingesteld vm.dirty_background op de grootte van 1/5 of vm.dirty_ratiovm.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 geheugendruk of 30 seconden is verstreken. 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

Gezien de standaardbewerkingen voor virtueel geheugen en de hoeveelheid RAM in moderne systemen, vertraagt write-back mogelijk andere opslaggebonden bewerkingen vanuit het perspectief van de specifieke client die deze gemengde werkbelasting stimuleren. 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_ratiovm.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