Limpar Memória

[hamasterisk]

Caros companheiros, esse é meu primeiro post por aqui.
Estive vendo as categorias e não sei muito bem se o que preciso se encaixa exatamente aqui, mas creio que sim.
Faço o backup do nosso banco de dados MySQL usando export a cada 1 hora e jogo isso em nosso FTP.
Contudo, a cada vez que o export roda, vai tudo pra memória e depois fica lá, consumindo toda memória RAM.
Esse servidor tinha 1Gb. Passei pra 2Gb e agora pra 4Gb.
Em virtude disso, tenho que dar um reboot diário no servidor pra limpar a memória, o que não é uma boa prática de administração.
Pesquisei por ae e descobri os comandos abaixo. Eles funcionam muito bem, mas apenas quando estou logado no console. Quando eu coloco os comandos num script, o servidor simplesmente trava.
Desconfio que seja problema de path ou coisa assim. Apesar de estar rodando o script no crontab, como root.
Toda ajuda é bem vinda. Antecipadamente grato.

echo 3 > /proc/sys/vm/drop_caches
sysctl -w vm.drop_caches=3

[galahad]

Qual é a versão do MySQL que você está rodando?
Qual o comando você está usando para fazer o export do(s) banco(s)?
Já tentou fazer um reload do MySQL pra ver se ele libera a memória?
Já verificou as sessões do MySQL para ver se não está ficando nenhuma sessão presa e consumindo memória?
Já tentou rodar o comando "flush tables" no MySQL?

Espero as respostas :-)

[hamasterisk]

obrigado pelas resposta.
esse uso de memória acontece com várias coisas que você faz no sistema, como a cópia de um arquivo grande de um local para outro. não é exclusividade do mysql, mas respondendo as perguntas, ae vão:

mysql 4.1.20
dump

qto ao flush tables, não tentei.
mas como nçao acontece apenas com o processo do mysql e sim com todos os outros, gostaria mesmo de fazer o comando pra limpar memória funcionar sem travar, rs.

Qual é a versão do MySQL que você está rodando?
Qual o comando você está usando para fazer o export do(s) banco(s)?
Já tentou fazer um reload do MySQL pra ver se ele libera a memória?
Já verificou as sessões do MySQL para ver se não está ficando nenhuma sessão presa e consumindo memória?
Já tentou rodar o comando "flush tables" no MySQL?

Espero as respostas :-)

[galahad]

Qual o sistema de arquivos você está utilizando?
Qual a versão do kernel?

Pelo que andei vendo do /proc/sys/vm/drop_caches, ele faz a liberação forçada dos indicadores de memória, então é aconselhável você rodar o sync(1) antes de passar o parâmetro pra esse arquivo.

Pode ser que, se você colocar no seu script o comando sync antes de alterar o drop_caches, ele não trave, já que vai sincronizar as informações da memória com o disco e liberar de fato os endereços livres.

Acho que vale a tentativa.

[fredy10]

Bom, não sei se entendi direito o problema, mas pelo que sei, o Linux pega uma grande parte da memória livre e faz cache. Portanto, por mais que ele não esteja usando a memória, ela vai estar como "cached" no TOP.

Esse parâmetro, pode ser interpretado - de certa forma - como uma memória livre, pois o linux aloca ela para poder utilizá-la mais rapidamente quando necessário.

[hamasterisk]

To usando o Centos no kernel 2.6
Vou fazer o teste e mantenho o post atualizado
Valeu pela ajuda

Qual o sistema de arquivos você está utilizando?
Qual a versão do kernel?

Pelo que andei vendo do /proc/sys/vm/drop_caches, ele faz a liberação forçada dos indicadores de memória, então é aconselhável você rodar o sync(1) antes de passar o parâmetro pra esse arquivo.

Pode ser que, se você colocar no seu script o comando sync antes de alterar o drop_caches, ele não trave, já que vai sincronizar as informações da memória com o disco e liberar de fato os endereços livres.

Acho que vale a tentativa.

[hamasterisk]

É isso mesmo que ele faz. Contudo, no caso de um backup, certamente ele não vai fazer uso desses dados, pois estão todos compactados (tgz), prontos pra ir pro FTP, então não faz sentido manter isso em memória.

Qual o sistema de arquivos você está utilizando?
Qual a versão do kernel?

Pelo que andei vendo do /proc/sys/vm/drop_caches, ele faz a liberação forçada dos indicadores de memória, então é aconselhável você rodar o sync(1) antes de passar o parâmetro pra esse arquivo.

Pode ser que, se você colocar no seu script o comando sync antes de alterar o drop_caches, ele não trave, já que vai sincronizar as informações da memória com o disco e liberar de fato os endereços livres.

Acho que vale a tentativa.

Bom, não sei se entendi direito o problema, mas pelo que sei, o Linux pega uma grande parte da memória livre e faz cache. Portanto, por mais que ele não esteja usando a memória, ela vai estar como "cached" no TOP.

Esse parâmetro, pode ser interpretado - de certa forma - como uma memória livre, pois o linux aloca ela para poder utilizá-la mais rapidamente quando necessário.

[fredy10]

Mas de qualquer forma, os dados vão continuar na memória! pois ele não irá zerar os bits das memórias, então os dados estarão lá gravados fisicamente... E se o linux precisar de realocar esse espaço para alguma outra coisa, ele irá reescrever os dados, o que não dá diferença nenhuma.

[hamasterisk]

Então o mais indicado é eu continuar a dar reboot diário?

Mas de qualquer forma, os dados vão continuar na memória! pois ele não irá zerar os bits das memórias, então os dados estarão lá gravados fisicamente... E se o linux precisar de realocar esse espaço para alguma outra coisa, ele irá reescrever os dados, o que não dá diferença nenhuma.

[fredy10]

Então o mais indicado é eu continuar a dar reboot diário?

Não... Uma das grandes vantagens do linux em relação ao ruindows é a questão de gerenciamento de memória... Ele não fragmenta muito a memória e por isso ganha performance.

A questão de cached, ele mesmo vai se virando. Você não precisa se preocupar com isso. É só você ficar de olho, quando a memória em cache (cached) estiver alta, é sinal que tem memória livre. Se for diminuindo muito e a memória livre também estiver baixa, aí sim está faltando memória fisica.

Passe por favor o resultado do TOP para eu dar uma olhada.

[hamasterisk]

O problema é exatamente esse.
Nosso banco de dados está bem grande e a cada dump, chupa uma memória muito grande.
A máquina originalmente estava com 1Gb de RAM. Passei pra 2Gb e agora ta com 4Gb.
Como faço um backup por hora, depois de 5 backup, a memória RAM livre tá em 23Mb e isso compromete a performance, pois começar a fazer cache no disco.

Não... Uma das grandes vantagens do linux em relação ao ruindows é a questão de gerenciamento de memória... Ele não fragmenta muito a memória e por isso ganha performance.

A questão de cached, ele mesmo vai se virando. Você não precisa se preocupar com isso. É só você ficar de olho, quando a memória em cache (cached) estiver alta, é sinal que tem memória livre. Se for diminuindo muito e a memória livre também estiver baixa, aí sim está faltando memória fisica.

Passe por favor o resultado do TOP para eu dar uma olhada.

[fredy10]

O problema é exatamente esse.
Nosso banco de dados está bem grande e a cada dump, chupa uma memória muito grande.
A máquina originalmente estava com 1Gb de RAM. Passei pra 2Gb e agora ta com 4Gb.
Como faço um backup por hora, depois de 5 backup, a memória RAM livre tá em 23Mb e isso compromete a performance, pois começar a fazer cache no disco.

Mas e a memória cached tá em quanto???

Tenho 15 servidores de banco aqui. 3 deles são mysql. O menor banco mysql tem 5GB e as máquinas rodam tranquilas... a última foi reiniciada a mais de 6 meses.

Por isso quero ver se ela está deixando em cached

[hamasterisk]

Fazer cache de pesquisas frequentes é totalmente compreensível.
Mas quando o sistema compacta alguns arquivos pra serem copiados e nunca mais serão usados, não faz sentido ficar com isso em RAM.

Mas e a memória cached tá em quanto???

Tenho 15 servidores de banco aqui. 3 deles são mysql. O menor banco mysql tem 5GB e as máquinas rodam tranquilas... a última foi reiniciada a mais de 6 meses.

Por isso quero ver se ela está deixando em cached

[galahad]

Qual a distribuição e a versão de kernel você está utilizando?

Verificou se o flush tables melhora a questão da utilização da memória?

[hamasterisk]

Centos

2.6.9-67.0.15.ELsmp #1 SMP Thu May 8 10:52:19 EDT 2008 i686 i686 i386 GNU/Linux

Qual a distribuição e a versão de kernel você está utilizando?

Verificou se o flush tables melhora a questão da utilização da memória?

[fredy10]

Eu sei que você está confuso quanto a isso... Mas pense só em uma coisa:

Quando a memória é utilizada, são gravados dados nela. Após a utilização, mesmo que o kernel marque essa área como livre, os dados permanecerão lá, pois para limpar a memória, ele teria que zerar todos os bits da memória (isso falando a nível de hardware mesmo) e isso traria uma demora. Certo?
Então... o cache, é justamente essa área que está livre para gravação. Caso o kernel necessite alocar algo naquela área, ele irá regravar os dados que estavam lá antes.

Se ele tivesse que limpar a memória primeiro (zerar os bits) e depois gravar novamente os novos dados, isso demoraria o dobro do tempo. Por esse motivo o *nix fazem esse cache. A micro$$oft aprendeu a fazer isso e está utilizando o mesmo sistema no rwindows vista...

[hamasterisk]

O problema é a grande perda de performance quando estamos sem RAM livre.
Vou lhe dar um exemplo: acabo de dar boot no servidor e ele sobe com 3.9Gb de memória RAM livre. Disparo o backup e após o dump em SQL e posterior compactação com tgz, a memória livre cai para 23Mb e fica nisso. A performance da aplicação fica horrível. Se eu não der um boot no servidor ou executar os comandos, fica simplesmente inviável usar a aplicação.
O boot resolve, mas tem que ficar fazendo manual e demora uns 7 minutos, em virtude de todas as checagens SCSI, etc... Se esse comando funcionasse, sem ficar travando, seria o ideal.

Eu sei que você está confuso quanto a isso... Mas pense só em uma coisa:

Quando a memória é utilizada, são gravados dados nela. Após a utilização, mesmo que o kernel marque essa área como livre, os dados permanecerão lá, pois para limpar a memória, ele teria que zerar todos os bits da memória (isso falando a nível de hardware mesmo) e isso traria uma demora. Certo?
Então... o cache, é justamente essa área que está livre para gravação. Caso o kernel necessite alocar algo naquela área, ele irá regravar os dados que estavam lá antes.

Se ele tivesse que limpar a memória primeiro (zerar os bits) e depois gravar novamente os novos dados, isso demoraria o dobro do tempo. Por esse motivo o *nix fazem esse cache. A micro$$oft aprendeu a fazer isso e está utilizando o mesmo sistema no rwindows vista...

[fredy10]

Bom, se você passar o resultado do TOP quando sua máquina está lenta, fica mais fácil analisar e opinar...