Utilisation de la mémoire Windows 2012 Core Extreme sur le service SVCHOST / Workstation

Nous avons environ 200 serveurs, Hyper V, File Cluster et IIS, qui rencontrent tous le même problème, un événement se produit sur le serveur lors d'une utilisation normale qui maximise ou presque la RAM du serveur. Une fois que cela se produit, le service SVCHOST / Workstation, spécifiquement (éliminé en isolant le service Workstation sur son propre SVCHOST) arrête de libérer les descripteurs / threads et la mémoire utilisée par ce service n'est jamais libérée. Nous avons, dans certains cas extrêmes, des services Workstation qui utilisent jusqu'à 40 Go de RAM sur un serveur de 255 Go. Trouver également plus de 40 millions de poignées dans certains cas.

Au redémarrage, le problème disparaît bien sûr et n'apparaît plus jusqu'à ce que toute la mémoire ait été utilisée, par exemple par le processus W3 ou les machines virtuelles HyperV, après cela, le service Workstation commence à récupérer toute la RAM. Le processus est très lent et peut prendre des semaines / mois selon la quantité de RAM sur un serveur.

Nos serveurs Hyper V et nos serveurs IIS accèdent aux partages pour les fichiers de travail, ces partages sont sur le stockage SSD, ils sont donc très performants. Nous avons installé tous les correctifs actuels mais ne sommes pas passés à R2 car nous avons beaucoup d'outils en place qui en feront une étape importante et ne pouvons trouver aucune indication claire que cela serait corrigé dans R2.

Nous avons exécuté ProcMon et d'autres outils, mais sur les serveurs les plus problématiques, ces outils ne fonctionneront même pas. Pour les autres, les résultats qu'ils fournissent montrent simplement qu'il semble effectivement y avoir une fuite de mémoire dans ce processus.

Existe-t-il un moyen de libérer de la mémoire de ce processus ou d'éviter le bogue tous ensemble? Nous ne voulons pas avoir à redémarrer et nous ne pouvons pas redémarrer le processus une fois qu'il est dans un état d'erreur. Le processus est gelé.

Nous essayons d'éviter de redémarrer régulièrement pour «résoudre» ce problème, donc toutes les réponses seraient appréciées.

J'ai eu un problème étrangement similaire où le svchost détruisait les performances du serveur.

La solution: il s'avère que j'avais un journal des événements complet. Je l'ai nettoyé et tout était de nouveau opérationnel, comme si de rien n'était.

(Je recommande également de changer la taille du journal des événements par défaut, voir ci-dessous)

Pour définir la taille maximale du journal à l'aide de l'interface Windows
- Démarrez l'Observateur d'événements.
- Dans l'arborescence de la console, recherchez et sélectionnez le journal des événements que vous souhaitez gérer.
- Dans le menu Action, cliquez sur Propriétés.
- Dans Taille maximale du journal (Ko), utilisez le contrôle spinner pour définir la valeur souhaitée et cliquez sur OK.

Cela ressemble exactement à ce qui se passe ici, mais a fini par être une solution vraiment facile. Un redémarrage résoudrait temporairement le problème, mais dès que quelque chose tentait d'écrire dans le journal, tout devenait incontrôlable et continuait à consommer des ressources.

J'espère que cela t'aides!

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

Il n'y a aucun moyen de libérer (correctement) en externe la mémoire allouée ou de gérer les ressources sans tuer l'application incriminée.

>or avoid the bug all together? 

Vous rencontrez une fuite de mémoire et de ressources. La seule façon de résoudre le problème est de trouver la fuite et d'éviter son déclenchement (si possible) ou de corriger la fuite au niveau du code source; Dans le dernier cas, vous avez besoin de l'aide de Microsoft pour produire le correctif, mais il semble qu'ils s'attendent à ce que vous leur disiez "exactement" où se situe réellement le problème.

Vous pouvez essayer de trouver le coupable en identifiant la fuite de mémoire / ressource en utilisant par exemple MS Application Verifier

Crearing RAM est facile mais pas de solution.

Je suggère Sysinternals RAMMAP ou VMMAP pour une enquête plus approfondie. Avec ces outils, vous pouvez mieux voir ce qui se passe. très souvent, c'est un problème de métafichier.

Depuis Server 2008, nous avons ce problème avec tous les serveurs Terminal Server à court de mémoire avec une consommation de mémoire incroyable au fil du temps lors du démarrage des applications à partir du partage.

Notre solution consiste à héberger ces applications sur un serveur Terminal Server distinct et à effacer fréquemment la consommation de mémoire.

Nous le faisons avec une application de ligne de commande c ++ conçue en utilisant
SetProcessWorkingSetSize () avec SeDebugPrivilege sur tous les processus

Il est fortement recommandé de ne pas faire quelque chose comme ça;)