Você está 100% correto. Não é uma boa prática liberar memória RAM. Este é provavelmente um exemplo de administração do sistema de culto de carga.
Em nossos servidores, temos o hábito de descartar caches à meia-noite.
sync; echo 3 > /proc/sys/vm/drop_caches
Quando eu executo o código, ele libera muita memória RAM, mas eu realmente preciso fazer isso. RAM livre não é um desperdício?
Você está 100% correto. Não é uma boa prática liberar memória RAM. Este é provavelmente um exemplo de administração do sistema de culto de carga.
Sim, o cache de limpeza libera a RAM, mas faz com que o kernel procure arquivos no disco em vez de no cache, o que pode causar problemas de desempenho.
Normalmente, o kernel limpa o cache quando a RAM disponível é esgotada. Com frequência, grava conteúdo sujo no disco usando o pdflush.
O motivo para colocar caches como este é para avaliar o desempenho do disco e é a única razão pela qual existe.
Ao executar uma referência de I / O intensivo, você quer ter certeza de que as várias configurações que você está tentando estão realmente fazendo E / S de disco, então o Linux permite que você elimine caches ao invés de uma reinicialização completa. >
Para citar a documentação :
This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system.
Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended.
A idéia básica aqui provavelmente não é tão ruim (apenas muito ingênua e enganosa): Pode haver arquivos sendo armazenados em cache, que dificilmente serão acessados em um futuro próximo, por exemplo, arquivos de log. Estes "comer" ram, que mais tarde terão que ser liberados quando necessário pelo sistema operacional de uma maneira ou de outra.
Dependendo de suas configurações de swappiness, padrão de acesso a arquivos, padrão de alocação de memória e muito mais coisas imprevisíveis, pode acontecer que, quando você não liberar esses caches, eles sejam forçados a serem reutilizados, o que exige um pouco mais tempo do que alocar memória do pool de memória não utilizada. No pior dos casos, as configurações de swap do linux farão com que a memória do programa seja trocada, porque o linux acha que esses arquivos podem ser mais provavelmente usados no futuro próximo do que a memória do programa.
No meu ambiente, o linux adivinha muitas vezes erradamente, e no início da maioria das bolsas de valores da Europa (por volta das 09:00 hora local) os servidores começam a fazer coisas que fazem apenas uma vez por dia, precisando trocar na memória que foi previamente trocada porque escrever arquivos de log, compactá-los, copiá-los, etc. estava preenchendo o cache até o ponto em que as coisas tinham que ser trocadas.
Mas está descartando caches a solução para esse problema? Definitivamente não. O que seria a solução aqui é dizer ao Linux o que ele não sabe: que esses arquivos provavelmente não serão mais usados. Isso pode ser feito pelo aplicativo de gravação usando coisas como posix_fadvise() ou usando uma ferramenta de linha cmd como vmtouch (que também pode ser usada para examinar coisas e também arquivos de cache).
Dessa forma, você pode remover os dados que não são mais necessários dos caches e manter as coisas que devem ser armazenadas em cache, porque quando você descarta todos os caches, muitas coisas precisam ser relidas do disco. E isso no pior momento possível: quando é necessário; causando atrasos em seu aplicativo que são perceptíveis e muitas vezes inaceitáveis.
O que você deve ter em funcionamento é um sistema que monitore seus padrões de uso de memória (por exemplo, se algo está trocando) e, em seguida, analise de acordo e aja de acordo. A solução pode ser remover alguns arquivos grandes no final do dia usando o vtouch; Também pode ser para adicionar mais memória RAM, porque o pico de uso diário do servidor é apenas isso.
Eu vi quedas de armazenamento serem úteis ao inicializar várias máquinas virtuais. Ou qualquer outra coisa que use páginas grandes, como alguns servidores de banco de dados.
As Páginas Grandes no Linux geralmente precisam defragar a RAM para encontrar 2MB de RAM física contígua para colocar em uma página. Liberar todo o cache de arquivos torna esse processo muito fácil.
Mas eu concordo com a maioria das outras respostas, pois geralmente não há uma boa razão para descartar o cache de arquivos todas as noites.
É possível que isso tenha sido instituído como uma maneira de estabilizar o sistema quando não havia ninguém com as habilidades ou experiência para realmente encontrar o problema.
O armazenamento de caches essencialmente libera alguns recursos, mas isso tem um efeito colateral de fazer com que o sistema realmente trabalhe mais para fazer o que está tentando fazer. Se o sistema estiver trocando (tentando ler e gravar a partir de uma partição de swap de disco mais rápido do que realmente é capaz), a queda periódica das caches pode aliviar o sintoma , mas não faz nada para curar a causa .
Você deve determinar o que está causando uma grande quantidade de consumo de memória que faz com que as caixas de corte pareçam funcionar. Isso pode ser causado por qualquer número de processos de servidor mal configurados ou simplesmente incorretamente utilizados. Por exemplo, em um servidor eu testemunhei a utilização da memória no máximo quando um site do Magento atingiu um certo número de visitantes em um intervalo de 15 minutos. Isso acabou sendo causado pelo Apache sendo configurado para permitir que muitos processos sejam executados simultaneamente. Muitos processos, usando muita memória (Magento é uma fera às vezes) = troca.
Não assuma que é algo necessário. Seja proativo em descobrir por que ele está lá, tenha a coragem de desativá-lo se os outros sugerirem que está errado e observe o sistema - saiba qual é o problema real e corrija-o.
O Linux / m68k tem um bug no kernel que faz o kswapd enlouquecer e consumir 100% da CPU (50% se houver alguma outra tarefa ligada à CPU, como o autobuilder do pacote binário Debian - vulgo buildd - já em execução), pode (na maioria das vezes, nem sempre) ser mitigado executando este comando em intervalos de algumas horas.
Dito isto… o seu servidor provavelmente não é um sistema m68k (Atari, Amiga, Macintosh Clássico, VME, Q40 / Q60, Sun3); -)
Nesse caso, a pessoa que inseriu as falas seguiu algum conselho questionável ou, na melhor das hipóteses, desatualizado, ou teve a idéia de como a RAM deveria ser usada de maneira errada (o pensamento moderno realmente diz que “RAM livre é desperdiçada” e sugere o armazenamento em cache), ou "descobriu" que isso "conserta" [sic!] outro problema em outro lugar (e estava com preguiça de procurar uma correção adequada).
Um motivo pode ser o site estar executando algum tipo de monitoramento, que verifica a quantidade de RAM livre e envia um aviso aos administradores quando a memória RAM cai abaixo de uma determinada porcentagem. Se essa ferramenta de monitoramento for burra o suficiente para não incluir o cache no cálculo do RAM livre, ela poderá enviar falsos avisos; O esvaziamento regular do cache pode suprimir esses avisos e, ao mesmo tempo, permitir que a ferramenta perceba quando o RAM "real" fica baixo.
Naturalmente, nesse tipo de situação, a solução real é modificar a ferramenta de monitoramento para incluir o cache no cálculo de RAM livre; limpar o cache é apenas uma solução alternativa, e também uma solução ruim, porque o cache será reabastecido rapidamente quando os processos acessarem o disco.
Portanto, mesmo que a minha suposição seja verdadeira, a limpeza de cache não é algo que faça sentido, é uma solução alternativa para alguém que não é competente o suficiente para corrigir o problema principal.
Eu posso pensar em uma razão plausível para fazer isso em um trabalho noturno no cron.
Em um sistema grande, pode ser útil remover caches periodicamente para que você possa remover a fragmentação da memória.
O suporte de página de página transparente do kernel faz uma varredura periódica de memória para unir pequenas páginas em páginas de entrada. Em condições degeneradas, isso pode resultar em pausas no sistema de um minuto ou dois (minha experiência com isso foi no RHEL6; esperamos que seja melhorada). A queda de caches pode permitir que a varredeira da página tenha espaço para trabalhar.
Você pode argumentar que esse é um bom motivo para desativar as páginas de abraços transparentes; OTOH você pode acreditar que vale a pena ter uma melhora no desempenho geral das páginas de abraços transparentes, e vale a pena pagar o preço de perder seus caches uma vez por dia.
Eu pensei em outro motivo que você gostaria de fazer, embora não em um trabalho cron. Logo antes de um sistema de virtualização migrar uma VM para um novo hardware, seria um bom momento para isso. Menos conteúdo da memória para copiar para o novo host. Você eventualmente terá que ler a partir do armazenamento, em vez disso, é claro, mas eu provavelmente tomaria essa troca.
Eu não sei se algum software virt realmente faz isso.
Só para adicionar meus dois centavos: O sistema sabe que estas páginas de memória são caches e vão cair o quanto for necessário quando um aplicativo solicitar memória.
Uma configuração relevante é /proc/sys/vm/swappiness , que diz ao kernel durante novas alocações de memória para preferir descartar caches de memória ou trocar páginas de memória alocadas "ociosas".
A questão é a partir de 2014, mas como o problema existe até hoje em alguns backends ocultos, pode ainda ser útil para alguém.
link descreve um problema com o zfs. Lá, o espaço em disco não é liberado para os arquivos excluídos porque, se o nfs for usado na parte superior do zfs, os inodes do arquivo não serão descartados do cache de inode do kernel.
Para citar o tópico do bug, behlendorf, 6 de janeiro de 2015 escreveu:
The current speculation is that for some reason the NFS server is keeping a cached version of the file handle. Until the NFS server drops this file handle ZFS can't unlink this file. Some light testing has shown that dropping caches on the server will cause this reference to be dropped (like the NFS file handle) at which point the space is correctly freed. Memory pressure can also cause it to be dropped.
i.e. um eco noturno 3 > / proc / sys / vm / drop_caches é a solução mais fácil para esse bug se você não quiser ter um tempo de inatividade para reestruturar seu zfs.
Então, talvez não seja um administrador de cultos de carga, mas uma boa depuração foi o motivo.
Isso pode fazer sentido em sistemas NUMA (acesso não uniforme à memória), onde, tipicamente, cada CPU (socket) pode acessar toda a memória de forma transparente, mas sua própria memória pode ser acessada mais rapidamente do que a memória de outros soquetes. aplicações.
Muitos aplicativos paralelos simples tendem a fazer E / S de arquivo a partir de um único processo, deixando assim uma grande fração de memória em um único nó NUMA alocado para o cache de disco, enquanto no outro nó NUMA a memória pode estar livre . Nessas situações, como o processo de recuperação de cache no kernel Linux, até onde eu sei, ainda não é compatível com NUMA, os processos em execução no nó NUMA que possui memória alocada para o cache são forçados a alocar memória no outro nó NUMA. contanto que haja RAM livre no outro nó, matando assim as performances.
No entanto, em um sistema HPC, seria mais sensato limpar o cache antes de iniciar um novo trabalho do usuário, não em um horário específico com o cron.
Para aplicações não paralelas, é improvável que esse problema ocorra.
Eu tenho uma máquina desktop com 16GB de RAM rodando no kernel do PAE. Depois de uma ou duas horas, o desempenho do disco degrada-se drasticamente até que eu abandone os caches, por isso simplesmente o coloco no cron. Eu não sei se isso é um problema com o kernel do PAE ou com a implementação do cache sendo tão lenta se houver muita memória.