Metodtips för Linux-filsystemcache för Azure NetApp Files
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_ratio
vm.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
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för