2008 R2 Terminal Server: “Recursos do sistema insuficientes existem para concluir o serviço solicitado”

Question

Estou trabalhando com um Windows 2008 R2 Terminal Server não-íntegro configurado em um ambiente vSphere. Atualmente, possui 4 vCPUs e 32 GB de RAM. Sem comprometimento excessivo.

A contagem de usuários simultâneos neste servidor aumentou acentuadamente nos últimos meses (~ 70) e está possivelmente acima do nível recomendado. Devido aos aplicativos usados pelos usuários neste sistema, dividi-lo em vários servidores será um desafio além do escopo desta questão.

No entanto, em determinados pontos durante a semana (e agora, quase diariamente), novos logons de usuários produzem os seguintes erros: ID do Evento 1500

Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly.

DETAIL - Insufficient system resources exist to complete the requested service.

Isso permanece até que alguns usuários efetuem logoff, as sessões sejam desconectadas manualmente ou o sistema seja totalmente reinicializado.

Eu gostaria de saber:

• Em qual recurso esta mensagem de erro está se referindo? O que é realmente restrito?
• Existe um ajuste ou configuração no nível do sistema operacional que possa ajudar com isso?
• Os usuários estão satisfeitos com o desempenho, exceto pelo aumento da frequência dessa mensagem de erro. Há algo mais em jogo aqui?
• Existe um limite absoluto para o número de usuários que um servidor de terminal pode acomodar? Eu vejo mais de 150 usuários descritos em certos guias de ajuste para servidores de terminal.

    

Answer 1

Isso foi resolvido.

Comecei a examinar o registro porque aumentar os recursos de CPU e RAM na máquina virtual não resolveu o problema.

Fui apontado para o dureg da Microsoft para estimar o tamanho do registro. Navegando via regedit, encontrei problemas para abrir as chaves em HKEY_USERS\.Default\PRINTERS . Usando dureg , comecei a investigar nessa hierarquia.

As impressoras eram o problema. A causa e a correção são detalhadas em: O tamanho da seção de registro "HKEY_USERS.DEFAULT" aumenta continuamente em um Windows Servidor baseado no servidor 2008 R2 SP1

Hotfix: link

Isso aparentemente impede o crescimento, mas as chaves e o registro precisam ser compactados para recuperar espaço.

Como compactar o registro inchado: link

1)  Boot from a WinPE disk.
2)  Open regedit while booted in WinPe, load the bloated hive under HLKM. (e.g. HKLM\Bloated)
3)  Once the bloated hive has been loaded, export the loaded hive as a "Registry Hive" file with a unique name.
4) Unload the bloated hive from regedit.
5) Rename the hives so that you will boot with the compressed hive.
e.g.
c:\windows\system32\config\ren software software.old
c:\windows\system32\config\ren compressedhive software

Hmm, alguns passos ... meio complicado de fazer remotamente durante as horas de produção. Tentei entrar em contato com meu especialista da Microsoft residente para concluir, mas ele estava ocupado procurando algum SCCM ou SCVMM problema em algum lugar . Lendo alguns fóruns relacionados ao Citrix, tomei nota de uma ferramenta que poderia executar o acima com menos etapas ...

Então peguei um instantâneo de máquina virtual, baixei e executei software de compactação de registro freeware (Tweaking.com) ; apesar do som esmagador dos gemidos coletivos dos engenheiros de sistemas da Microsoft em todos os lugares ...

observe os 1,4 GB salvos no Config padrão ...

REBAJAM POR FAVOR!

Após uma reinicialização, tudo estava bem. A contagem de usuários atingiu 86 sem efeitos negativos e sem erros relacionados ao perfil. Eu monitorei a seção de registro da impressora e ficou estável.

    

Answer 2

No Windows Server 2003, esse erro foi resultado do esgotamento da memória do kernel. Como você está lidando com o Windows Server 2008 R2, não tenho certeza de como a causa do problema está intimamente relacionada à causa no W2K3, mas aposto que é um problema de memória devido ao número de usuários e processos. Eu daria uma olhada no esgotamento da memória do pool não paginado como a causa provável. Além disso, o número de processos é de quase 800, o que é bastante alto. O MS provavelmente diria para você reduzir o número de processos, o que só pode ser feito reduzindo a carga do usuário.

Este artigo tem boas informações sobre o uso da memória no Windows e como você pode visualizar o limite do pool não paginado para ver se essa é a causa do problema:

link

    

Answer 3

Inicie o Monitor de desempenho do Windows para monitorar os vários contadores:

• Interruptores de contexto
• Entradas da tabela de páginas
• elementos GDI
• Handles
• … (o que você encontrar)

E veja se um desses picos quando você recebe um login com falha.

Além disso, algo está causando alta% de CPU do kernel em seu sistema - você deve investigar isso para ver se ele leva a um problema relacionado.

O serviço Limpeza do perfil do usuário pode ajudar aqui, já que " ajuda a garantir que as sessões do usuário sejam completamente encerradas quando um usuário efetua logoff ".

    

Answer 4

Eu tenho muito pouco tempo, então vou fazer uma resposta incompleta e esperançosamente dar mais detalhes.

Quando fazia feitiços em equipes Citrix, lembro-me de tentar subir de 15 a 20 usuários por servidor, mas esses tinham alguns aplicativos pesados em execução. Nos dias de hoje, carregamos mais usuários, mas 70+ soa muito.

O contador de perfmon maxing out raramente não era comutação de contexto, ele funcionava como um servidor, enquanto outros contadores como RAM, CPU etc pareciam bons. Possivelmente, isso poderia ser um motivo (o servidor não pode alocar recursos antes do tempo limite devido à alternância de contexto excessiva). Aqui estão duas maneiras de monitorar a alternância de contexto :

The System\Context Switches/sec counter in 
System Monitor reports systemwide context 
switches.

The Thread(_Total)\Context Switches/sec  
counter reports the total number of context 
switches generated per second by all threads.

Além disso, você pode encontrar algo de útil no guia de planejamento de capacidade, você encontra um link para ele em este post de blog .

Quando posso responder a essa resposta, vou adicioná-la, tomando cuidado em todas as medições baseadas em tempo em uma máquina virtual do vSphere.

Devido a como a vCPU foi abstraída das CPUs físicas, a vCPU não tem a menor idéia de que horas são (um segundo virtual pode ser maior ou menor que um real (ou pelo menos físico) em segundo lugar. todos os contadores de perfmon baseados em tempo (tempo de CPU, interrupções de contexto / seg e assim por diante) são imprecisos (às vezes até descontroladamente), mesmo que possam servir como indicadores de granulação grosseira.

Para verificar isso, compare qualquer contador de CPU baseado em tempo nativo na VM com sua contraparte no host do vSphere para essa VM. Por esse motivo, a VMware publica alguns contadores para CPU (e Memória, que também é imprecisa da perspectiva do convidado) por meio de ferramentas VMware em dois objetos perfmon do VMguest.

Assim, os valores baseados em tempo corretos são disponibilizados a partir do perfmon convidado, mas somente se olharmos para os contadores de objetos publicados do VMware.

Eu apenas achei essas informações básicas um pouco relevantes, já que as respostas até agora estão focadas em medições baseadas em tempo de dentro de uma máquina virtual do vSphere, em que isso é, em alguns casos, uma circunstância crucial para a análise correta. Também, claro, se relaciona diretamente com o tema desta resposta particular (inacabada) e seus comentários. Pode ser útil para alguém.

Assim que eu tiver tempo, vou editar em links para os white papers, etc, que elaboram sobre isso, e os contra-caminhos exatos \ nomes. Naturalmente, tudo é googleable também.

    

Answer 5

Bem, pelo que li sobre o planejamento de capacidade do RDS no Server 2008 R2, talvez você esteja apenas executando seu servidor de terminal deficiente com recursos insuficientes para o número de usuários que você usa. Em particular, percebo que você tem 80 usuários em 4 vCPUS e a MS recomenda 1 núcleo por 15 usuários.

Do blog da technet intitulado Orientação de dimensionamento de capacidade e dimensionamento de RDS :

We always felt the need of Hardware capacity guidance and sizing information for Terminal Services or Remote Desktop services for Server 2008 R2, Whenever I am engaged in any architectural guidance discussion for RDS deployment i always get a question what needs to be taken into consideration while deciding the hardware configuration and to do capacity planning.

Here are some bullet points which I recommend to my partners and customers to consider:

• Memória de 2 GB (RAM) é o limite ideal para cada núcleo de uma CPU. Por exemplo. Se você tem 4 GB de RAM, então, para um ótimo desempenho, deve haver CPU dual core.
• 2 CPU Dual Core tem melhor desempenho do que o processador quad core simples.
• Largura de banda recomendada para LAN de 30 usuários e WAN de 20 usuários. Largura de banda (b) = 100 megabits por segundo (Mbps) com latência (l) menor que 5 milissegundos.
• Em um Terminal Server, 64 MB por usuário é o requisito da Memória Ideal (RAM) para GP Use apenas + 2 GB para o SO E.g. (100 usuários * 64) + 2000 = 8,4 GB, ou seja, 8 GB de RAM.
• Mais aplicativos usados (por exemplo, Office, CAD Apps e etc.) exigirão mais memória por usuário para serem adicionados a esse cálculo na memória base de 64 MB por usuário.
• A sessão de 15 TS por núcleo da CPU é o limite ideal de desempenho de um Terminal Server.
• A rede não deve ter mais do que 5 saltos e a latência deve ser inferior a 100 ms.
• 64 kbps é a largura de banda ideal por sessão do usuário. (256 cores, rede comutada, somente cache de bitmap)
• O desempenho da CPU degrada se% do tempo do processador por núcleo estiver constantemente acima de 65%.
• O desempenho dos servidores de terminal dobra quando está sendo executado em um X64 HW e sistema operacional.

In addition to that, Microsoft has just released a whitepaper on Capacity Planning in Windows Server 2008 R2.

Faça o download aqui

    

Answer 6

Eu sugeriria implementar o WSRM (Windows System Resource Manager). Quando há uma tonelada de aplicativos, conexões, serviços em execução em um host, o sistema não sabe que todos precisam jogar bem juntos. O Windows Server tenta naturalmente usar todos os recursos para concluir tudo o tempo todo, a menos que seja informado ... digite WSRM.

Ao implementar o WSRM, você pode definir limites de recursos por todos os tipos de variações para garantir que haja um campo de jogo uniforme para tudo que está em execução ou para os usuários conectados. De suas anotações, isso não parece ser um problema do ESX / vSphere, mas sim de muitos usuários conectados que estão constantemente competindo por tudo. Você terá que testar o WSRM para encontrar um meio feliz de equilibrar recursos entre todos, mas também não afetando os níveis de desempenho aos quais todos se acostumaram.

Visão geral do WSRM: link