Dela via

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 cacheinställningar

Du behöver förstå följande faktorer om konfigurerbara parametrar för filsystemcachen:

  • Genom att flusha en smutsig buffert lämnas datan i ett rent och användbart tillstånd för framtida läsningar tills minnestrycket leder till utrymmning.
  • 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 justerbara parameter, måste den markeras för att tömmas eller skrivas till lagringsmedia.
    • Minnestryck: Se vm.dirty_ratio | vm.dirty_bytes för detaljer.
    • Stäng: När ett filhandtag stängs, spolas alla smutsiga buffertar asynkront till lagringsenheten.

Dessa faktorer styrs av fyra justerbara parametrar. 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.

Anmärkning

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

vm.dirty_ratio | vm.dirty_bytes

Dessa två justerbara parametrar definierar mängden RAM-minne som gjorts användbart för data som ändrats men ännu inte skrivits till stabil lagring. Vilken tunable som än ställs in ställer den andra tunable 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 Red Hat till antingen 20% eller 30% fysiskt minne beroende på operativsystemet, vilket är en betydande mängd med tanke på minnesfotavtrycket för moderna system. 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. Standardinställningen för Red Hat är 10% av fysiskt minne, vilket i ett stort minnessystem är en betydande datamängd att börja tömma. Med SAS GRID som exempel var rekommendationen historiskt sett att ange vm.dirty_background till 1/5 av storleken på vm.dirty_ratio eller 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

Denna parameter definierar hur gammal en smutsig buffert kan vara innan den måste taggas för asynkron skrivning. Ta SAS Viyas CAS-arbetsbelastning som exempel. 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 filhandtag efter att ha skrivit data till varje shard lämnas handtagen öppna och buffertarna är minnesmappade av programmet. Utan en avslutning sker ingen rensning förrän antingen minnestryck passerar eller efter 30 sekunder. 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 justerbara värde definierar hur mycket tid som ägnas åt att sova mellan tömningar. 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 ej optimerad filsystemcache

När du tänker på de virtuella minnesinställningarna och mängden RAM-minne i moderna system kan tillbakaskrivning eventuellt göra andra lagringsberoende processer långsammare ur den specifika klientens perspektiv som driver den här blandade arbetsbördan. Följande symtom kan förväntas från en ietrimmad, skrivintensiv, cachetyngd Linux-dator.

  • Kataloglistor ls tar så lång tid att de verkar inte svara.
  • Läsdataflödet mot filsystemet minskar avsevärt jämfört med skrivdataflödet.
  • nfsiostat rapporter visar skrivfördröjningar i sekunder eller mer.

Du kan uppleva det här beteendet endast om Linux-datorn utför den blandade skrivintensiva arbetsbelastningen. Dessutom försämras användarupplevelsen för alla NFS-volymer som är monterade på 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 kvoten mellan vm.dirty_ratio och vm.dirty_background ställdes in till 2% och 1% av fysiskt minne respektive. I det här fallet började tömningen på 3,8 GiB, 1% av 384-GiB-minnessystemet. Tillbakaskrivningen liknade mycket skrivgenomströmningen 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