Percebemos um problema em que sessões de área de trabalho remota em um servidor congelam quando o servidor tem alta carga de CPU.
Ambiente:
- VMWare ESX 4.0u1.
- O SO convidado é o Windows Server 2008 R2 (esse é o servidor de congelamento).
- O sistema operacional convidado tem o MS SQL Server 2008 R2 (10.50.4000) e aplicativos internos que são executados como serviços do Windows.
- O cliente de área de trabalho remota normalmente está em um laptop com Windows 7.
Conectar o RDP ao servidor funciona bem. Quando o servidor é carregado, isso acontece:
- Uma sessão RDP existente não responde e parece congelar - pelo menos a tela não é atualizada. Se um gerenciador de tarefas estiver em execução, ele ficará estático, pois você não verá mais a atualização das estatísticas a cada poucos segundos. Você pode clicar em um botão ou algo assim, e a resposta visual será adiada por vários minutos.
- Uma sessão de console via ferramenta de administração do vmware parecerá congelar da mesma maneira. (Então, basicamente, parece afetar GUI / interatividade).
- Tentar se conectar por meio do RDP durante esse estado levará um período extremamente longo e, com frequência, exibirá apenas uma tela preta que nunca é resolvida para a GUI real.
-
Outros serviços continuam respondendo! Se o aplicativo da Web em execução no servidor for acessado de um navegador em outra máquina, ele responderá com bastante rapidez e parecerá quase não afetado pela alta carga. Um monitor de processo remoto que acessa o servidor de "congelamento" usando o WMI também continua funcionando.
O carregamento nesse cenário normalmente consiste no Processo A fazendo uma mistura sequencial (sem threads) de cálculos e chamadas para o Processo B. Ao receber tal chamada, o Processo B normalmente fará uma chamada de banco de dados seguida de alguns cálculos, retornando resultado para o processo A.
No gerenciador de processos remotos, podemos confirmar que o Process A, B e o SQL Server juntos ocupam 100% da CPU, mas devido às chamadas seqüenciais entre os processos, nunca deve haver mais do que um processo pronto para ser executado em qualquer ponto dado no tempo. Esses processos são serviços do Windows e não interagem com a GUI de forma alguma.
É como se o Windows privasse completamente o componente GUI dos ciclos da CPU quando outros processos estão causando carga.
Fiz algumas experiências apenas para verificar - por ex. se eu executar três cópias de um loop ocupado no meu laptop, cada uma delas ocupará 33% da CPU, o total será relatado como 100%, mas a GUI do Windows, em geral, ainda responderá totalmente.
O que faz com que a GUI do servidor congele assim sob carga, e o que pode ser feito para impedir que isso ocorra?
A vm tem 6 GB de RAM, o SQL Server é restrito a 2 GB de RAM, os outros serviços envolvidos são tipicamente menores que 200 MB cada. Portanto, não parece ser exaustão de memória.
Os serviços estão sendo executados com prioridade Normal, mas eu também os reduzi para "Abaixo do normal", sem nenhuma mudança real no comportamento.
Atualização 1
Na tentativa de reduzir o problema, tentei isso:
- No servidor, na prioridade normal, execute um processo personalizado que é apenas um loop ocupado. Como pretendido, isso maximiza a CPU em 100%. Durante esse tempo, o sistema ainda é perfeitamente responsivo para o usuário interativo .
- Emita uma consulta intensiva de dados e CPU ao SQL Server (
select * from dbo.Table where Name like '%flarp%' repetido 6 vezes no mesmo lote de comandos). A tabela tem 1,6 milhão de registros. Nenhum outro processo está levando recursos significativos da CPU. Quando a consulta é executada, a GUI congela completamente até que o lote de consulta seja concluído. Defino a prioridade do SQL Server como LOW e repito. Ainda congela a GUI.
- Experimente os dois itens acima ao mesmo tempo. Eu comecei o loop da CPU (com prioridade normal) primeiro e demora 100%. Quando, pouco depois, inicio a consulta SQL (no SQL Server de baixa prioridade), a GUI congela completamente. O gerenciador de processo remoto indica que o SQL Server, apesar de ser de baixa prioridade, recebe 100% da CPU enquanto o loop da CPU (na prioridade normal) está em 0% até que a consulta seja concluída. Portanto, apesar do servidor sql ter uma prioridade mais baixa, ele morre completamente o loop da CPU.