Terminal Server 2008 R2: "Risorse di sistema insufficienti per completare il servizio richiesto"

Sto lavorando con un Terminal Server Windows 2008 R2 non integro configurato in un ambiente vSphere. Attualmente ha 4 vCPU e 32 GB di RAM. Nessun impegno eccessivo.

Il conteggio degli utenti simultanei su questo server è aumentato notevolmente negli ultimi mesi (~ 70) ed è probabilmente superiore al livello raccomandato. A causa delle applicazioni utilizzate dagli utenti su questo sistema, suddividerlo in più server sarà una sfida che va oltre lo scopo di questa domanda.

Tuttavia, in determinati punti della settimana (e ora quasi quotidianamente), i nuovi accessi utente generano i seguenti errori: ID evento 1500

Windows non può accedere perché il tuo profilo non può essere caricato. Verifica di essere connesso alla rete e che la tua rete funzioni correttamente.

DETTAGLIO - Risorse di sistema insufficienti per completare il servizio richiesto.

Questo rimane fino a quando alcuni utenti non si disconnettono, le sessioni vengono disconnesse manualmente o il sistema viene riavviato completamente.

Mi piacerebbe sapere

• A quali risorse si riferisce questo messaggio di errore? Cosa è effettivamente vincolato?
• Esiste un parametro sintonizzabile o una configurazione a livello di sistema operativo che può esserti utile?
• Gli utenti sono soddisfatti delle prestazioni, ad eccezione della maggiore frequenza di questo messaggio di errore. C'è qualcos'altro in gioco qui?
• Esiste un limite assoluto al numero di utenti che un server terminal può ospitare? Vedo più di 150 utenti descritti in alcune guide di ottimizzazione per Terminal Server.

Questo è stato risolto.

Ho iniziato a esaminare il registro perché l'aumento delle risorse di CPU e RAM sulla macchina virtuale non ha risolto il problema.

Mi è stato indicato lo strumento dureg di Microsoft per stimare le dimensioni del registro. Navigando tramite regedit, ho riscontrato problemi durante l'apertura delle chiavi in HKEY_USERS\.Default\PRINTERS. Usando dureg, ho iniziato a sondare sotto quella gerarchia.

Le stampanti erano il problema. La causa e la correzione sono dettagliate in:
La dimensione dell'hive del Registro di sistema "HKEY_USERS.DEFAULT" aumenta continuamente su un server basato su Windows Server 2008 R2 SP1

Aggiornamento rapido: http://support.microsoft.com/kb/2871131

Ciò apparentemente blocca la crescita, ma le chiavi e il registro devono essere compressi per recuperare spazio.

Compressione del registro gonfio: 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

Mmm, qualche passo ... un po 'difficile da fare da remoto durante le ore di produzione. Ho provato a contattare il mio esperto Microsoft residente per completare, ma era impegnato a inseguire da qualche parte alcuni problemi di SCCM o SCVMM . Leggendo alcuni forum relativi a Citrix, ho preso atto di uno strumento in grado di eseguire quanto sopra con meno passaggi ...

Così ho fatto un'istantanea della macchina virtuale, quindi ho scaricato ed eseguito il software di compressione del registro freeware (Tweaking.com) ; nonostante il suono travolgente dei gemiti collettivi degli ingegneri di sistemi Microsoft ovunque ...

notare 1,4 GB salvati nella configurazione predefinita ...

PER FAVORE, RIAVVIA!

Dopo un riavvio, tutto è andato bene. Il conteggio degli utenti ha raggiunto 86 senza effetti negativi e senza errori relativi al profilo. Ho monitorato l'hive del registro di stampa ed è rimasto stabile.

In Windows Server 2003 quell'errore era il risultato dell'esaurimento della memoria del kernel. Poiché hai a che fare con Windows Server 2008 R2 non sono sicuro di quanto strettamente correlata sia la causa del problema con la causa in W2K3, ma scommetto che è un problema di memoria dovuto al numero di utenti e processi. Darei un'occhiata all'esaurimento della memoria di Nonpaged Pool come probabile causa. Inoltre, il numero di proccesi è quasi 800, il che è piuttosto elevato. MS probabilmente ti direbbe di ridurre il numero di processi, cosa che può essere fatta solo riducendo il carico dell'utente.

Questo articolo contiene alcune buone informazioni sull'utilizzo della memoria in Windows e su come è possibile visualizzare il limite del pool non di paging per vedere se questa è la causa del problema:

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

Avvia Windows Performance Monitor per monitorare i vari contatori:

• Switch di contesto
• Voci tabella pagine
• Elementi GDI
• maniglie
• ... (qualunque cosa tu possa trovare)

E vedi se uno di questi picchi quando ricevi un login fallito.

Inoltre: qualcosa sta causando un'alta percentuale di CPU del kernel sul tuo sistema - dovresti indagare per vedere se ti porta ad un problema correlato.

Il servizio di pulizia dell'hive del profilo utente può essere d'aiuto in quanto "aiuta a garantire che le sessioni utente siano completamente terminate quando l'utente si disconnette".

Bene, da quello che ho letto sulla pianificazione della capacità RDS in Server 2008 R2, potresti semplicemente eseguire il tuo povero terminal server con risorse insufficienti per il numero di utenti che lo usi. In particolare, noto che hai 80 utenti su 4 vCPUS e MS consiglia 1 core per 15 utenti.

Dal blog technet intitolato Guida alla pianificazione delle dimensioni e della capacità 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 da 2 GB (RAM) è il limite ottimale per ciascun core di una CPU. Ad esempio, se si dispone di 4 GB di RAM, per prestazioni ottimali è necessario disporre di CPU dual core.
• 2 CPU Dual Core offrono prestazioni migliori rispetto al processore quad core singolo.
• Larghezza di banda consigliata per LAN di 30 utenti e WAN di 20 utenti. Larghezza di banda (b) = 100 megabit al secondo (Mbps) con latenza (l) Meno di 5 millisecondi.
• Su un Terminal Server 64 MB per utente è il requisito di memoria ideale (RAM) per GP Utilizzare solo + 2 GB per sistema operativo Ad esempio (100 utenti * 64) + 2000 = 8,4 GB, ovvero 8 GB di RAM.
• Più applicazioni utilizzate (ad es. Office, App CAD ecc.) Richiederanno più memoria per utente da aggiungere a questo calcolo sulla memoria di base da 64 MB per utente.
• 15 sessioni TS per core della CPU sono il limite di prestazioni ottimali di un Terminal Server.
• La rete non dovrebbe avere più di 5 hop e la latenza dovrebbe essere inferiore a 100 ms.
• 64 kbps è la larghezza di banda ideale per sessione utente. (256 colori, rete commutata, solo cache bitmap)
• Le prestazioni della CPU diminuiscono se la percentuale di tempo del processore per core è costantemente superiore al 65%.
• Le prestazioni dei server terminal raddoppiano quando sono in esecuzione su un X64 HW e OS.

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

Scaricalo qui

Ho pochissimo tempo, quindi farò solo una risposta imprecisa e spero che la risponda più tardi.

Quando stavo facendo incantesimi nei team Citrix, ricordo che cercavamo di portare a 15-20 utenti per server, ma quelli avevano alcune app pesanti in esecuzione. In questi giorni di x64 cariciamo più utenti, ma 70+ suona molto.

Il contagiri del perfmon al massimo non era raramente il cambio di contesto, bensì un server mentre altri contatori come RAM, CPU ecc. Sembravano buoni. Forse questo potrebbe essere un motivo (il server non può allocare le risorse prima del timeout a causa di un cambio di contesto eccessivo). Ecco due modi per monitorare il cambio di contesto :

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.

Inoltre potresti trovare qualcosa di utile nella guida alla pianificazione della capacità, puoi trovare un link ad esso in questo post del blog .

Quando potrò dedicare tempo a questa risposta, lo farò, aggiungerò qui lanciando un avvertimento su tutte le misurazioni basate sul tempo all'interno di una macchina virtuale vSphere.

A causa di come la vCPU è stata sottratta dalle CPU fisiche, la vCPU non ha idea di che ora sia (un secondo virtuale può essere più o meno di un secondo reale (o almeno fisico). Di conseguenza, basato su tutti i tempi i contatori perfmon (tempo di CPU, switch di contesto / sec e così via) sono imprecisi (a volte anche così selvaggiamente), anche se possono servire da indicatori molto grossolani.

Per verificarlo, confrontare qualsiasi contatore CPU nativo basato sul tempo all'interno della VM con la sua controparte sull'host vSphere per quella VM. Per questo motivo VMware pubblica alcuni contatori per CPU (e memoria che è anche inaccurata dal punto di vista del guest) tramite strumenti VMware in due oggetti perfmon VMguest.

Pertanto, i valori corretti basati sul tempo vengono resi disponibili all'interno del guest perfmon, ma solo se si osservano i contatori di oggetti pubblicati VMware.

Ho appena pensato che queste informazioni di base fossero un po 'rilevanti poiché le risposte finora si stanno concentrando su misurazioni basate sul tempo all'interno di una macchina virtuale vSphere, dove in alcuni casi questa è una circostanza cruciale per un'analisi corretta. Naturalmente si collega anche direttamente al tema di questa particolare risposta (incompiuta) e ai suoi commenti. Potrebbe essere utile a qualcuno.

Non appena avrò tempo, modificherò nei collegamenti ai white paper ecc. Che elaborano questo, e i contatori esatti percorsi \ nomi. Naturalmente è anche tutto google.

Suggerirei di implementare WSRM (Gestione risorse di sistema di Windows). Quando ci sono un sacco di app, connessioni, servizi in esecuzione su un host, il sistema non sa che tutti devono giocare bene insieme. Windows Server tenta naturalmente di utilizzare tutte le sue risorse per completare tutto tutto il tempo a meno che non venga reso noto ... immettere WSRM.

Con l'implementazione di WSRM è possibile impostare limiti di risorse per ogni tipo di variazione per assicurarsi che vi sia un campo di gioco uniforme per tutto ciò che è in esecuzione o gli utenti connessi. Dalle tue note questo non sembra essere un problema ESX / vSphere ma piuttosto troppi utenti connessi che sono costantemente in competizione per tutto. Dovrai testare WSRM per trovare un mezzo felice di bilanciamento delle risorse tra tutti, ma anche senza influire sui livelli di prestazioni a cui tutti sono abituati.

Panoramica di WSRM: http://technet.microsoft.com/en-us/library/cc732553.aspx