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


21

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.

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí


¿Es este tu problema? . No puedo decir que haya experimentado esto en un servidor Windows Server 2008 R2 , pero me encontré con él en 2003 y 2008, por lo que tal vez todavía se aplique.
HopelessN00b

@ HopelessN00b El ID de evento 1508 al que se hace referencia a menudo no aparece en este entorno. La mayor parte de mi investigación me ha llevado a soluciones orientadas a entornos Windows 2003, pero a lo mejor mis habilidades de Google están fuera ahora ...
ewwhite

Esto es para 2003, pero es posible que desee ver si parece relevante: support.microsoft.com/kb/935649
ErikE

@ HopelessN00b Lo comprobé RegistrySizeLimit, y no está definido.
ewwhite

1
@ErikE Estas entradas de registro se ignoran en 2008 R2 .
ewwhite

Respuestas:


16

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

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


¿Podría haberse evitado esto deshabilitando la redirección de impresora RDP? A veces, los clientes tendrán controladores de impresión terribles que se copiarán en los servidores que también utilicen. Por supuesto, para un servidor de terminal puede que necesite Redirección de impresora RDP ...

1
@kce Todos los clientes en este entorno eran clientes ligeros, excepto tal vez 2 o 3 PC. También podría haber un problema con el cliente al instalar impresoras locales en el TS en lugar de las impresoras distribuidas por GPO ... pero el error mencionado en la revisión fue un problema independientemente.
Ewwhite

¡Gracias por el diagnóstico, la revisión y la herramienta! Recuerdo vagamente que este problema me sucedió una vez, pero luego ocurrió una corrupción total no relacionada, así que simplemente reinstalé todo. Ciertamente marcaré esto en mi Evernote, si tengo un problema similar en el futuro. ¡Gracias otra véz!
pepoluan

Para los registros, he hecho lo anterior y se resolvió, pero ahora me enfrento a otra hinchazón del registro: ¡ HKU\.DEFAULT\Software\Hewlett-Packardy HKU\.DEFAULT\Software\Lexmarkambos juntos representan aproximadamente 1.2 GB del archivo de registro PREDETERMINADO!
ETL

3

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


2
¿800 procesos es demasiado alto? Pero en Linux ... :(
ewwhite

Antes de quejarse de que 800 procesos son altos en comparación con Linux, agregue la columna "hilos" para procesar el monitor y vea cuántos de ellos ve ... los procesos en Linux y Windows son diferentes. Compararlos es injusto para ambos diseños de kernel.
Mark

2

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


¿Puedo agregar más vCPU?
Ewwhite

Agregar más potencia de procesamiento no solucionará el alto uso del% del kernel, solo lo enmascarará. Además, no es probable que sea directamente la fuente de sus fallas de inicio de sesión.
MikeyB

Lo que estoy tratando de llegar al fondo de ...
ewwhite

La funcionalidad de la utilidad UPHClean se proporciona de forma nativa a través del Servicio de limpieza de perfiles de usuario desde w2k8 en adelante.
ErikE

@ewwhite Aquí hay un artículo de Microsoft que menciona el agotamiento de PTE en los servidores W2k3 TS . Puede valer la pena lanzar algunos contadores de perfmon para comprobar si eso es lo que te está pasando.
HopelessN00b

1

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


1

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.


¿Estás sugiriendo que necesito reducir el cambio de contexto? Las cifras reportadas a través de procmon fueron mucho más bajas que otros ejemplos que vi en línea. ¿Pero eso no puede ser contrarrestado por recursos adicionales de hardware / CPU?
Ewwhite

Le sugiero que observe si puede ser relevante para su problema. Si lo ha medido y la cantidad parece baja según su investigación, obviamente no lo es. El nivel de tolerancia aumenta linealmente para cada procesador agregado al sistema. Sin embargo, no creo que haya un nivel de umbral absoluto, pero en principio debe basarse por sistema (saludable).
ErikE

Esta publicación de blog fue simplemente interesante desde la perspectiva de la virtualización, aunque probablemente no sea relevante: professionalvmware.com/2010/11/context-switching-some-resources Y como se ve en este documento vinculado, la estimación de costos de cambio de contexto multinúcleo virtualizado es complicado : blog.tsunanet.net/2010/11/…
ErikE

0

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


Gracias. Ya tengo instalado WSRM con el perfil Igual por sesión .
ewwhite

No estoy seguro de que WSRM pueda aliviar el problema subyacente, que según mis instintos es el agotamiento de la memoria de algún tipo (y basado en el mismo problema y mensaje de error en W2K3 es algún tipo de agotamiento de la memoria del núcleo).
joeqwerty
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.