Dela via

Metodtips för Linux-filsystemcache för Azure NetApp Files

  • Artikel

Den här artikeln hjälper dig att förstå metodtips för filsystemcache för Azure NetApp Files.

Filsystem cache tunables

Du måste förstå följande faktorer när det gäller filsystemcachens tunables:

  • Om du tömer en smutsig buffert blir data i ett rent tillstånd som kan användas för framtida läsningar tills minnestrycket leder till borttagning.
  • Det finns tre utlösare för en asynkron tömningsåtgärd:
    • Tidsbaserad: När en buffert når den ålder som definieras av denna tunable, måste den markeras för rengöring (dvs. tömning eller skrivning till lagring).
    • Minnestryck: Mer vm.dirty_ratio | vm.dirty_bytes information finns i.
    • Stäng: När ett filhandtag stängs rensas alla smutsiga buffertar asynkront till lagring.

Dessa faktorer styrs av fyra tunables. Varje tunable kan justeras dynamiskt och beständigt med hjälp av tuned eller sysctl i /etc/sysctl.conf filen. Om du justerar dessa variabler förbättras prestandan för program.

Kommentar

Information som beskrivs i den här artikeln avslöjades under valideringsövningarna för SAS GRID och SAS Viya. Som sådan baseras tunablesna på lärdomar från valideringsövningarna. Många program har på samma sätt nytta av att justera dessa parametrar.

vm.dirty_ratio | vm.dirty_bytes

Dessa två tunables definierar mängden RAM-minne som gjorts användbart för data som ändrats men ännu inte skrivits till stabil lagring. Beroende på vilken tonfisk som ställs in ställs den andra tonfisken automatiskt in på noll. RedHat avråder från att manuellt ställa in någon av de två tunables till noll. Alternativet vm.dirty_ratio (standardvärdet för de två) anges av Redhat till antingen 20 % eller 30 % av det fysiska minnet beroende på operativsystemet, vilket är en betydande mängd med tanke på det moderna systemets minnesfotavtryck. Du bör tänka på att ställa in vm.dirty_bytes i stället vm.dirty_ratio för en mer konsekvent upplevelse oavsett minnesstorlek. Till exempel fastställde pågående arbete med SAS GRID 30 MiB som en lämplig inställning för bästa övergripande prestanda för blandade arbetsbelastningar.

vm.dirty_background_ratio | vm.dirty_background_bytes

Dessa tunables definierar startpunkten där Linux-tillbakaskrivningsmekanismen börjar rensa smutsiga block till stabil lagring. Redhat är som standard 10 % av det fysiska minnet, vilket i ett stort minnessystem är en betydande mängd data för att börja rensa. Om du till exempel använder SAS GRID har rekommendationen tidigare varit att ange vm.dirty_background till 1/5 storlek eller vm.dirty_ratiovm.dirty_bytes. Med tanke på hur aggressivt vm.dirty_bytes inställningen har angetts för SAS GRID anges inget specifikt värde här.

vm.dirty_expire_centisecs

Detta tunable definierar hur gammal en smutsig buffert kan vara innan den måste taggas för asynkront skrivning. Ta till exempel SAS Viyas CAS-arbetsbelastning. En tillfällig skrivdominerande arbetsbelastning fann att det var optimalt att ange det här värdet till 300 centisekunder (3 sekunder) med 3 000 centisekunder (30 sekunder) som standard.

SAS Viya delar CAS-data i flera små segment på några megabyte vardera. I stället för att stänga dessa filreferenser efter att ha skrivit data till varje shard lämnas handtagen öppna och buffertarna i är minnesmappade av programmet. Utan stängning blir det ingen tömning förrän antingen minnestrycket eller 30 sekunder har passerat. Att vänta på minnestryck visade sig vara suboptimalt, liksom att vänta på att en lång timer skulle upphöra att gälla. Till skillnad från SAS GRID, som letade efter det bästa övergripande dataflödet, såg SAS Viya ut att optimera skrivbandbredden.

vm.dirty_writeback_centisecs

Kernel flusher-tråden ansvarar för att asynkront rensa smutsiga buffertar mellan varje viloläge för tömningstråden. Detta tunable definierar hur mycket som spenderas i viloläge mellan spolar. Med tanke på värdet på 3 sekunder vm.dirty_expire_centisecs som används av SAS Viya, anger SAS detta tunable till 100 centisekunder (1 sekund) snarare än standardvärdet på 500 centisekunder (5 sekunder) för att hitta den bästa övergripande prestandan.

Påverkan av en otunnad filsystemcache

Med tanke på de virtuella standardminnena och mängden RAM-minne i moderna system kan tillbakaskrivningen eventuellt göra andra lagringsbundna åtgärder långsammare ur den specifika klientens perspektiv som driver den här blandade arbetsbelastningen. Följande symtom kan förväntas från en otunnad, skrivintensiv, cacheladdad Linux-dator.

  • Kataloglistor ls tar tillräckligt lång tid för att verka svarar inte.
  • Läsdataflödet mot filsystemet minskar avsevärt jämfört med skrivdataflödet.
  • nfsiostat rapporter skriver svarstider i sekunder eller högre.

Du kan bara uppleva det här beteendet av Linux-datorn som utför den blandade skrivintensiva arbetsbelastningen. Dessutom försämras upplevelsen mot alla NFS-volymer som monterats mot en enda lagringsslutpunkt. Om monteringarna kommer från två eller flera slutpunkter är det bara volymerna som delar en slutpunkt som uppvisar det här beteendet.

Att ange parametrarna för filsystemets cache enligt beskrivningen i det här avsnittet har visat sig åtgärda problemen.

Övervaka virtuellt minne

Tänk på följande kodfragment och utdata för att förstå vad som händer med det virtuella minnet och tillbakaskrivningen. Dirty representerar mängden smutsigt minne i systemet, och tillbakaskrivning representerar mängden minne som aktivt skrivs till lagring.

# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done

Följande utdata kommer från ett experiment där vm.dirty_ratio förhållandet och vm.dirty_background har angetts till 2 % respektive 1 % av det fysiska minnet. I det här fallet började tömningen på 3,8 GiB, 1 % av 384-GiB-minnessystemet. Tillbakaskrivningen liknade skrivdataflödet till 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

Nästa steg