2008 R2 Terminal Server: "Existen recursos de sistema insuficientes para completar el servicio solicitado"

Estoy trabajando con un Terminal Server de Windows 2008 R2 no saludable configurado en un entorno vSphere. Actualmente tiene 4 vCPU y 32 GB de RAM. Sin compromiso excesivo.

El recuento de usuarios simultáneos en este servidor ha aumentado considerablemente en los últimos meses (~ 70), y posiblemente esté por encima del nivel recomendado. Debido a las aplicaciones utilizadas por los usuarios en este sistema, dividir esto en múltiples servidores será un desafío más allá del alcance de esta pregunta.

Sin embargo, en ciertos momentos durante la semana (y ahora, casi a diario), los inicios de sesión de nuevos usuarios producen los siguientes errores: Identificador de evento 1500

Windows no puede iniciar sesión porque su perfil no se puede cargar. Compruebe que está conectado a la red y que su red funciona correctamente.

DETALLE: existen recursos del sistema insuficientes para completar el servicio solicitado.

Esto permanece hasta que algunos usuarios cierren sesión, las sesiones se desconectan manualmente o el sistema se reinicia por completo.

Me gustaría saber:

• ¿A qué recurso (s) se refiere este mensaje de error? ¿Qué es realmente restringido?
• ¿Existe una configuración o configuración ajustable a nivel de sistema operativo que pueda ayudar con esto?
• Los usuarios están contentos con el rendimiento, excepto por la mayor frecuencia de este mensaje de error. ¿Hay algo más en juego aquí?
• ¿Existe un límite absoluto para la cantidad de usuarios que puede alojar un servidor de terminal? Veo más de 150 usuarios descritos en ciertas guías de ajuste para servidores de Terminal Server.

Esto ha sido resuelto.

Comencé a examinar el registro porque el aumento de los recursos de CPU y RAM en la máquina virtual no resolvió el problema.

Me señalaron la herramienta dureg de Microsoft para estimar el tamaño del registro. Navegando a través de regedit, encontré problemas al abrir las teclas debajo HKEY_USERS\.Default\PRINTERS. Utilizando dureg, comencé a investigar bajo esa jerarquía.

Las impresoras fueron el problema. La causa y la solución se detallan en:
El tamaño de la sección del registro "HKEY_USERS.DEFAULT" aumenta continuamente en un servidor basado en Windows Server 2008 R2 SP1

Revisión: http://support.microsoft.com/kb/2871131

Aparentemente, esto detiene el crecimiento, pero las claves y el registro deben comprimirse para recuperar espacio.

Comprimir registro hinchado: 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, unos pocos pasos ... un poco difíciles de hacer de forma remota durante las horas de producción. Traté de comunicarme con mi experto residente de Microsoft para completar, pero él estaba ocupado persiguiendo algún problema de SCCM o SCVMM en alguna parte . Al leer algunos foros relacionados con Citrix, tomé nota de una herramienta que podría realizar lo anterior con menos pasos ...

Así que tomé una instantánea de máquina virtual, luego descargué y ejecuté el software de compresión de registro gratuito (Tweaking.com) ; a pesar del sonido abrumador de los gemidos colectivos de los ingenieros de sistemas de Microsoft en todas partes ...

tenga en cuenta los 1,4 GB guardados en la configuración predeterminada ...

¡POR FAVOR REINICIE!

Después de un reinicio, todo estuvo bien. El recuento de usuarios alcanzó 86 sin efectos nocivos y sin errores relacionados con el perfil. He monitoreado la sección de registro de la impresora y se ha mantenido estable.

En Windows Server 2003, ese error fue resultado del agotamiento de la memoria del núcleo. Debido a que está tratando con Windows Server 2008 R2, no estoy seguro de cuán estrechamente relacionada está la causa del problema con la causa en W2K3, pero apuesto a que es un problema de memoria debido a la cantidad de usuarios y procesos. Echaría un vistazo al agotamiento de la memoria del bloque no paginado como la causa probable. Además, el número de procesos es de casi 800, que es bastante alto. MS probablemente le dirá que reduzca el número de procesos, lo que solo puede hacerse reduciendo la carga del usuario.

Este artículo tiene buena información sobre el uso de la memoria en Windows y cómo puede ver el límite del Grupo no paginado para ver si esa es la causa del problema:

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

Inicie Windows Performance Monitor para monitorear los distintos contadores:

• Cambios de contexto
• Entradas de tabla de página
• Elementos GDI
• Manejas
• ... (lo que puedas encontrar)

Y vea si uno de estos picos cuando obtiene un inicio de sesión fallido.

Además: algo está causando un alto porcentaje de CPU del kernel en su sistema; debe investigar eso para ver si lo lleva a un problema relacionado.

El servicio de limpieza de colmenas de perfil de usuario puede ayudar aquí ya que "ayuda a garantizar que las sesiones de usuario finalicen por completo cuando un usuario cierra la sesión".

Bueno, de lo que he leído sobre la planificación de la capacidad de RDS en Server 2008 R2, es posible que esté ejecutando su servidor de terminal deficiente con recursos insuficientes para la cantidad de usuarios que lo está utilizando. En particular, noto que tiene 80 usuarios en 4 vCPUS, y MS recomienda 1 núcleo por cada 15 usuarios.

Del blog de technet titulado Guía de planificación de capacidad y dimensionamiento 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:

• La memoria de 2 GB (RAM) es el límite óptimo para cada núcleo de una CPU. Por ejemplo, si tiene 4 GB de RAM, para un rendimiento óptimo debe haber CPU de doble núcleo.
• 2 CPU de doble núcleo funcionan mejor que un procesador de cuatro núcleos.
• Ancho de banda recomendado para LAN de 30 usuarios y WAN de 20 usuarios. Ancho de banda (b) = 100 megabits por segundo (Mbps) con latencia (l) Menos de 5 milisegundos.
• En un Terminal Server, 64 MB por usuario es el requisito de Memoria Ideal (RAM) para GP. Solo use + 2 GB para el SO Por ejemplo (100 usuarios * 64) + 2000 = 8.4 GB, es decir, 8 GB de RAM.
• Más aplicaciones usadas (es decir, Office, aplicaciones CAD, etc.) requerirán que se agregue más memoria por usuario a este cálculo sobre la memoria base de 64 MB por usuario.
• 15 sesiones de TS por núcleo de CPU es el límite de rendimiento óptimo de un Terminal Server.
• La red no debe tener más de 5 saltos y la latencia debe ser inferior a 100 ms.
• 64 kbps es el ancho de banda ideal por sesión de usuario. (256 colores, red conmutada, solo almacenamiento en caché de mapa de bits)
• El rendimiento de la CPU se degrada si el% de tiempo de procesador por núcleo es constantemente superior al 65%.
• El rendimiento de los servidores de Terminal Server se duplica cuando se ejecuta en un X64 HW y OS.

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

Descarguelo aqui

Tengo muy poco tiempo, así que haré una respuesta incompleta y espero desarrollarla más tarde.

Cuando estaba haciendo hechizos en los equipos de Citrix, recuerdo que intentamos subir de nivel a 15-20 usuarios por servidor, pero esos tenían algunas aplicaciones pesadas ejecutándose. En estos días de x64 cargamos más usuarios, pero más de 70 parece mucho.

El rendimiento máximo del contador de rendimiento no era raramente un cambio de contexto, pondría en funcionamiento un servidor mientras que otros contadores como RAM, CPU, etc. se veían bien. Posiblemente eso podría ser una razón (el servidor no puede asignar recursos antes de que se agote el tiempo de espera debido al cambio de contexto excesivo). Aquí hay dos formas de monitorear el cambio 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.

También puede encontrar algo útil en la guía de planificación de capacidad, puede encontrar un enlace en esta publicación de blog .

Cuando pueda sacar el tiempo de esta respuesta, lo haré, solo agregaré aquí arrojando una advertencia sobre todas las mediciones basadas en el tiempo dentro de una máquina virtual vSphere.

Debido a cómo se extrajo la vCPU de las CPU físicas, la vCPU no tiene idea de qué hora es (un segundo virtual puede ser más o menos que un segundo real (o al menos físico). Como consecuencia, todo el tiempo Los contadores de rendimiento (tiempo de CPU, cambios de contexto / seg, etc.) son inexactos (a veces incluso de forma salvaje), incluso si pueden servir como indicadores de grano muy grueso.

Para verificar esto, compare cualquier contador de CPU basado en tiempo nativo dentro de la VM con su contraparte en el host vSphere para esa VM. Por esta razón, VMware publica algunos contadores para la CPU (y la memoria, que también es inexacta desde la perspectiva del invitado) a través de las herramientas de VMware en dos objetos de perfusión de VMguest.

Por lo tanto, los valores correctos basados ​​en el tiempo se ponen a disposición desde el perfil del invitado, pero solo si se miran los contadores de objetos publicados de VMware.

Simplemente pensé que esta información básica era un poco relevante ya que las respuestas hasta ahora se centran en mediciones basadas en el tiempo desde una máquina virtual vSphere, donde esto es en algunos casos una circunstancia crucial para un análisis correcto. Por supuesto, también se relaciona directamente con el tema de esta respuesta particular (inacabada) y sus comentarios. Puede ser de utilidad para alguien.

Tan pronto como tenga tiempo, editaré los enlaces a los libros blancos, etc., que detallan esto, y las rutas / nombres exactos del contador. Naturalmente, todo es googleable también.

Sugeriría implementar WSRM (Administrador de recursos del sistema de Windows). Cuando hay un montón de aplicaciones, conexiones y servicios que se ejecutan en un host, el sistema no sabe que todos deben jugar bien juntos. Windows Server, naturalmente, intenta utilizar todos sus recursos para completar todo todo el tiempo a menos que se dé cuenta ... ingrese WSRM.

Al implementar WSRM, puede establecer límites de recursos por todo tipo de variaciones para asegurarse de que haya un campo de juego uniforme para todo lo que se está ejecutando o los usuarios conectados. Según sus notas, esto no parece ser un problema de ESX / vSphere, sino demasiados usuarios conectados que compiten constantemente por todo. Tendrá que probar WSRM para encontrar un medio feliz de equilibrar los recursos entre todo, pero también no afectar los niveles de rendimiento a los que todos se han acostumbrado.

Descripción general de WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx