Utilizzo di buffer di RAM molto elevati dopo l'istanza di ridimensionamento / riavvio

Ieri pomeriggio abbiamo ridimensionato una delle nostre istanze di Linode (CentOS 5.7, 64 bit) da un'istanza da 4 GB a 12 GB. Subito dopo il riavvio, ho notato che l'uso della memory per i buffer è stato insanamente alto – più alto di quello che ho mai visto in qualsiasi macchina che ho toccato. Anche sui miei server più utilizzati raramente vedo l'utilizzo di buffer superiore a ~ 200 MB. Su questo server, l'utilizzo del buffer corrente è due ordini di grandezza superiore rispetto a prima di ridimensionare e riavviare.

Ecco il grafico di memory munin con dati pre e post migrazione:

  • Come posso impostare le premesse piene per un utente in un dir specificato?
  • Cron e atd eseguono i lavori con lo stesso utente, le autorizzazioni e l'ambiente?
  • Come eseguire il backup di un Centos Server completo?
  • File creato senza autorizzazioni o proprietari
  • Fornitura di utenti normali (non root) con funzionalità di esecuzione automatica di initialization e arresto
  • Invocare `smbclient -L localhost` in Ubuntu fornisce: NT_STATUS_CONNECTION_REFUSED
  • Grafico Munin Mempory

    I dati che munin stanno mostrando sono corroborati dall'output di "free":

    [erik@host ~]$ free -m total used free shared buffers cached Mem: 11967 10146 1820 0 7374 1132 -/+ buffers/cache: 1639 10327 Swap: 255 0 255 

    Ora, sono ben consapevole dell'utilizzo del kernel di memory non utilizzata per la cache, ma la mia comprensione dei buffer è che i buffer sono diversi. Sono abituati a memorizzare temporaneamente le scritture finché non sono state impegnate sul disco. È una giusta comprensione? Questo server ha molto poco IO del disco (è un server web apache / php, DB è altrove, quindi solo IO di sostanza sono access_logs) e in quanto tale, mi aspetto che l'utilizzo del buffer sia piuttosto basso.

    Ecco un grafico del traffico di networking per lo stesso periodo di tempo:

    immettere qui la descrizione dell'immagine

    Come potete vedere, non c'è una modifica sostanziale del traffico prima e dopo la ridimensionamento.

    Durante il riavvio sono cambiate tre cose che so di:

    1. Abbiamo raccolto 4 core aggiuntivi che Linode ha dato all'inizio di questa settimana, portndo i core totali a 8.
    2. Siamo sul kernel "Ultimo bit a 64 bit", che è ora 3.7.10-x86_64-linode30. Precedentemente siamo stati su 3.0.18 credo.
    3. Siamo andati da 4GB di RAM a 12GB.

    Di questi cambiamenti, la mia convinzione è che sia stato il nuovo kernel che sta causando l'aumento dell'uso del buffer. Purtroppo, al momento, non possiamo prendere un altro colpo di inattività per un downgrade a un kernel precedente, anche se questo potrebbe finire per essere necessario se non riesco a trovare questo utilizzo di buffer.

    Con questo, ho due domande:

    1. Qualcuno di voi fa funzionare il kernel 3.7.10 e, in caso affermativo, hai visto un cambiamento simile?
    2. Quali strumenti sono disponibili per controllare i buffer del kernel e le loro size?
    3. Suppongo che, come la cache, il kernel rilascerà questa memory quando altre applicazioni lo richiedono. È corretto?

    One Solution collect form web for “Utilizzo di buffer di RAM molto elevati dopo l'istanza di ridimensionamento / riavvio”

    Per chiarire questo punto:

    [Buffers] sono utilizzati per memorizzare temporaneamente le scritture fino a che non siano stati impegnati sul disco. È una giusta comprensione?

    No, non è giusto.

    Sembra capire il concetto di memory cache. Quando un file viene letto da un disco, il file viene mantenuto in memory come cache. Se un'applicazione ha bisogno di accedere nuovamente a questo file, l'accesso viene da RAM che è veloce, invece di accedere nuovamente al file dal disco, che è lento.

    Se un'applicazione deve scrivere su questo file, la scrittura viene eseguita sul file in RAM, che è veloce e il kernel contrassegna le pagine di memory come "sporco". Per quanto riguarda l'applicazione, la scrittura è completa e l'app può tornare a fare quello che fa.

    Il kernel maneggia il lavaggio delle pagine sporche al disco in seguito. È ansible forzare un stream di tutte le pagine sporche con il command di sync o vednetworking che i demoni di sciacquo (pdflush o bdflush) si svegliano di volta in volta.

    È ansible vedere la quantità di memory sporca in qualsiasi momento con il cat /proc/meminfo | grep Dirty cat /proc/meminfo | grep Dirty .

    Per correggere la comprensione, sia la cache di pagina pulita (i file che sono stati letti) che la cache di pagina sporca (i file in attesa di essere scritti su disco) vengono conteggiati come "cache" da Linux.

    La cache di file può essere liberata se i processi richiedono più allocazioni di memory virtuale. I segmenti di memory condivisi e tmpfs sono anche riportti come "cache", ma questi non possono essere liberati come la cache di file.

    Di solito i "buffer" sono allocazioni di memory eseguendo processi. Date un'occhiata in top -a o simili e vedere quale process sta occupando la maggior parte della RAM.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.