Vraag Waarom caches achterlaten in Linux?


In onze servers hebben we de gewoonte om caches om middernacht te laten vallen.

sync; echo 3 > /proc/sys/vm/drop_caches

Wanneer ik de code uitvoer lijkt het veel RAM vrij te maken, maar moet ik dat echt doen. Is vrije RAM geen verspilling?


81
2018-05-20 03:12


oorsprong


Zoek de persoon die dit heeft ingebracht en vraag hem waarom hij het deed. Zoals je goed hebt geraden, is er geen duidelijke goede reden voor. - Michael Hampton♦
Debuggen van de kernel. Dat is het zo'n beetje. Dit maakt geen RAM vrij; het laat caches vallen, zoals de naam al doet vermoeden, en vermindert dus de prestaties. - Michael Hampton♦
@ivcode Vervolgens moet u het probleem met die server vinden en verhelpen in plaats van te proberen de omstandigheden die dit veroorzaken te voorkomen. Als mijn auto elke keer tot stilstand komt als ik een scherpe bocht naar rechts maak, is het vermijden van scherpe bochten naar rechts een slechte oplossing. - David Schwartz
Verwant thedailywtf.com/Articles/Modern-Memory-Management.aspx Sterk ruzie maken dat het een slecht idee is. - Drunix
Gerelateerd, en een bruikbare beschrijving van het "probleem": linuxatemyram.com - Bill Weiss


antwoorden:


Je bent 100% correct. Het is niet een goede gewoonte om RAM vrij te maken. Dit is waarschijnlijk een voorbeeld van het beheer van vrachtcultussystemen.


85
2018-05-20 04:59



+1 voor het vermelden van Cargo Cult System Administration. Elke sysadmin die die term niet kent en wat het betekent, moet worden ontslagen. - Tonny
@Tonny: We zouden achterblijven zonder sysadmin afdeling dan :( - PlasmaHH
Net als de meeste mensen, hou ik van bondige onbezonnen beweringen met veel instemming, maar een citaat of redenering zou de +1 van mijn superego verdienen. - Aaron Hall
Leg de cargo-cult-administratie uit, evenals het bovenstaande, als u het niet erg vindt. Misschien in een vervolg-bewerking? Ik stel mijn +1 nog steeds achter ...: P - Aaron Hall
"het is mogelijk dat, hoewel je applicatie deze RAM misschien niet gebruikt, maar Linux agressief in het geheugen caching en hoewel de applicatie geheugen nodig heeft, zal hij sommige van deze cache niet vrijmaken, maar liever swappen." Niet erg specifiek. In de praktijk is geheugenbeheer niet perfect en het hebben van een knop om te draaien wanneer die onvolkomenheid verschijnt, is een goede zaak. - Dan Pritts


Ja, het wissen van de cache zal RAM vrijmaken, maar het zorgt ervoor dat de kernel naar bestanden op de schijf zoekt in plaats van in de cache, wat prestatieproblemen kan veroorzaken.

Normaal gesproken zal de kernel de cache leegmaken als het beschikbare RAM-geheugen leeg is. Het schrijft vaak vervuilde inhoud naar schijf met behulp van pdflush.


62
2018-05-20 06:26



+1 voor uitleg waarom Het is een slecht idee. - Ogre Psalm33


De reden om caches als deze te laten vallen is voor het benchmarken van schijfprestaties en is de enige reden waarom dit bestaat.

Wanneer u een I / O-intensieve benchmark uitvoert, wilt u er zeker van zijn dat de verschillende instellingen die u probeert, allemaal daadwerkelijk schijf-I / O doen, zodat u met Linux caches kunt laten vallen in plaats van een volledige herstart uit te voeren.

Citeren uit de documentatie:

Dit bestand is geen middel om de groei van de verschillende kernel te controleren   caches (inodes, dentries, pagecache, enz ...) Deze objecten zijn   automatisch teruggevorderd door de kernel wanneer ergens anders geheugen nodig is   op het systeem.

Gebruik van dit bestand kan prestatieproblemen veroorzaken. Omdat het weggooit   gecachte objecten, het kan een aanzienlijke hoeveelheid I / O en CPU kosten   recreëren de vallende objecten, vooral als ze zwaar werden gebruikt.   Vanwege dit is gebruik buiten een testomgeving of debuggingomgeving   niet aangeraden.


34
2018-05-20 13:51



Natuurlijk, afhankelijk van wat u probeert te doen, kan zelfs een volledige herstart de schijfcache niet voldoende wissen. - α CVn
"deze objecten worden automatisch door de kernel teruggevorderd wanneer er geheugen nodig is" is het ontwerpdoel, maar het is misschien niet altijd het werkelijke gedrag. - Dan Pritts
@DanPritts Waar denk je precies aan dat het niet waar is? - Joe
Het voor de hand liggende geval is wanneer u RAM wilt leegmaken om de toewijzing van meer (niet-transparante) enorme pagina's toe te staan; een ander geval is transparant, enorme pagina's, garbage collection pause bugs (zie mijn antwoord / opmerkingen elders op deze vraag). Maar mijn opmerking was bedoeld voor de algemene zaak. Soms weten de mensen die het systeem bedienen beter dan de mensen die het hebben ontworpen / geïmplementeerd. Vaak niet - dat is wat hun commentaar probeert te beschermen tegen. Ik ben gewoon blij dat het - Dan Pritts


Het basisidee is hier waarschijnlijk niet zo slecht (gewoon erg naïef en misleidend): er kunnen bestanden in de cache worden opgeslagen waarvan het onwaarschijnlijk is dat ze in de nabije toekomst worden geopend, bijvoorbeeld logbestanden. Deze "opeten" ram, die later op een of andere manier door het OS moet worden bevrijd wanneer dit nodig is.

Afhankelijk van je instellingen voor swappiness, bestandstoegangspatroon, geheugentoewijzingspatroon en nog veel meer onvoorspelbare dingen, kan het gebeuren dat wanneer je deze caches niet vrijmaakt, ze later gedwongen worden opnieuw te worden gebruikt, wat een beetje meer tijd in beslag neemt dan geheugen toewijzen uit de pool van ongebruikt geheugen. In het ergste geval zullen de swappiness-instellingen van linux ervoor zorgen dat het programmageheugen wordt uitgewisseld, omdat Linux denkt dat die bestanden in de nabije toekomst eerder zullen worden gebruikt dan het programmageheugen.

In mijn omgeving raadt Linux nogal eens verkeerd aan, en aan het begin van de meeste Europese beurzen (rond 0900 lokale tijd) zullen servers dingen doen die ze slechts één keer per dag doen, waarbij ze het geheugen moeten ruilen dat eerder was uitgewisseld omdat ze schrijven logbestanden, comprimeren, kopiëren enz. vulde de cache tot het punt waarop dingen moesten worden geruild.

Maar laat caches de oplossing voor dit probleem vallen? zeker niet. Wat hier de oplossing zou zijn, is om Linux te vertellen wat het niet weet: dat deze bestanden waarschijnlijk niet meer zullen worden gebruikt. Dit kan worden gedaan door de schrijftoepassing met behulp van dingen zoals posix_fadvise()of met behulp van een cmd-lijntool zoals vmtouch (die ook kan worden gebruikt om dingen te bekijken, evenals cachebestanden).

Op die manier kunt u de gegevens die niet meer nodig zijn uit de caches verwijderen en de dingen bewaren die in de cache moeten worden opgeslagen, omdat wanneer u alle caches laat vallen, veel dingen opnieuw moeten worden gelezen vanaf de schijf. En dat op het slechtst mogelijke moment: wanneer het nodig is; vertragingen in uw applicatie veroorzaken die merkbaar en vaak onaanvaardbaar zijn.

Wat u op zijn plaats zou moeten hebben, is een systeem dat uw geheugengebruikspatronen controleert (bijvoorbeeld als er iets wordt geruild) en vervolgens dienovereenkomstig analyseren en dienovereenkomstig handelen. De oplossing zou kunnen zijn om enkele grote bestanden aan het einde van de dag uit te zetten met vtouch; het kan ook zijn om meer ram toe te voegen, omdat het dagelijkse piekgebruik van de server precies dat is.


25
2018-05-20 19:46



Alle apps op mijn server draaien op nohup. Misschien wordt nohup.out in de cache opgeslagen en herinneringen opgesnoven? - ivcode
@ivcode: Dit kan een reden zijn, controleer hoe groot nohup.out is. Gebruik vmtouch misschien om erachter te komen hoeveel ervan in de cache is opgeslagen. - PlasmaHH
Ik heb een cron-taak cat /dev/null > path/nohup.out in elke 15 minuten omdat nohup.out snel groeit. Misschien is linux cahing nohup.out zelfs als ik het opruim - ivcode
@ivcode Als u de uitvoer niet nodig hebt nohup je moet het doorverwijzen naar /dev/null. Het klinkt alsof je op een gegeven moment enkele zeer onervaren sysadmins op je systemen had. Zien stackoverflow.com/questions/10408816/... voor hoe te sturen nohupuitvoer naar /dev/null - David Wilkins
hoewel nohup.out in intervallen van 15 minuten wordt gewist, als het apps-proces om de een of andere reden is gedood, wordt nohup.out automatisch van een ander script gemaakt. Ik heb vmtouch geprobeerd. het is inderdaad een erg goede tool - ivcode


Ik heb drop-caches gezien als nuttig bij het opstarten van een aantal virtuele machines. Of iets anders dat gebruikmaakt van grote pagina's, zoals sommige databaseservers.

Grote pagina's in Linux moeten vaak RAM defragmenteren om 2 MB aangrenzend fysiek RAM te vinden om in een pagina te plaatsen. Als u alle bestandscache vrijmaakt, is dit proces zeer eenvoudig.

Maar ik ben het eens met de meeste andere antwoorden dat er geen goede reden is om de bestandscache elke avond te laten vallen.


16
2018-05-22 00:47



Ik reageerde omdat ik erop wees dat vooroordelen van de tweede orde antwoorden zijn op drop-caches. - Noah Spurrier
Ook resulteert in het lezen van enkele grote bestanden in HPC-toepassingen op knooppunten met een hoog geheugen (1Tb) in een grote hoeveelheid in het geheugen opgeslagen cachegeheugen. Omdat veel HPC-toepassingen malloc's van honderden GB uitvoeren, kan het systeem uren lang stil blijven liggen, omdat migratieprocessen minuscule brokken gefragmenteerd geheugen vruchteloos over NUMA-knooppunten verplaatsen zodra het systeem de "rand" van het geheugen in de cache bereikt. Erger nog, niets dat je kunt doen in het gebruikersland om de caches te bevrijden, behalve het systeem te misleiden om alle kleine 2MB-blokken tegelijk toe te wijzen en vervolgens vrij te geven, waardoor de enorme wisseling van defragmentatie en de apps normaal worden uitgevoerd. - user1649948
+1 De opdracht om grote pagina's te maken (sysctl -w vm.nr_hugepages=...) weigert zelfs maar te werken, tenzij ik eerst caches laat vallen (Arch linux). - Aleksandr Dubinsky


Het is mogelijk dat dit werd ingesteld als een manier om het systeem te stabiliseren wanneer er niemand was met de vaardigheden of ervaring om het probleem daadwerkelijk te vinden.

Middelen vrijmaken

Het laten vallen van caches zal in essentie wat middelen vrijmaken, maar dit heeft een neveneffect van het feit dat het systeem daadwerkelijk harder werkt om te doen wat het probeert te doen. Als het systeem wordt omgewisseld (proberen te lezen en schrijven van een schijf-swap-partitie sneller dan het daadwerkelijk mogelijk is) dan kan het periodiek laten vallen van caches de symptoom, maar doet niets om het te genezen oorzaak.

Wat is het geheugen opeten?

U zou moeten bepalen wat veel geheugenconsumptie veroorzaakt waardoor het laten vallen van caches lijkt te werken. Dit kan worden veroorzaakt door een aantal slecht geconfigureerde of gewoon verkeerd gebruikte serverprocessen. Op een server bijvoorbeeld, was ik getuige van maximale geheugengebruik toen een Magento-website een bepaald aantal bezoekers binnen een interval van 15 minuten bereikte. Dit werd veroorzaakt doordat Apache was geconfigureerd om te veel processen tegelijkertijd te laten werken. Te veel processen, met veel geheugen (Magento is soms een beest) = wisselen.

Bottom Line

Ga er niet alleen van uit dat het iets is dat nodig is. Wees proactief in het achterhalen waarom het er is, heb het lef om het uit te schakelen als anderen suggereren dat het verkeerd is, en observeer het systeem - leer wat het echte probleem is en los het op.


8
2018-05-20 15:16





Linux / m68k heeft eigenlijk een kernel-bug waardoor kswapd gek wordt en 100% CPU opslokt (50% als er een andere CPU-gebonden taak is, zoals een Debian binair pakket autobuilder - vulgo buildd - reeds actief), wat kan (de meeste van de tijd, niet altijd) worden gematigd door dit specifieke commando om de paar uur uit te voeren.

Dat gezegd hebbende ... uw server is hoogstwaarschijnlijk geen m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) systeem ;-)

In dit geval volgde de persoon die de regels invoerde een of ander twijfelachtig of op zijn best verouderd advies, of kreeg hij het idee hoe RAM verkeerd moest worden gebruikt (het moderne denken zegt inderdaad: "gratis RAM is RAM-geheugen verspild" en suggereert caching) , of "ontdekt" dat dit een ander probleem elders "oplost" (en te lui was om naar een juiste oplossing te zoeken).


4
2018-05-21 08:03



"een kernel-bug waardoor kswapd gek wordt" - Welke bug is dit? - Ben
@Ben zie deze draad (dit bericht en enkele follow-ups, waarvan er één een gok bevat waar het vandaan zou kunnen komen) - mirabilos
Ik ondervind een soortgelijk probleem (hoewel het x86_64 is) en de enige oplossing op dit moment is het verwijderen van caches serverfault.com/questions/740790/... - Fernando
@Fernando Ik heb ook een "drop caches" cronjob op de m68k-box - mirabilos


Een reden kan zijn dat de site een soort van monitoring uitvoert, die de hoeveelheid gratis ram controleert en een waarschuwing naar beheerders stuurt wanneer de vrije ram onder een bepaald percentage daalt. Als dat bewakingsprogramma dom genoeg is om cache niet mee te nemen in de berekening van de gratis ram, kan dit valse waarschuwingen geven; het regelmatig legen van de cache kan deze waarschuwingen onderdrukken, terwijl het hulpmiddel nog steeds opvalt als de "echte" ram te laag wordt.

Natuurlijk is de echte oplossing in dit soort situaties het wijzigen van de monitoringtool om cache op te nemen in de gratis ramberekening; het opschonen van de cache is slechts een tijdelijke oplossing en ook een slechte, omdat de cache snel wordt bijgevuld wanneer processen de schijf benaderen.

Dus zelfs als mijn aanname waar is, is het cachenerreinen niet iets dat logisch is, maar eerder een oplossing door iemand die niet competent genoeg is om het primaire probleem op te lossen.


3
2018-05-21 06:20





Ik kan één aannemelijke reden bedenken om dit in een nachtelijke cron-baan te doen.

Op een groot systeem kan het handig zijn om periodiek caches te laten vallen, zodat u fragmentatie van het geheugen kunt verwijderen.

De kernel transparante ondersteuning van de reusachtige pagina voert een periodieke overzicht van het geheugen uit om kleine pagina's samen te voegen tot enorme pagina's. Onder gedegenereerde omstandigheden kan dit resulteren in systeempauzes van een minuut of twee (mijn ervaring hiermee was in RHEL6, hopelijk is het verbeterd). Door caches te laten vallen kan de reusachtige veegmachine wat ruimte hebben om mee te werken.

Je zou kunnen beweren dat dit een goede reden is om transparante enorme pagina's uit te schakelen; OTOH je zou kunnen geloven dat de algehele prestatieverbetering van transparante reusachtige pagina's de moeite waard is, en de moeite waard is om de prijs te betalen van het één keer per dag verliezen van je caches.


Ik heb een andere reden bedacht om dat te doen, hoewel niet in een cron-baan. Vlak voordat een virtualisatiesysteem een ​​VM naar nieuwe hardware migreert, zou dit een goed moment zijn. Minder geheugeninhoud om naar de nieuwe host te kopiëren. Uiteindelijk zul je uit de opslag moeten lezen, in plaats daarvan, natuurlijk, maar ik zou die afweging waarschijnlijk doen.

Ik weet niet of een van de virt-software dit feitelijk doet.


3
2018-01-14 15:43



Heb je hier een bron voor? Dit klinkt als iets dat in de kernel moet worden opgelost als het zo'n probleem is. - gparent
Ik heb persoonlijke ervaring met de pauzes met transparante enorme pagina's. RHEL6, Dell R810, 4CPU's, 64 GB RAM. Door transparante enorme pagina's uit te schakelen (er is een / proc-bestand voor) hebben de pauzes onmiddellijk hersteld. Ik heb de cache drop-techniek toen niet geprobeerd; in plaats daarvan heb ik onze Java-apps opnieuw geconfigureerd om niet-transparante enorme pagina's te gebruiken en transparante transparante pagina's uitgeschakeld te laten. IIRC, we hebben genoeg naar de situatie gekeken om te beseffen dat we niet de enige getroffen mensen waren, en dat Red Hat hiervan op de hoogte was. - Dan Pritts
Hallo Dan, ik constat hetzelfde gedrag op mijn server. Ik werk met een enorme hoeveelheid gegevens en er valt drastische prestaties na 10+ berekeningen van hetzelfde python-programma (x2-3 van de eerste rekentijd). Als ik ernaar kijk, is de geheugencachegrootte enorm, 100 + GB. En als ik deze geheugencache doorspoel en mijn programma opnieuw uitvoer, krijg ik mijn initiële berekeningstijd terug. Heeft u een document of informatie over dit fenomeen? Dank je. - Axel Borja
access.redhat.com/solutions/46111 beschrijft het. U kunt transparante enorme pagina's uitschakelen om te zien of dat het probleem in uw geval is. - Dan Pritts


Gewoon om mijn twee cent toe te voegen: het systeem weet heel goed dat deze geheugenpagina's caches zijn, en zoveel als nodig zal laten vallen wanneer een toepassing om geheugen vraagt.

Een relevante instelling is /proc/sys/vm/swappiness, dat de kernel tijdens nieuwe geheugentoewijzingen vertelt om geheugencaches te laten vallen of om "inactieve" toegewezen geheugenpagina's te verwisselen.


2
2018-05-26 11:04





De vraag is vanaf 2014, maar aangezien het probleem tot op de dag van vandaag bestaat uit een aantal verborgen centen van 6,8 backends, kan het nog steeds nuttig zijn voor iemand.

https://github.com/zfsonlinux/zfs/issues/1548 beschrijft een probleem met zfs. Daar wordt schijfruimte niet vrijgemaakt voor verwijderde bestanden, omdat als nfs boven op zfs wordt gebruikt, de inodes van het bestand niet uit de inode-cache van de kernel worden verwijderd.

Om te citeren uit de bug-thread, behlendorf, 6 januari 2015 schreef:

De huidige speculatie is dat om de een of andere reden de NFS-server is   een in cache opgeslagen versie van de bestandsingang bewaren. Tot de NFS-server   zet dit bestand af, ZFS kan dit bestand niet ontkoppelen. Enkele lichte testen   heeft aangetoond dat het achterlaten van caches op de server deze referentie veroorzaakt   om te laten vallen (zoals de handgreep van het NFS-bestand) op welk punt de spatie is   correct bevrijd. De druk van het geheugen kan er ook voor zorgen dat het valt.

dat wil zeggen een nachtelijke echo 3> / proc / sys / vm / drop_caches is de gemakkelijkste oplossing voor die bug als je geen downtime wilt hebben voor het herstructureren van je zfs.

Dus misschien niet de ladingcultus die het bewondert, maar een paar behoorlijk goede debugging was de reden.


1
2017-10-27 12:25