none
Configuracao de memoria virtual e memoria usada RRS feed

  • Pergunta

  • Pessoal,

     

    alguem poderia me esclarecer como funciona a configuracao de limite de memoria de uma pool ?

    Minhas duvidas são :

    - Qual o limite maximo de memoria virtual que pode ser utilizado em iis rodando em 32 bits em servidor 64 ?

    - Este limite é para todos os processos de uma pool ( worker process ) ou cada processo teria este limite ?

    - Como verifica a quantidade de memoria sendo utilizada ? Ja ouvi falar que esta memoria virtual que o iis configura nao é a mesma que é exibda no task manager. Eu acho que está correto pois no taskmanager meus processos tem no maximo 300 Mb e apesar de no IIS estar configurado para 2.800 ele recicla com grande frequencia.

    Agradeço ajuda de voces

    domingo, 2 de outubro de 2011 01:39

Respostas

  • Olá,

     

    - Em arquitetura de 32 o maximo que pode atingir de memoria virtual é de 2^32 (2 GB), em arquiteturas x64 pode chegar até 8 TB..

    - Se não estou enganado seria a soma de todos os worker process (Necessário confirmar).

    - Com relação a memoria virtual analise com o Process Explorer, vc tem acesso a Memoria paginada e nao-paginada...

     

    []s


    Erick Albuquerque | Microsoft MVP
    MVP Profile | Twitter | Linkedin | http://iisbrasil.wordpress.com
    • Marcado como Resposta Rafael Metring segunda-feira, 10 de outubro de 2011 14:26
    terça-feira, 4 de outubro de 2011 15:55
    Moderador
  • Numa máquina 64bits, processos criados em modo 32-bits rodam no subsistema WoW (Windows on Windows) que permite o endereçamento de até 4Gb de memória virtual, por processo de 32bits. Isso é exatamente igual a um Windows 32bits, exceto pelo fato que neste outro caso, metade destes endereços estaria reservado para o kernel (2Gb). Ou seja:

    Windows 32bits: máximo de 2Gb para processos + 2 Gb para kernel (resevado), POR PROCESSO
    Windows 64bits rodando processos de 32bits (WoW): máximo de 4Gb, POR PROCESSO (o kernel é 64bits e fica em outra área de memória).

    Nota: para que processo "enxergue" os 4Gb, ele deve ter sido compilado para isso (com um flag chamado /LARGEADDRESSAWARE); no caso do IIS, o w3wp.exe (processo que executa as páginas) é compilado de forma a utilizar esse total de memória. Outros processos podem não ter esse flag habilitado.

    IMPORTANTE: estamos falando de memória virtual, que em outras palavras, é a capacidade de endereços de memória que os processos enxergam. Isso não tem nada a ver com a quantidade de memória física na máquina. Ex: uma máquina Win32 pode ter 2Gb de RAM física instalada e "endereçar"  até 4Gb de RAM virtual (*por exemplo, usando arquivo de paginação para "suprir" o que faltou de memória física*). Ou pode ter 16Gb de RAM fisica instalada, mas mesmo assim, os processos 32bits não vão endereçar (nativamente) mais que os 4Gb citados anteriormente.

    Att.,


    Paulo Teixeira - PFE
    • Marcado como Resposta Rafael Metring segunda-feira, 10 de outubro de 2011 14:27
    terça-feira, 4 de outubro de 2011 16:28

Todas as Respostas

  • Olá,

     

    - Em arquitetura de 32 o maximo que pode atingir de memoria virtual é de 2^32 (2 GB), em arquiteturas x64 pode chegar até 8 TB..

    - Se não estou enganado seria a soma de todos os worker process (Necessário confirmar).

    - Com relação a memoria virtual analise com o Process Explorer, vc tem acesso a Memoria paginada e nao-paginada...

     

    []s


    Erick Albuquerque | Microsoft MVP
    MVP Profile | Twitter | Linkedin | http://iisbrasil.wordpress.com
    • Marcado como Resposta Rafael Metring segunda-feira, 10 de outubro de 2011 14:26
    terça-feira, 4 de outubro de 2011 15:55
    Moderador
  • Numa máquina 64bits, processos criados em modo 32-bits rodam no subsistema WoW (Windows on Windows) que permite o endereçamento de até 4Gb de memória virtual, por processo de 32bits. Isso é exatamente igual a um Windows 32bits, exceto pelo fato que neste outro caso, metade destes endereços estaria reservado para o kernel (2Gb). Ou seja:

    Windows 32bits: máximo de 2Gb para processos + 2 Gb para kernel (resevado), POR PROCESSO
    Windows 64bits rodando processos de 32bits (WoW): máximo de 4Gb, POR PROCESSO (o kernel é 64bits e fica em outra área de memória).

    Nota: para que processo "enxergue" os 4Gb, ele deve ter sido compilado para isso (com um flag chamado /LARGEADDRESSAWARE); no caso do IIS, o w3wp.exe (processo que executa as páginas) é compilado de forma a utilizar esse total de memória. Outros processos podem não ter esse flag habilitado.

    IMPORTANTE: estamos falando de memória virtual, que em outras palavras, é a capacidade de endereços de memória que os processos enxergam. Isso não tem nada a ver com a quantidade de memória física na máquina. Ex: uma máquina Win32 pode ter 2Gb de RAM física instalada e "endereçar"  até 4Gb de RAM virtual (*por exemplo, usando arquivo de paginação para "suprir" o que faltou de memória física*). Ou pode ter 16Gb de RAM fisica instalada, mas mesmo assim, os processos 32bits não vão endereçar (nativamente) mais que os 4Gb citados anteriormente.

    Att.,


    Paulo Teixeira - PFE
    • Marcado como Resposta Rafael Metring segunda-feira, 10 de outubro de 2011 14:27
    terça-feira, 4 de outubro de 2011 16:28
  • Muito bem explicado.

     

    Acabou até sanando uma duvida que eu tinha com relação ao limite por processo, porem aparecendo outras... Se eu tiver N worker process... o limite seria de 4GB em arquitetura x64 utlizando o Application Pool em 32 bits... Se todos os worker process chegassem neste limite como faria?

     

    []s


    Erick Albuquerque | Microsoft MVP
    MVP Profile | Twitter | Linkedin | http://iisbrasil.wordpress.com
    terça-feira, 4 de outubro de 2011 16:42
    Moderador
  • Erik e Paulo, obrigado pelas explicações.

     

    Agora também me surgiu uma dúvida.. Se eu tenho um limite de 4Gb por processo, vale a pena eu trabalhar com vários work process ?
    Se eu tenho uma pool com 50 websites e eu configurar ela para trabalhar com 50 workprocess eu teria teoricamente 4Gb de memoria virtual para cada site ?

     

    Abraços

    terça-feira, 4 de outubro de 2011 17:21
  • Como eu disse, uma coisa é memória virtual (que poderia ser traduzido como "total de endereços de memória que um processo pode endereçar") e outra é a memória física instalada na máquina.

    Se uma máquina (intel, amd, etc) tem palavras de 32bits, isso significa que há um barramento (um "caminho") entre o processador e os bancos de memória de "32 duas vias", sendo que cada "via" é um bit... Para ler alguma coisa da memória, primeiro vc tem que dizer para o chip de memória QUAL É O ENDEREÇO onde a informação está... então, primeiro o processador pega e envia uma sequencia de bits nessas "vias" para dizer onde está a informação, e só então a informação é "recuperada" da memória. Resumindo, numa máquina de 32bits, o maior endereço de memória que pode existir é 11111111111111111111111111111111, ou em decimal 2^32 = 4Gb. Há como "aumentar" isso usando um recurso chamado PAE (outra hora eu explico).

    Só que nem todo mundo tem 4Gb de RAM na máquina. Ai que entra um módulo do Windows chamado VMM (ou Virtual Memory Manager). Ele tem uma "tabela" onde ele faz um DE->PARA. Explicando, ele "deixa" a aplicação achar que tem 4Gb de RAM (o máximo permitido pela arquitetura 32bits), mas na hora de ler a informação "de verdade" da memória física ele faz essa conversão.

    Então todo processo Windows "acha" que tem 4Gb de RAM, mas quem controla o acesso a memória física na verdade é módulo Virtual Memory Manager do Windows. Esse cara é que lê/grava informações na memória física. Quando "acaba" a memória física disponível ele pode usar o PAGEFILE.SYS para gravar uma página de memória (um pedaço da memória) que não está sendo usada pela aplicação no disco, liberar a memória física, e dar para a outra aplicação.

    Em geral esse processo funciona muito bem, mas qdo você tem MUITAS aplicações pode começar a acontecer um problema chamado de "paginação" ... faz um teste: cria uma Máquina Virtual e deixa ela com pouca memória (ou tira memória fisica da sua máquina)... vc vai ver que qto mais Worker Processes (Application Pools) você tem, mais o disco é usado (e mais lento tudo fica).

    Respondi?


    Att.,


    Paulo Teixeira - PFE
    terça-feira, 4 de outubro de 2011 17:36
  • Exatamente! Vc pegou a idéia! Isso vai te dar isolamento (um processo não vai "atrapalhar" o outro), e ao mesmo tempo vai "aumentar" a capacidade de endereçamento das aplicações.

    Mas cuidado, tudo em excesso causa problemas... há um limite qto ao número de AppPools que você pode usar. Esse número não é "magico", ou seja, não é 5, 50, ou 500... vai variar de acordo com hardware/drivers/apps que vc tem no seu webserver. Minha experiência diz que um número abaixo de 60 é aceitável, mas como disse, não é uma regra, você tem que testar no seu ambiente.

    Att.,


    Paulo Teixeira - PFE
    terça-feira, 4 de outubro de 2011 17:39
  • Paulo, suas explicações são excelentes e bem esclarecedoras.

    Meu problema atual vendo sendo o tal do OOM ( out of memory ) em varias aplicações.

    Quando eu reduzo o limite de memória virtual das pools, ele recicla e isso não ocorra.
    Segundo suas informações, no meu entender, se eu tenho um unico work process eu tenho um total de 4Gb de memoria virtual para o processo que vai gerenciar todos os websites.

    Se eu aumento isso para X workprocess eu teria 4Gb para cada um o que aumentaria muito a quantidade disponivel de memoria virtual para cada aplicação.

    Estou errado quanto a isso ?

     

    Mais uma pergunta.. se o limite está na verdade nos barramentos , porque o windows libera 4Gb por processo.
    Não seria 4Gb ao total, para todos os recursos do windows ?

    Desculpe tanta pergunta mas suas respostas foram excelentes e acho que estas perguntas podem ajudar também a outros usuários já que não achei muito material esclarecedor sobre isso.

    terça-feira, 4 de outubro de 2011 18:37
  • Ok, vamos por partes:

    a) "Se eu aumento isso para X workprocess eu teria 4Gb para cada um o que aumentaria muito a quantidade disponivel de memoria virtual para cada aplicação"

    Sim, exatamente, mas há duas formas de fazer isso:

    • A primeira é criar vários application pools, cada um rodando um processo. Esse é o método recomendado.
    • Um outra forma é utilizar um único application pool, com vários processos (recurso chamado web garden). Nesse caso a aplicação pode ter problemas de controle de sessão (mensagens do tipo: "sua sessão expirou e será necessário logar novamente"). Este recurso pode ser usado, mas a aplicação precisa ter um mecanismo próprio para manter a sessão fora do IIS (por exemplo, num banco de dados, ou algo similar).

    b) "Se o limite está na verdade nos barramentos , porque o windows libera 4Gb por processo. Não seria 4Gb ao total, para todos os recursos do windows ? "

    O barramento endereça 2^32=4Gb de memória física, e esse é o limite do hardware. Na realidade, esclarecendo um pouco, há um recurso chamado PAE (Physical Address Extensions) que permite endereçar mais memória física (até o limite de 128Gb para máquinas 32bits). O que o Virtual Memory Manager faz é virtualizar o acesso a essa memória.

    Exemplificando, digamos que vc tenha o MS Word e ele tente alocar a posição 0x00001000 da memória. O VMM diz que está tudo ok e permite o acesso. Depois vc abre o Excel e ele também tenta alocar a posição 0x00001000 da memória, e o VMM também irá deixar isso acontecer... só que por trás de tudo, o VMM pega a área de memória (virtual) 0x00001000 usada pelo MS Word e coloca na posição 0x00002000 da memória FISICA, e coloca a área de memória (virtual) 0x00001000 usada pelo Excel e coloca na posição 0x00003000 da memória física. Ele (VMM) tem uma tabela onde tem um mapa de memória virtual de cada processo X memória física no hardware.

    Ou seja, a memória usada pelo Word está isolada (pela virtualização feita pelo VMM) da área de memória do Excel. Os processos (Word, Excel, etc) não invadem a área de memória um do outro, e o mapeamento da memória virtual para a memória fisica é transparente e feita pelo VMM. O VMM deixa que cada processo (Word, Excel, IIS, etc) ache que tem 4Gb de memória (virtual) e mapeia isso para a memória fisica seguindo um algoritmo interno dele.

    ok?


    Paulo Teixeira - PFE
    terça-feira, 4 de outubro de 2011 20:45
  • Paulo, novamente muito esclarecedor.

     

    Minha ultima pergunta.

    Como estabelecer o limite ideal para cada pool e o numero de pools ?

    1 pool para cada site, com 4Gb para cada pool ?

     

    Obrigado

    terça-feira, 4 de outubro de 2011 21:04
  • Acredito que você esteja falando de duas coisas distintas:

    a) Na configuração de Recycling do IIS, quais valores recomendados para o Limite de Virtual Memory e (physical) Memory: a resposta é nenhum, ou melhor, não se deveria usar esta configuração. Explico: quando se configura o IIS para fazer recycling ao atingir um certo limite de memória, isso significa que assumiu a sua aplicação TEM problemas de vazamento de memoria (ou memory leak), e que não vai fazer nada para corrigir isso. O ideal seria identificar o código da aplicação que tem problemas e corrigi-lo: uma aplicação "bem escrita" não tem memory leak, e portanto, não precisa de limites de memória ;-) 

    Mas, por outro lado, por exemplo no cenário de hosting, na maioria das vezes não se tem controle sobre as aplicações (dos clientes) que são colocadas no servidor. Nesse caso, não há também uma regra, mas a minha experiência pessoal diz que em torno de 60% da memória virtual é possível ativar o recycling, ou seja, se o processo é 32bits/32bits, haverá 2Gb de memória virtual disponível, e 60%=1.2Gb é o valor que eu começaria a pensar em colocar para fazer recycling. Se o processo for 32bits/64bits, ai vai ter 4Gb de memória virtual, o que dá 2.4Gb, aproximadamente.

    Nota: isso é o que eu tenho por experiência própria, não há uma recomendação oficial da Microsoft quanto a esses valores.

    b) "1 pool para cada site, com 4Gb para cada pool?": sim, ao menos 1 ApplicationPool para cada site, mas você pode ter mais: não há regra, você pode começar com 1 apppool por site, e se o site ainda estiver instável, você pode ir isolando as applicações em novos AppPools (dentro do mesmo site). Quanto ao "4Gb para cada pool", esse é o padrão, não deve-se mexer nesses valores, mudá-los pode trazer problemas indesejados, particularmente se o Windows for 32bits.

    Dica: Applicações instáveis logam HTTP Status 500 no log de requests. Use uma ferramenta como o LOGPARSER para descobrir as páginas que dão mais erro 500, essas devem ser as vilãs do seu servidor. Ai vc isola a Aplicação inteira em um AppPool separado.

    Att.,

     


    Paulo Teixeira - PFE
    quarta-feira, 5 de outubro de 2011 01:05
  • Paulo, definitivamente suas respostas foram as respostas mais completas que já recebi em todas as perguntas do forum.  Parabens.

    Eu nunca tive a teoria disso que você comentou mas por tentativa e erro , 2.5 giga foi sempre o que resultou em melhor resultado nos servidores, que dá bem o que você falou.

    Não entendi quando você disse 1 pool AO MENOS. Como você coloca mais de 1 pool no mesmo site ? , criando diretorios virtuais para cada pasta ?

    Você também diz acima,  "quanto "4Gb para cada pool", esse é o padrão, não deve-se mexer nesses valores, mudá-los"...

    O ideal não seria os 2.4 citados por você ?

    Obrigado pela dica do logparsers com erro 500. Vou testar isso hoje a noite.
    Pela primeira vez alguém deu uma luz sobre como identificar isso de uma forma pratica.

    Mais uma dúvida , abusando da sua boa vontade.

    Se eu abro uma pagina qualquer e verifico pelo taskmanager a quantidade de "PRIVATE BYTES". No primeiro acesso ele consome vamos supor 150 Mb.
    No segundo acesso da mesma página, se estiver tudo certo sem memory leak, ele deveria manter os mesmo 150 ? ou ele vai subindo até o GC fazer a limpeza ?

    Se for esta segunda opção, ao abrir uma página e verificar a memoria utilizada. Se eu forçar o GC a limpar tudo, no segundo acesso deveria ter exatamente a mesma memória ?

     

    Abraços

    quarta-feira, 5 de outubro de 2011 01:18
  • Paulo, definitivamente suas respostas foram as respostas mais completas que já recebi em todas as perguntas do forum.  Parabens.
    Eu nunca tive a teoria disso que você comentou mas por tentativa e erro , 2.5 giga foi sempre o que resultou em melhor resultado nos servidores, que dá bem o que você falou.
    Não entendi quando você disse 1 pool AO MENOS. Como você coloca mais de 1 pool no mesmo site ? , criando diretorios virtuais para cada pasta ?
    Sim, exatamente dessa forma. Num mesmo site, você pode ter vários diretórios virtuais/aplicações, cada um em um ApplicationPool diferente.
    Você também diz acima,  "quanto "4Gb para cada pool", esse é o padrão, não deve-se mexer nesses valores, mudá-los"...
    O ideal não seria os 2.4 citados por você ?
    Desculpe, acho que acabei te confundindo. Em relação ao recycling no IIS, sim, o ideal é manter os 2.4Gb que havia comentado. Explicando a frase acima, no Windows 32bits serão 4Gb de memória virtual, mas somente metade disponível (pois o restante está reservado para o Kernel). Há entretanto, um parâmetro usado no boot do Windows que permite mudar isso, por exemplo, para 3Gb para aplicação e 1Gb para Kernel. Só que usar este parâmetro não é recomendado para servidores Web (isso é comum em alguns cenários com Exchange e outros produtos).
    Para conhecimento (não use no Windows rodando o IIS) o parâmetro chama-se /3Gb  (para o Windows 2003) ou IncreaseUserVa (para o Windows 2008 e 2008 R2).
    Obrigado pela dica do logparsers com erro 500. Vou testar isso hoje a noite.
    Pela primeira vez alguém deu uma luz sobre como identificar isso de uma forma pratica.

    Mais uma dúvida , abusando da sua boa vontade.

    Se eu abro uma pagina qualquer e verifico pelo taskmanager a quantidade de "PRIVATE BYTES". No primeiro acesso ele consome vamos supor 150 Mb.
    No segundo acesso da mesma página, se estiver tudo certo sem memory leak, ele deveria manter os mesmo 150 ? ou ele vai subindo até o GC fazer a limpeza ?


    Não é tão rápido, a memória vai aumentando depois de horas, talvez dias. Exemplificando, as 09:00hs vai usar 150mb, as 12:00hs digamos que vai estar com 200mb, e as 18:00s pode já estar em 500mb... entre um request e outro dar uma "subidinha" e depois baixar é normal.

    Se no inicio do dia está em 150mb e no final do dia está em 800mb, 1Gb, pode realmente ter memory leak, mas se mantem uma valor constante, digamos que variando entre 150mb e 200mb ao longo do dia (subindo, descendo, subindo de novo, etc), então não é memory leak.
    rir

    Se for esta segunda opção, ao abrir uma página e verificar a memoria utilizada. Se eu forçar o GC a limpar tudo, no segundo acesso deveria ter exatamente a mesma memória ?
     
    Abraços
    Não, de jeito nenhum. Forçar o GC (com o GC.Collect()) é uma das piores coisas que se pode fazer para uma aplicação Web (cabe uma outra aula de horas sobre os problemas que isso traz ;-) ) ... Ao contrário do que muita gente imagina, rodar um GC.Collect() não necessariamente vai liberar a memória. O que vai fazer é bloquear todas as páginas (parar a execução no meio do caminho), tentar limpar (*) o que for possível, e depois voltar a executar as páginas. Leia-se em (*) que isso significa varrer todas os objetos em memória verificar se ele pode ou não ser liberado, o que pode ser uma tarefa muito intensiva. E como disse, enquanto isso está acontecendo, a execução das suas páginas fica "congelada". Para completar, se vc coloca isso no código de uma página, isso irá acontecer toda vez que um usuário for usá-la, o que vc deve concordar comigo, é algo totalmente imprevisível... pode acontecer 1 vez ao dia, ou 30 vezes por segundo!!!!! (o que seria terrível para sua app).

    Paulo Teixeira - PFE
    quarta-feira, 5 de outubro de 2011 02:36
  • Paulo,

     

    não sei qual memoria exatamente agente visualiza pelo task maanger, mas na coluna mem usage tenho pool que sobe 1Mb por minuto mais ou menos.
    Seria um memory leak com toda certeza ? rsrs

    A propósito, nunca na minha vida consegui fazer a pool passar de 300 Mb. Independete da configuração ou limites, sempre que chega em 300 Mb ela recicla :(

    Abraços

    quarta-feira, 5 de outubro de 2011 02:48
  • Pode estar reciclando por algum outro motivo, uma dica é olhar o log de eventos de aplicação (Application Event Log) e olhar a Origem (Source) W3SVC ... lá tem os motivos pelo qual um pool foi reciclado. Pode ser que a aplicação tenha travado por algum outro motivo e foi reciclada. Outra dica é a que já falei, de olhar os logs do IIS com o logparser. Tem uns exemplos de comandos logparser no site: www.logparserplus.com/examples

    Att.,


    Paulo Teixeira - PFE
    quarta-feira, 5 de outubro de 2011 03:46
  • Paulo, a informação é exatamente de memoria virtual :

     

    A worker process with process id of '498112' serving application pool 'pool4' has requested a recycle because it reached its virtual memory limit. 
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Isso ocorre em cerca de 60 segundos em 60 segundos :(


    quarta-feira, 5 de outubro de 2011 12:27
  • Rafael,

    seria bom rever a configuração do Application Pool (clicar com botão direito > Properties > Recycling). O valor de Virtual Memory Limit pode estar com algum valor que está sendo atingido rapidamente, causando este recycle. É pouco provável que algum outro fator esteja causando isso.

    Att.,


    Paulo Teixeira - PFE
    quinta-feira, 6 de outubro de 2011 02:58
  • Paulo, pior que está com 2.500 , mas como te disse, a memoria sobre 1 Mb por minuto .... algo muito errado deve ter..

     

    quinta-feira, 6 de outubro de 2011 03:35
  • Bom,

    uma idéia é retirar totalmente o limite que houver. Ai o AppPool vai crescer até travar, e causar um erro fatal (crash).

    Mas antes disso, você vai precisar instalar a ferramenta DebugDiag 1.2 no servidor. Depois abra a ferramenta e crie uma regra para captura de CRASH MEMORY DUMP para o Application Pool que está com problemas; pode usar os valores padrão (Next, Next, Finish).

    Quando o problema acontecer (pelo que você disse, será rápido), a ferramenta irá gerar um MEMORY DUMP (um arquivo com a extensão .dmp). Use a própria ferramenta para rodar a análise automática e tentar descobrir a causa do CRASH. A ferramenta (as vezes) dará uma pista do problema. A ferramenta também permite fazer o "tracking" de problemas de memória, mas ai é um pouco mais complicado... se vc estudá-la um pouco talvez consiga fazer isso e obter informações adicionais da causa do problema no ambiente.

    Não se esqueça de colocar o limite de recycling de volta (para manter o ambiente estável) depois de coletar o dump de memória.

    Att.,

    Paulo.


    Paulo Teixeira - PFE
    quinta-feira, 6 de outubro de 2011 05:41
  • Rafael,

     

    Se possivel marque as respostas que lhe ajudaram.

     

    []s


    Erick Albuquerque | Microsoft MVP
    MVP Profile | Twitter | Linkedin | http://iisbrasil.wordpress.com
    segunda-feira, 10 de outubro de 2011 14:11
    Moderador
  • Feito Erik.

    Obrigado a todos.


    terça-feira, 11 de outubro de 2011 22:19