Problemas de instabilidade nos servidores de terminal de 32 bits do Windows 2003 R2

Question

Estamos com problemas de instabilidade em alguns dos TS do Windows 2003 de 32 bits.

Depois de muita pesquisa no Google minhas suspeitas são de que está ficando sem entradas de tabela de páginas (PTE's).

Pelo que eu posso entender, este é um problema ao usar a opção / 3gb em servidores Windows de 32 bits, e com o TS 'você pode facilmente atingir o limite.

Como você pode verificar que isso é o que está acontecendo? Eu não tenho experiência com perfmon e experiência limitada com o Process Explorer, e eu realmente não sei o que estou procurando.

Mais informações: Sempre, a lista de processos do gerenciador de tarefas fica vazia quando isso acontece, e os contadores de memória também ficam em branco. O servidor normalmente tem apenas cerca de 65 usuários quando isso acontece, mas eles executam o MSO e diferentes softwares de contabilidade. Algumas delas são muito mal escritas e inchadas. O uso comum de memória por usuário é de 200 a 600 MB, mas nossos servidores nunca ficam sem RAM disponível. Algumas impressoras estão instaladas nos servidores, às vezes até 20. Os servidores estão funcionando sem problemas com 70 a 80 usuários há alguns anos, mas foram reduzidos à medida que pareciam estabilizá-los.

    

Answer 1

A memória do kernel do Windows Server 2003 x86, por padrão, é muito pouco configurada para um servidor de terminal muito usado.

Para visualizar os valores reais em uso no sistema em execução, você pode usar o Process Explorer do SysInternal, em Visualizar > Informação do sistema. Se o sistema estiver configurado para usar a quantidade máxima de Pool Paginado e Pool Não Paginado, o Limite Paginado será de 512 MB e o Limite Não Paginado será de 256 MB.

Paramostraresteníveldedetalhe,ossímbolosapropriadosdevemsercarregadosemOpções>Configurarsímbolos:

Se o Paged Physical ou Nonpaged estiver se aproximando do limite, haverá instabilidade do sistema. Os valores do registro que configuram esses limites máximos estão localizados em:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"PagedPoolSize"=dword:FFFFFFFF
"SystemPages"=dword:FFFFFFFF

É importante notar que ter uma grande quantidade de memória física pode não ser útil, já que as janelas x86 só podem usar uma pequena quantidade para o espaço de memória do kernel e não podem crescer além do que é mostrado no limite. (os limites de memória do kernel x64 são muito menos restritivos). O limite é calculado dinamicamente no momento da inicialização do sistema com base nas configurações disponíveis de memória e registro.

Você pode obter mais detalhes sobre o que está usando a memória do kernel com os seguintes comandos do Windows Debugger:

!vm - mostra informações semelhantes aos limites de memória do kernel do explorador de processos.
! poolused n - exibe informações sobre o uso de conjuntos paginados / não paginados. Isso às vezes pode ser útil se um driver tiver um vazamento de memória que esteja consumindo memória do kernel em excesso.

! Comando poolused
link

! comando vm
link

    

Answer 2

70 a 80 usuários em um TS de 32 bits parece muito para mim. Nosso número de planejamento sempre foi de 50 a 65 usuários. Quanta memória RAM está nos servidores?

Usar o / 3GB em um TS causará problemas de desempenho e estabilidade. Eu vi em primeira mão. Ele começa com a impossibilidade de carregar perfis de usuário e, rapidamente, se expande a partir daí. Minha sugestão seria remover a opção / 3GB e ver o que afeta o desempenho e a estabilidade.

    

Answer 3

Você pode encontrar uma descrição de como determinar o uso da memória do kernel em meu artigo Windows x64 - Todos os mesmos, mas muito diferentes, Parte 2: Memória do kernel, / 3GB, PTEs, (Não) Conjunto de páginas pagas .

Em resumo, usando o WinDbg em combinação com o LiveKD, você pode estabelecer uma sessão de depuração ao vivo com a máquina local. A partir daí, é fácil consultar itens como PTEs gratuitos, uso e máximo de pool (não) paginado.