w3wp.exe suga memória

Em uma instalação do Small Business Server 2011, vários processos do w3wp.exe parecem estar usando uma quantidade desproporcional de memória. As instalações prontas para uso do SBS vêm com um total de 7 sites e 20 pools de aplicativos ASP.NET (itens específicos do Sharepoint, Exchange, WSUS e SBS, como Remote Web Workplace).

A dúzia resultante de processos w3wp.exe tende a consumir mais de 4 GB de memória do servidor ao longo do tempo, sendo o pool de aplicativos de pico o pertencente ao WSUS com cerca de 800 MB no conjunto de trabalho. Reciclar manualmente os pools de aplicativos por meio do MMC do IIS ajuda a reduzir temporariamente o uso de memória (os processos w3wp.exe diminuem para 10 MB, alguns deles se recuperam rapidamente), mas obviamente não é algo que um administrador deseja fazer o dia todo. Não consegui encontrar nenhuma recomendação sobre a reciclagem automática dos pools de aplicativos pré-instalados pelo SBS, por isso estou um pouco relutante em "simplesmente fazê-lo" nos sistemas de produção.

Minha pesquisa na rede sobre como limitar isso apenas levantou várias postagens afirmando que o consumo de memória w3wp não prejudicaria, mas beneficiava o desempenho, pois a memória seria "liberada quando necessário por outros aplicativos". O problema é que não funciona:

• por um lado, um SBS é um servidor com várias funções, uma das funções (a principal) sendo o armazenamento em rede CIFS, que se beneficia imensamente do cache do sistema de arquivos, que novamente depende da memória estar "livre", como em "não usada por outros processos em qualquer way "- pools de aplicativos ASP.NET que quase nunca vêem usuários e comem memória são contraproducentes
• Outra coisa é que ainda tenho que ver uma diminuição substancial do consumo de memória das instâncias w3wp devido à falta de memória - o que vejo é uma pequena redução de menos de 100 mb e troca excessiva - prejudicando o desempenho

Quase nunca administro aplicativos IIS ou ASP.NET, portanto, todas as idéias sobre como aparar efetivamente os requisitos de memória para os pools de aplicativos são bem-vindas.

Bem-vindo ao maravilhoso mundo da SBS. Requisitos recomendados para RAM = 10 GB ... e EXIGE um mínimo de 8 GB. (de acordo com a Microsoft .) por um bom motivo. Não é uma máquina bem oleada e bem afinada ... é muito desleixada, inchada e tem tudo sob o sol reunido. Quanto mais RAM você puder jogar nessa caixa ... melhor. Infelizmente, você está limitado a 32 GB no máximo. Qual imho ... é bobo.

Isto é o que acabei fazendo:

configurando o cache do aplicativo de servidor para o .NET AppPools como um valor baixo (5 MB), definindo o parâmetro privateBytesLimit no web.configat %WINDIR%\Microsoft.NET\Framework\<version>\Configcomo sugerido nesta resposta :

    <configuration>
      <system.web>
         <caching>
           <cache privateBytesLimit="5242880" privateBytesPollTime="00:01:00" />
         </caching>
      </system.web>
    </configuration>

Isso ajudou a reduzir o uso de memória para um pouco mais de 1 GB com as configurações padrão de reciclagem de pool.

Aparentemente, o uso do tipo "servidor" de coletor de lixo ( <gcServer = "true">) também pode levar a um consumo significativo de memória , mas, ao que parece, <gcServer>é definido como falso por padrão.

Se você suspeitar que o consumo de memória resultante é um problema devido a um defeito de software, poderá usar o Microsoft DebugDiag 1.2 para criar um despejo de memória completo e analisar o despejo quanto a problemas comuns. Se você acha que pode haver um problema de memória, é necessário ativar o rastreamento de vazamentos selecionando a opção "Monitorar vazamentos" e deixá-lo funcionar por um tempo antes de criar / analisar o despejo.

DebugDiag 1.2 Baixe
https://www.microsoft.com/download/en/details.aspx?id=26798

Você não precisa de um pool de aplicativos separado para cada aplicativo, apenas aqueles que não são confiáveis ​​ou aos quais deseja dar prioridade. Muitos podem compartilhar (mantendo diferentes versões .net separadas). Você pode limitar de forma mais realista a memória que um pool de aplicativos usará. Não deve haver necessidade de reciclar conjuntos repetidamente mais de uma vez por dia.

Além disso, há apenas tanta memória que pode ser liberada dessa maneira. Embora alguns deles sejam armazenados em cache, cada aplicativo precisa de uma certa quantidade de memória de trabalho, altamente dependente do aplicativo Web específico. Tentar restringir muito isso vai fazer com que as coisas parem.

O problema realmente é que o SBS tenta fazer muita coisa de uma só vez, você precisa observar o que realmente usa e desligar o que não usa.

Mas, para ser sincero com apenas 11 usuários, para onde está indo o resto da memória? Exchange e SQL para uso leve certamente não precisam de mais de 12 GB!