2008 R2 Terminal Server: "Existem recursos insuficientes do sistema para concluir o serviço solicitado"

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 compromisso.

A contagem de usuários simultâneos nesse servidor aumentou bastante nos últimos meses (~ 70) e possivelmente está acima do nível recomendado. Devido aos aplicativos usados ​​pelos usuários neste sistema, dividir isso em vários servidores será um desafio além do escopo desta pergunta.

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

O Windows não pode fazer logon porque seu perfil não pode ser carregado. Verifique se você está conectado à rede e se a sua rede está funcionando corretamente.

DETALHE - Existem recursos insuficientes do sistema para concluir o serviço solicitado.

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

Eu gostaria de saber:

• A que recursos esta mensagem de erro se refere? 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? Vejo mais de 150 usuários descritos em alguns guias de ajuste para servidores de terminal.

Isso foi resolvido.

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

Fui apontado para o Microsoft ferramenta duregpara estimar o tamanho do registro. Ao navegar pelo regedit, encontrei problemas ao abrir as chaves emHKEY_USERS\.Default\PRINTERS. Usandodureg, comecei a investigar sob essa hierarquia.

Impressoras eram o problema. A causa e a correção estão detalhadas em:
O tamanho da seção do Registro "HKEY_USERS.DEFAULT" aumenta continuamente em um servidor baseado no Windows Server 2008 R2 SP1

Hotfix: http://support.microsoft.com/kb/2871131

Aparentemente, isso interrompe o crescimento, mas as chaves e o registro precisam ser compactados para recuperar espaço.

Compactando o registro inchado: http://support.microsoft.com/kb/2498915

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 o horário de produção. Tentei entrar em contato com meu especialista residente da Microsoft para concluir, mas ele estava ocupado procurando algum problema do SCCM ou do SCVMM em algum lugar . Lendo alguns fóruns relacionados ao Citrix, observei uma ferramenta que poderia executar o procedimento acima com menos etapas ...

Então, tirei um instantâneo da máquina virtual, baixei e executei software de compactação de registro de 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 na configuração padrão ...

POR FAVOR REINICIE!

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

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 da relação entre a causa do problema e a causa no W2K3, mas aposto que é um problema de memória devido ao número de usuários e processos. Eu daria uma olhada na exaustão de memória de Nonpaged Pool como a causa provável. Além disso, o número de processos é de quase 800, o que é bastante alto. A Microsoft provavelmente diria para você reduzir o número de processos, o que só pode ser feito reduzindo a carga do usuário.

Este artigo possui algumas informações boas sobre o uso de memória no Windows e como você pode exibir o limite de pool não paginado para verificar se essa é a causa do problema:

https://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx

Inicie o Windows Performance Monitor para monitorar os vários contadores:

• Opções de contexto
• Entradas da Tabela de Páginas
• Elementos GDI
• Alças
• ... (o que você puder encontrar)

E veja se um desses picos ocorre quando um logon falha.

Além disso: algo está causando uma alta porcentagem de CPU do kernel no seu sistema - você deve investigar isso para ver se isso leva a um problema relacionado.

O serviço de limpeza de seção de perfil de usuário pode ajudar aqui, pois "ajuda a garantir que as sessões do usuário sejam completamente encerradas quando um usuário fizer logoff".

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

No blog da technet, intitulado RDS Sizing and Capacity Planning Guidance :

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:

• 2GB de memória (RAM) é o limite ideal para cada núcleo de uma CPU. Por exemplo, se você possui 4 GB de RAM, para obter o desempenho ideal, deve haver CPU de núcleo duplo.
• 2 A CPU Dual Core tem melhor desempenho que o processador Quad core único.
• 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 servidor de terminal, 64 MB por usuário é o requisito de memória ideal (RAM) para GP. Use apenas 2 GB para SO, por exemplo (100 usuários * 64) + 2000 = 8,4 GB, ou seja, 8 GB de RAM.
• Mais aplicativos usados ​​(por exemplo, Office, aplicativos CAD e etc.) exigirão que mais memória por usuário seja adicionada a esse cálculo na memória base de 64 MB por usuário.
• 15 sessão TS por núcleo de CPU é o limite de desempenho ideal de um Terminal Server.
• A rede não deve ter mais de 5 saltos e a latência deve estar abaixo de 100ms.
• 64 kbps é a largura de banda ideal por sessão do usuário. (256 cores, rede comutada, apenas cache de bitmap)
• O desempenho da CPU diminui se a% de tempo do processador por núcleo estiver constantemente acima de 65%.
• O desempenho dos servidores de terminal duplica quando está sendo executado em um X64 HW e OS.

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

Faça o download aqui

Eu tenho muito pouco tempo, então eu darei uma resposta superficial e espero esclarecer mais tarde.

Quando eu fazia magias nas equipes da Citrix, lembro que tentamos nivelar de 15 a 20 usuários por servidor, mas eles tinham alguns aplicativos pesados ​​em execução. Nos dias de x64, carregamos mais usuários, mas mais de 70 parece muito.

O limite máximo do contador perfmon não era raramente a alternância de contexto, seria usado no servidor, enquanto outros contadores, como RAM, CPU, etc, pareciam bons. Possivelmente, esse poderia ser um motivo (o servidor não pode alocar recursos antes do tempo limite devido à excessiva alternância de contexto). 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, e encontra um link para ele nesta postagem do blog .

Quando eu puder dedicar um tempo a esta resposta, eu o farei, acrescentarei aqui jogando com cautela em todas as medições baseadas no tempo em uma máquina virtual vSphere.

Devido à forma como a vCPU foi abstraída das CPUs físicas, a vCPU não tem idéia de que horas são (um segundo virtual pode ser mais ou menos que um segundo real (ou pelo menos físico). Como conseqüência, o tempo todo é baseado os contadores perfmon (tempo da CPU, alternância de contexto / s e assim por diante) são imprecisos (às vezes até muito intensos), mesmo que possam servir como indicadores granulares muito grosseiros.

Para verificar isso, compare qualquer contador de CPU baseado em tempo nativo na VM com o seu equivalente no host do vSphere para essa VM. Por esse motivo, o VMware publica alguns contadores para CPU (e memória, que também são imprecisos da perspectiva do convidado) por meio das ferramentas VMware em dois objetos perfmon do VMguest.

Portanto, os valores corretos com base no tempo são disponibilizados no perfmon convidado, mas apenas se observarmos os contadores de objetos publicados da VMware.

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

Assim que tiver tempo, editarei os links para os whitepapers, etc, que são detalhados sobre isso e os caminhos / nomes exatos dos contadores. Naturalmente, é tudo googleable também.

Eu sugeriria a implementação do 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 naturalmente tenta usar todos os seus recursos para concluir tudo o tempo todo, a menos que seja informado ... entre no WSRM.

Ao implementar o WSRM, você pode definir limites de recursos por todo tipo de variação, para garantir que exista um campo de jogo uniforme para tudo o que está sendo executado ou usuários conectados. Das 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ê precisará testar o WSRM para encontrar um meio feliz de equilibrar recursos entre tudo, mas também não afetando os níveis de desempenho com os quais todos se acostumaram.

Visão geral do WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx