none
Entity Framework 4 - Consumo de Memória Excessivo ! RRS feed

  • Pergunta

  • Boa tarde a todos,

    a um tempo comecei a usar o Entity Framework 4 e realmente gostei.

    desenvolvi um sistema de agendamento e administração para consultórios odontológicos.

    Este sistema esta pronto e roda perfeitamente em minha maquina. Porem, ele é web e ao subi-lo no UOL host, a aplicação da RECYCLE conforme o usuário vai usando.

    depois de muito tentar achar o erro, o pessoal do UOL me respondeu.

    Prezado Matheus,

    A dificuldade de queda de sessão ocorre devido ao alto consumo de memória causada pela aplicação.

    A aplicação consome rapidamente 100 MB de memória física disponível no servidor, e o pool de aplicação é automaticamente reiniciando derrubando a sessão.

    Deixamos um link com um print de uso de memória:

    http://matheusmog.dominiotemporario.com/memory.jpg

    É preciso otimizar o código para consumir pouca memória e evitar esse tipo de dificuldade.

    minha massa de dados ainda nem eh tao grande ...

    A questao agora é ... alguem ja teve esta dificuldade ou sabe como otimizar e reduzir o consumo de memoria em servidor ?

    aguardo ansiosamente

     


    Matheus Reis MCP - .Net Framework
    quarta-feira, 25 de maio de 2011 15:59

Todas as Respostas

  • Em que momento este problema ocorre, é em alguma chamada a método que consulta dados vindos do Entity FrameWork?

    Caso positivo, verifique se esses dados vem paginados, isso pode ajudar no processamento.

    Poste mais detalhes sobre o erro.

    Logo ao publicar e iniciar a aplicação já ocorre esse erro?

    quarta-feira, 25 de maio de 2011 17:22
  • é intermitente ...

    as vezes eu faço login, vou a uma pagina que fara a busca de dados e cai ...

    depois eu faço login novamente, acesso esta pagina, acesso outra que fará busca em outras tabelas com outros dados, e navego por mais umas 3 paginas e depois cai.

    isso eu apenas usando o sistema, fico imaginando quando for 2,3 ou 4 usuarios simultaneamente.

    ja cheguei a ficar navegando uns 3 minutos no sistema e interagindo com dados sem cair ... porem ja houve vezes em que logo, vou pra outra pagina e ele cai em seguida.


    Matheus Reis MCP - .Net Framework
    quarta-feira, 25 de maio de 2011 17:28
  • Você já tentou publicar em outros servidores para verificar se o desempenho é semelhante?


    quarta-feira, 25 de maio de 2011 18:40
  • eu criei uma ApplicationPool no meu IIS local, fiz deploy no meu sistema, joguei em uma pasta, criei um site, apontei para esta pasta e rodei.

    fui acompanhando no taskmanager. Antes de efetuar o login na App, ja são consumidos 60 a 70 mb ...

    conforme vou utilizando o sistema, esse nunmero vai crescendo e chegou a 101 mb ... pra mim nao cai, pois nao tenho limite de memoria, mas se acontecer isso no servidor, com certeza vai cair.

    o EF 4.1 consegue otimizar isto, sera ?


    Matheus Reis MCP - .Net Framework
    quarta-feira, 25 de maio de 2011 18:44
  • Eu vou pesquisar algo a respeito, mas de uma olhada nesses links, falam sobre como manipular os dados no Entity Framework de uma maneira menos trabalhosa para a memória.

    http://blogs.microsoft.co.il/blogs/gilf/archive/2010/02/07/entity-framework-context-lifetime-best-practices.aspx

    http://blog.dynatrace.com/2009/05/12/memory-leak-in-entitydatasource-when-controlling-lifetime-of-your-objectcontext/

    Sua aplicação é em Asp.net ou Silverlight?

    quarta-feira, 25 de maio de 2011 19:02
  • vou olhar ... estou migrando minha APP para EF4.1

     

    minha aplicacao eh asp.net com mysql


    Matheus Reis MCP - .Net Framework
    quarta-feira, 25 de maio de 2011 19:06
  • Ola,

    migrei minha app para EF4.1 . Houveram ganhos de alocação de memória.

    fiz um teste (meio amador, mas ta valendo rsrs) abri 3 browser diferentes e chamei o sistema e cada um loguei com um usuario difrente.

    enquanto so contem 1 usuario logado, ele consome por volta de 69mb. com 3 usuarios ele chega a 95mb rapidamente.

    do meu conhecimento se esgotou. nao sei aonde posso obter ganho de memoria, visto que eh uma ferramenta ORM ... mas ai fica a duvida .. qualquer sistema feito em EF nao pdoe ser hospedado em um server compartilhado ?

    alguem pode me ajudar ?

    grato.


    Matheus Reis MCP - .Net Framework
    quinta-feira, 26 de maio de 2011 19:37
  • bem ... subi para o SERVIDOR UOL HOST e a aplicação continua caindo !

    nao adiantou ... alguem ai pode me ajudar ?

     


    Matheus Reis MCP - .Net Framework
    quinta-feira, 26 de maio de 2011 22:28
  • ninguem sabe :? ninguem hospedou um sistema em EF4.1 em um host compartilhado ainda ?

    se alguem quiser simular o que esta acontecendo, acesse - http://matheusmogi-com-br.web33.redehost.com.br/DW/Default.aspx (matheus.reis/5039)
    comece a navegar no sistema, inserir dados, enfim, interagir com o sistema ... vera que do nada ele volta pra tela de login.

     


    Matheus Reis MCP - .Net Framework
    terça-feira, 31 de maio de 2011 12:39
  • Isso aí eu acredito que se dá por um simples fato. Quando vc faz um site com consultas SQL do jeito velho, vc filtra exatamente o que vc quer, traz um registro, tendo todos os campos ou não, a depender da string que vc escreve.

     

    No caso do EF, pelo que entendi, um código genérico sempre vai trazer o registro inteiro, para consulta singular, e consulta multipla vai trazer vários ou todos os registros completos. Fora o ônus de ser um phuta camada de processamento extra em cima de algo que poderia ser direto. Sério, esse tipo de "facilidade" (frameworks mil) só traz atrazo. Não adianta ser mais fácil e ter uma sintaxe gostosa de ver se no final ferra com a aplicação (fato, a sintaxe do EF é linda... e só, o problema é que gosto muito de código bonito).

     

    Imagine que vc tenha por exemplo um banco de dados com postagens como de um blog, daí vc faz uma busca pra retornar todos os posts. Vc coloca pra exibir só o título e a data, mas ele traz o texto e as demais informações das postagens. Em alguns casos, por exemplo onde vc supostamente acredita fazer uma paginação, na verdade em todas as páginas, tods os registros são requisitados, apenas são exibidos aqueles que a página requer, mas carregados na memória estão todos.

     

    Acho muito bonitinho os vários artigos que tem por aí ensinando EF e tal, usar gridviews ou webgrid no caso do MVC, mas os "profissionais" que escrevem esses artigos não se dão ao trabalho de abordar questões tão sérias e vitais como essas... a não ser, claro, que eles não saibam ou não se importem com isso, o que é errado em todo caso.

     

    Facilidade que estraga a aplicação eu dispenso, prefiro fazer código mais "baixo nível" e fazer uma aplicação boa, leve e consistente, do que fazer uma aplicação fácil e rápida, mas que vai ferrar tudo e ser impossível de usar.

     

    sábado, 24 de setembro de 2011 12:15
  • acredito q vc nao esteja fechando a conexao apos executar os comando do banco.

    faz a conexao assim:

    using(ADOConexao conex = new ADOConexao)

    {

    //Coloca aki somente oq eh necessário requisição do banco.

    }

    assim vc garante q a conexao será sempre fechada

    sexta-feira, 15 de junho de 2012 02:12
  • Não é por culpa das ferramentas de ORM, o NHibernate por exemplo sei que funciona perfeitamente em produção mesmo em ambiente compartilhado com limites ou sistemas grandes com grandes modelos de classes. A questão é se fizer as coisas tudo no "modo padrão" como você mesmo vê em artigos, sem considerar o caso específico, pode dar problema de lentidão ou consumir muito recurso mesmo, assim pode acontecer no NHibernate também. Eu não trabalho profissionalmente com EF, mas o que posso ajudar é falar de características do NHibernate para performance que podem servir como chave de pesquisa pra vc no EF. Segue entao: abrir a conexao no inicio da requisicao e finalizar no fim da mesma; ver caso a caso onde usar Lazy load ou não; e usar Fetch em querys pesadas (só nao sei se existe como dar fetch no EF em determinadas propriedades via LINQ ou algo parecido, no caso do NHibernate é com QueryOver ou Criteria). O Fetch faz desligar o lazy em cada propriedade que você for usar num determinado momento que tiver fazendo uma query/busca no banco, ou seja, vai carregar de uma vez exatamente os objetos de propriedades que você precisar no momento e não deixar a aplicação indo ao banco toda hora acessando propriedades que são lazy e nem o contrário de deixar tudo sem lazy load. Última versão que testei no EF não tinha isso, não lembro qual foi, mas tente também o EF5 beta, vai que o EF4 é mais beta que o EF5 beta.. E outra coisa você não especificou que tipo de mapeamento está usando, mas faça via "Code First" senão estiver usando. ORM ajuda muito para POO, mas para sistemas maiores é preciso fazer as coisas enxutas e com execução otimizada pensando em cada tipo de situação. Mais uma dica, vai debugando usando IIS até achar o ponto que a memória fica crescendo, as vezes é até simplesmente o uso de Session de forma pesada, o que seria indevido usar, não sei seu caso.
    sábado, 16 de junho de 2012 14:54