Utilizzo della memoria Core Extreme di Windows 2012 sul servizio SVCHOST / Workstation


9

Abbiamo circa 200 server, Hyper V, File Cluster e IIS, che presentano tutti lo stesso problema, un evento si verifica sul server durante l'uso normale che raggiunge il limite massimo o quasi massimo della RAM sul server. Una volta che ciò accade, il servizio SVCHOST / Workstation, in particolare (eliminato dal servizio SVGOST isolandolo dal proprio SVCHOST) smette di rilasciare handle / thread e la memoria utilizzata da quel servizio non viene mai rilasciata. Abbiamo, in alcuni casi estremi, servizi Workstation che utilizzano fino a 40 GB di RAM su un server da 255 GB. Anche trovare in alcuni casi oltre 40 milioni di handle.

Al riavvio, il problema ovviamente scompare e non viene più visualizzato fino a quando tutta la memoria non è stata utilizzata, ad esempio dal processo W3 o dalle VM HyperV, dopodiché il servizio Workstation inizia a catturare tutta la RAM. Il processo è molto lento e può richiedere settimane / mesi a seconda della quantità di RAM su un server.

Sia i nostri server Hyper V che i server IIS accedono alle condivisioni per i file di lavoro, queste condivisioni sono archiviate su SSD, quindi sono molto performanti. Abbiamo installato tutte le patch attuali ma non ci siamo spostati su R2 in quanto disponiamo di numerosi strumenti che renderanno questo un passaggio significativo e non sono in grado di trovare alcuna chiara indicazione che ciò verrà risolto in R2.

Abbiamo eseguito ProcMon e altri strumenti, ma sui server più problematici tali strumenti non funzioneranno nemmeno. Per gli altri, i risultati che forniscono mostrano solo che sembra esserci effettivamente una perdita di memoria in quel processo.

C'è un modo in cui possiamo liberare la memoria da questo processo o evitare il bug tutti insieme? Non vogliamo riavviare e non è possibile riavviare il processo una volta che si trova in uno stato di errore. Il processo si blocca.

Stiamo cercando di evitare di riavviare regolarmente per "risolvere" questo problema, quindi qualsiasi risposta sarebbe apprezzata.


Qual è la tua domanda?
Andrew Schulman,

In effetti lo facciamo, ma nella migliore delle ipotesi è ambiguo, si aprono solo migliaia / milioni di thread. Sui sistemi più problematici non possiamo nemmeno eseguire quegli strumenti, si limitano a bloccare il server.
Craig,

Vogliamo trovare una buona soluzione per risolvere il problema oltre a riavviare il box. Non siamo in grado di interrompere i servizi una volta iniziato questo problema.
Craig,

KB 2811660 è stato installato? Questi sistemi eseguono Server Manager? support.microsoft.com/kb/2793908

Sì, questo KB è stato installato qualche tempo fa. Inoltre, questa perdita è specifica per il servizio Workstation, che KB applica al servizio WMI.
Craig,

Risposte:


1

Ho avuto un problema stranamente simile in cui svchost stava distruggendo le prestazioni del server.

La soluzione: risulta che avevo un registro eventi completo. L'ho cancellato e tutto è tornato in esecuzione come se niente fosse.

(Consiglio anche di cambiare la dimensione del registro eventi da quella predefinita, vedi sotto)

Per impostare la dimensione massima del registro utilizzando l'interfaccia di Windows
- Avvia Visualizzatore eventi.
- Nell'albero della console, navigare e selezionare il registro eventi che si desidera gestire.
- Nel menu Azione, fai clic su Proprietà.
- In Dimensione massima registro (KB), utilizzare il controllo Spinner per impostare il valore desiderato e fare clic su OK.

Sembra esattamente quello che sta succedendo qui, ma alla fine è stata una soluzione davvero semplice. Un riavvio risolverebbe temporaneamente il problema, ma non appena qualcosa provasse a scrivere nel registro, tutto sarebbe sfuggito di mano e avrebbe continuato a consumare risorse.

Spero che sia di aiuto!


-1
>Is there a way we can free up the memory from this process ?

Non è possibile rilasciare esternamente (correttamente) la memoria allocata o gestire le risorse senza uccidere l'app offensiva.

>or avoid the bug all together? 

Si verifica una perdita di memoria e risorse. L'unico modo per risolvere il problema è trovare la perdita ed evitare il suo trigger (se possibile) o correggere la perdita a livello di codice sorgente; Nell'ultimo caso hai bisogno dell'aiuto di Microsoft per produrre la patch, ma sembra che si aspettino che tu dica "esattamente" dove si trova realmente il problema.

Puoi provare a trovare il colpevole individuando la perdita di memoria / risorsa utilizzando ad esempio MS Application Verifier


Il trigger sono le condivisioni di file, che non possiamo evitare.
Craig,

se non riesci a evitare il trigger, trova la perdita con "Application Verifier" e contatta MS con quelle informazioni.
Pat

Le applicazioni, poiché sono molteplici, sono tutte Microsoft. Li abbiamo già contattati, stiamo cercando una soluzione più rapida in quanto affermano che potrebbero essere necessarie settimane / mesi per risolvere il problema.
Craig,

Considerando che la SM non si affretterà davvero a risolvere questo genere di cose su un sistema operativo non attuale, non credo che troverai una soluzione più rapida. Una cosa diversa è se dici loro dove si trova la perdita.
Pat

Abbiamo un caso aperto e abbiamo lavorato con loro per un mese. La perdita è letteralmente nel servizio Workstation.
Craig,

-1

La creazione di RAM è semplice ma nessuna soluzione.

Suggerisco Sysinternals RAMMAP o VMMAP per approfondimenti. Con questi strumenti puoi vedere meglio cosa succede. molto spesso è un problema metafile.

Da Server 2008 abbiamo questo problema con tutti i terminal server che esauriscono la memoria con un consumo di memoria incredibile nel tempo all'avvio delle applicazioni dalla condivisione.

La nostra soluzione è l'hosting di tali applicazioni su un Terminal Server separato e l'eliminazione frequente del consumo di memoria.

Lo facciamo con un'applicazione da riga di comando c ++ progettata da sé utilizzando
SetProcessWorkingSetSize () con SeDebugPrivilege su tutti i processi

Si consiglia vivamente di non fare qualcosa del genere;)


Perché votare? È esattamente quello che è stato chiesto! Non è un piacere provare ad aiutare qui ...
Magnus,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.