Perché rilasciare cache in Linux?

Nei nostri server abbiamo l'abitudine di far cadere le cache a mezzanotte.

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

Quando eseguo il codice sembra liberare molta RAM, ma devo davvero farlo. La RAM libera non è uno spreco?

Hai ragione al 100%. E ' non è una buona pratica per liberare la RAM. Questo è probabilmente un esempio di amministrazione del sistema di culto delle merci.

Sì, la cancellazione della cache libera la RAM, ma fa sì che il kernel cerchi i file sul disco piuttosto che nella cache, il che può causare problemi di prestazioni.

Normalmente il kernel svuota la cache quando la RAM disponibile è esaurita. Scrive spesso il contenuto sporco sul disco usando pdflush.

Il motivo per eliminare le cache in questo modo è per il benchmark delle prestazioni del disco ed è l'unica ragione per cui esiste.

Quando si esegue un benchmark ad alta intensità di I / O, si desidera essere sicuri che le varie impostazioni che si eseguono eseguano effettivamente l'I / O su disco, quindi Linux consente di eliminare le cache anziché eseguire un riavvio completo.

Per citare dalla documentazione :

Questo file non è un mezzo per controllare la crescita delle varie cache del kernel (inode, dentries, pagecache, ecc ...). Questi oggetti vengono automaticamente recuperati dal kernel quando è necessaria memoria altrove nel sistema.

L'uso di questo file può causare problemi di prestazioni. Dal momento che elimina gli oggetti memorizzati nella cache, può costare una quantità significativa di I / O e CPU per ricreare gli oggetti rilasciati, soprattutto se erano in uso intenso. Per questo motivo, si sconsiglia l'utilizzo al di fuori di un ambiente di test o di debug.

L'idea di base qui probabilmente non è poi così male (solo molto ingenua e fuorviante): potrebbero esserci dei file in cache, che è molto improbabile che possano essere raggiunti nel prossimo futuro, ad esempio i file di registro. Questi ram "divorati", che in seguito dovranno essere liberati dal sistema operativo in un modo o nell'altro.

A seconda delle impostazioni di swappiness, modello di accesso ai file, modello di allocazione della memoria e molte altre cose imprevedibili, può accadere che quando non si liberano queste cache, saranno successivamente costretti a essere riutilizzati, il che richiede un po 'più di tempo rispetto a allocare memoria dal pool di memoria non utilizzata. Nel peggiore dei casi, le impostazioni di swappiness di Linux causeranno lo scambio della memoria del programma, perché Linux pensa che questi file potrebbero essere più probabili da usare nel prossimo futuro rispetto alla memoria del programma.

Nel mio ambiente, Linux ipotizza abbastanza spesso di sbagliare, e all'inizio della maggior parte dei server di borsa valori europei (intorno alle 0900 ora locale) inizieranno a fare cose che fanno solo una volta al giorno, necessitando di scambiare memoria precedentemente scambiata perché scrivendo i file di log, la compressione, la copia, ecc. stavano riempiendo la cache al punto in cui le cose dovevano essere scambiate.

Ma la memorizzazione nella cache è la soluzione a questo problema? sicuramente no. Quale sarebbe la soluzione qui è dire a Linux ciò che non sa: che probabilmente questi file non verranno più utilizzati. Questo può essere fatto dall'applicazione di scrittura usando cose come posix_fadvise()o usando uno strumento cmd line vmtouch(che può anche essere usato per esaminare cose e file di cache).

In questo modo è possibile rimuovere i dati non più necessari dalle cache e conservare gli elementi che devono essere memorizzati nella cache, poiché quando si rilasciano tutte le cache, è necessario rileggere molte cose dal disco. E quello nel momento peggiore possibile: quando è necessario; causando ritardi nell'applicazione che sono evidenti e spesso inaccettabili.

Quello che dovresti avere in atto è un sistema che monitora i tuoi schemi di utilizzo della memoria (ad esempio se qualcosa sta cambiando) e quindi analizzarli di conseguenza e agire di conseguenza. La soluzione potrebbe essere quella di eliminare alcuni file di grandi dimensioni alla fine della giornata usando vtouch; potrebbe anche essere quello di aggiungere più RAM perché l'utilizzo di picco giornaliero del server è proprio questo.

Ho visto che le cache di rilascio sono utili quando si avvia un gruppo di macchine virtuali. O qualsiasi altra cosa che utilizza pagine di grandi dimensioni come alcuni server di database.

Le pagine di grandi dimensioni in Linux devono spesso deframmentare la RAM per trovare 2 MB di RAM fisica contigua da inserire in una pagina. Liberare tutta la cache dei file rende questo processo molto semplice.

Ma sono d'accordo con la maggior parte delle altre risposte in quanto non esiste un motivo generalmente valido per eliminare la cache dei file ogni notte.

È possibile che questo sia stato istituito come un modo per stabilizzare il sistema quando non c'era nessuno con le capacità o l'esperienza per trovare effettivamente il problema.

Liberare risorse

La caduta delle cache essenzialmente libererà alcune risorse, ma ciò ha un effetto collaterale nel rendere il sistema effettivamente più duro nel fare ciò che sta cercando di fare. Se il sistema sta eseguendo lo swap (tentando di leggere e scrivere da una partizione di swap su disco più velocemente di quanto non sia effettivamente in grado), la caduta periodica delle cache può alleviare il sintomo , ma non fa nulla per curare la causa .

Cosa sta divorando la memoria?

È necessario determinare cosa sta causando molto consumo di memoria che fa sembrare che la caduta delle cache funzioni. Ciò può essere causato da un numero qualsiasi di processi server mal configurati o semplicemente erroneamente utilizzati. Ad esempio, su un server ho assistito al massimo utilizzo della memoria quando un sito Web Magento ha raggiunto un determinato numero di visitatori in un intervallo di 15 minuti. Ciò è stato causato dalla configurazione di Apache per consentire l'esecuzione simultanea di troppi processi. Troppi processi, usando molta memoria (Magento è una bestia a volte) = scambio.

Linea di fondo

Non dare per scontato che sia qualcosa di necessario. Siate proattivi nel scoprire perché è lì, abbiate il coraggio di disabilitarlo se altri suggeriscono che è sbagliato e osservate il sistema - imparate qual è il vero problema e risolvetelo.

Linux / m68k in realtà ha un bug del kernel che fa impazzire kswapd e consuma il 100% di CPU (50% se c'è qualche altra attività legata alla CPU, come un autobuilder di pacchetti binari Debian - vulgo buildd - già in esecuzione), che può (la maggior parte del tempo; non sempre) essere mitigato eseguendo questo particolare comando ogni poche ore.

Detto questo ... il tuo server probabilmente non è un sistema m68k (Atari, Amiga, Macintosh classico, VME, Q40 / Q60, Sun3) ;-)

In questo caso, la persona che ha messo in riga o ha seguito alcuni consigli discutibili o, nella migliore delle ipotesi, obsoleti, o ha avuto l'idea di come la RAM dovrebbe essere utilizzata in modo errato (il pensiero moderno dice effettivamente "la RAM libera è spreco di RAM" e suggerisce la memorizzazione nella cache) o "scoperto" che questo "risolve" [sic!] un altro problema altrove (ed era troppo pigro per cercare una soluzione corretta).

Un motivo potrebbe essere che il sito sta eseguendo una sorta di monitoraggio, che controlla la quantità di RAM libera e invia un avviso agli amministratori quando la RAM libera scende al di sotto di una certa percentuale. Se quello strumento di monitoraggio è abbastanza stupido da non includere la cache nel calcolo ram gratuito, potrebbe inviare falsi avvisi; svuotare regolarmente la cache potrebbe sopprimere questi avvisi, pur consentendo allo strumento di notare quando il RAM "reale" si sta esaurendo.

Naturalmente, in questo tipo di situazione, la vera soluzione è quella di modificare lo strumento di monitoraggio per includere la cache nel calcolo ram gratuito; pulire la cache è solo una soluzione alternativa, e anche una cattiva, perché la cache si riempirà rapidamente quando i processi accedono al disco.

Quindi, anche se la mia ipotesi è vera, la pulizia della cache non ha senso, è piuttosto una soluzione alternativa da parte di qualcuno che non è abbastanza competente per risolvere il problema principale.

Mi viene in mente un motivo plausibile per farlo in un lavoro cron notturno.

Su un sistema di grandi dimensioni, può essere utile eliminare periodicamente le cache in modo da poter rimuovere la frammentazione della memoria.

Il supporto trasparente hugepage del kernel esegue una scansione periodica della memoria per fondere piccole pagine in hugepage. In condizioni degenerate ciò può comportare pause di sistema di un minuto o due (la mia esperienza con questo è stata in RHEL6; si spera che sia migliorata). La caduta delle cache può consentire alla spazzatrice di hugepage di avere un po 'di spazio su cui lavorare.

Potresti sostenere che questa è una buona ragione per disabilitare gli hugepage trasparenti; OTOH potresti credere che valga la pena avere il miglioramento complessivo delle prestazioni da hugepage trasparenti e vale la pena pagare il prezzo della perdita della cache una volta al giorno.

Ho pensato a un'altra ragione per cui vorresti farlo, anche se non in un lavoro cron. Proprio prima che un sistema di virtualizzazione migra una VM su un nuovo hardware sarebbe un ottimo momento per questo. Meno contenuto di memoria da copiare nel nuovo host. Dovrai eventualmente leggere dalla memoria, invece, ovviamente, ma probabilmente prenderei quel compromesso.

Non so se qualcuno dei software virt lo faccia davvero.

Solo per aggiungere i miei due centesimi: il sistema sa benissimo che queste pagine di memoria sono cache e scenderanno quanto necessario quando un'applicazione richiede memoria.

Un'impostazione pertinente è /proc/sys/vm/swappiness, che dice al kernel durante le nuove allocazioni di memoria di preferire eliminare cache di memoria o scambiare pagine di memoria allocate "inattive".

La domanda è del 2014, ma poiché il problema esiste fino ad oggi su alcuni backend centos 6.8 nascosti, potrebbe essere ancora utile per qualcuno.

https://github.com/zfsonlinux/zfs/issues/1548 descrive un problema con zfs. Lì, lo spazio su disco non viene liberato per i file eliminati perché se si utilizza nfs sopra zfs gli inode del file non vengono eliminati dalla cache degli inode del kernel.

Per citare dal thread di bug, Behlendorf, 6 gennaio 2015 ha scritto:

La speculazione attuale è che per qualche motivo il server NFS mantiene una versione cache dell'handle del file. Fino a quando il server NFS non rilascia questo handle di file, ZFS non può scollegare questo file. Alcuni test chiari hanno dimostrato che l'eliminazione delle cache sul server causerà l'eliminazione di questo riferimento (come l'handle del file NFS) in quel momento lo spazio viene liberato correttamente. La pressione della memoria può anche causare la caduta.

vale a dire un'eco notturna 3> / proc / sys / vm / drop_caches è la soluzione più semplice per quel bug se non si desidera avere un tempo morto per ristrutturare zfs.

Quindi forse non l'amministrazione di culto cargo, ma un buon debugging è stato il motivo.

Ciò può avere senso sui sistemi NUMA (accesso alla memoria non uniforme), in cui, in genere, ciascuna CPU (socket) può accedere a tutta la memoria in modo trasparente, ma è possibile accedere alla propria memoria più velocemente della memoria di altri socket, in associazione con applicazioni HPC parallele.

Molte semplici applicazioni parallele tendono a eseguire l'I / O dei file da un singolo processo, lasciando in uscita una grande frazione di memoria su un singolo nodo NUMA allocato alla cache del disco, mentre sull'altro nodo NUMA la memoria può essere per lo più libera. In queste situazioni, poiché il processo di recupero della cache nel kernel Linux, per quanto ne so, non è ancora a conoscenza di NUMA, i processi in esecuzione sul nodo NUMA che ha memoria allocata alla cache sono costretti ad allocare memoria sull'altro nodo NUMA, purché ci sia RAM libera sull'altro nodo, uccidendo così le prestazioni.

Tuttavia, in un sistema HPC, sarebbe più saggio pulire la cache prima di iniziare un nuovo processo utente, non in un momento specifico con cron.

Per applicazioni non parallele è improbabile che si verifichi questo problema.

Quando la cache della pagina è piuttosto grande (molto più grande del tuo attuale utilizzo di swap) e lo scambio e lo scambio avvengono a turno, è quando devi eliminare le cache. Ho visto casi in cui l'utilizzo della memoria aumenta in uno dei miei server di database MariaDB che eseguono Ubuntu 16.04LTS e Linux ha appena scelto di aumentare l'utilizzo dello scambio anziché rimuovere le cache di pagine inutilizzate. Hugepage trasparenti già disabilitati nel mio sistema perché TokuDB ha richiesto che fosse disabilitato. Ad ogni modo forse non è un bug, ma Linux continua a fare questo comportamento per me è abbastanza sconcertante. Varie fonti affermano che Linux rimuoverà la cache della pagina quando l'applicazione lo richiede:

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Ma la realtà non è così semplice. La soluzione alternativa è:

1. Eseguire periodicamente la cache di rilascio
2. Eseguire la cache di rilascio quando necessario (monitorare usando vmstat 1 per lo scambio di attività)
3. Consiglia a linux di rimuovere alcuni file dalla cache (come i file di log di apache) usando utility come dd o python-fadvise. Vedi https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Esempio di esecuzione dd:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Esempio python-fadvise:

pyadvise -d /var/log/apache2/access_log.1

Ho una macchina desktop con 16 GB di RAM in esecuzione sul kernel PAE. Dopo un'ora o due le prestazioni del disco si riducono drasticamente fino a quando non lascio cadere le cache, quindi le metto semplicemente in cron. Non so se questo è un problema con il kernel PAE o con l'implementazione della cache così lenta se c'è molta memoria.