+ Responder ao Tópico



  1. #1

    Padrão Limpar Memória

    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

  2. #2

    Padrão

    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 :-)



  3. #3

    Padrão respostas

    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.

    Citação Postado originalmente por galahad Ver Post
    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 :-)

  4. #4

    Padrão

    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.



  5. #5

    Padrão

    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.

  6. #6

    Padrão teste

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

    Citação Postado originalmente por galahad Ver Post
    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.



  7. #7

    Padrão correto

    É 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.

    Citação Postado originalmente por galahad Ver Post
    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.
    Citação Postado originalmente por fredy10 Ver Post
    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.

  8. #8

    Padrão

    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.



  9. #9

    Padrão reboot então?

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

    Citação Postado originalmente por fredy10 Ver Post
    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.

  10. #10

    Padrão

    Citação Postado originalmente por hamasterisk Ver Post
    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.



  11. #11

    Padrão problema

    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.

    Citação Postado originalmente por fredy10 Ver Post
    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.

  12. #12

    Padrão

    Citação Postado originalmente por hamasterisk Ver Post
    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



  13. #13

    Padrão uso da cache

    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.

    Citação Postado originalmente por fredy10 Ver Post
    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

  14. #14

    Padrão

    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?



  15. #15

    Padrão versão

    Centos

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


    Citação Postado originalmente por galahad Ver Post
    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?

  16. #16

    Padrão

    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...



  17. #17

    Padrão perda de performance

    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.

    Citação Postado originalmente por fredy10 Ver Post
    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...

  18. #18

    Padrão

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