Qu'est-ce que le processus Visual Studio Standard Collector et pourquoi utilise-t-il 10 Go de RAM?


21

J'espère que c'est le bon site d'échange de pile sur lequel poster ... Je n'ai pas eu l'impression que c'était une question de programmation pour SO. Quoi qu'il en soit, j'exécute Visual Studio 2015 et j'ai reçu une notification de Windows pour fermer VS2015 car il manque de mémoire. J'ai 24 Go de RAM et j'ai juste redémarré hier, donc je pense que quelque chose est loin d'ici. J'utilise parfois la fenêtre interactive C # et la fenêtre interactive python 2.7, mais celles-ci n'étaient pas utilisées au moment de ce message.

Remarque: Au moment où j'écris ceci, je viens de recevoir un message «Incident dur inconnu» de devenv.exe (processus vs2015). Mais le service Standard Collector fonctionne toujours en utilisant jusqu'à 10,7 Go.

Quelqu'un sait-il ce qu'est le collecteur standard? Et qu'est-ce qui pourrait provoquer une augmentation de l'utilisation de la RAM?

Remarque: Encore une fois pendant que j'écris, je viens de remarquer que le service Standard Collector s'est arrêté dans mon gestionnaire de tâches et que j'ai toute ma RAM.

Utilisation importante de la RAM par un processus "Standard Collector" de Visual Studio

Mise à jour: Il semble que cela puisse être un bug que l'équipe VS a essayé de corriger dans la mise à jour 1. J'ai définitivement installé la mise à jour 1, mais je devrais peut-être essayer de reproduire dans un exemple de code et de l'envoyer à l'équipe VS. L'instance devenv qui s'est bloquée n'était pas non plus en cours de débogage. (Bien qu'il existe une autre instance de débogage comme vous pouvez le voir par l'extension .vshost.exe dans le gestionnaire de tâches)

Cette instance de devenv ne s'est pas bloquée et fonctionne actuellement sans problème dans le débogueur.

entrez la description de l'image ici


Il traite des outils de diagnostic. . Vous savez que Chrome existe en tant que processus 64 bits, n'est-ce pas?
Ramhound

1
il s'agit d'un bogue connu et il a un correctif avec une vérification de mise à jour ici pour plus d'informations: connect.microsoft.com/VisualStudio/feedback/details/1630071/…
arana

@arana, je lance la mise à jour 1, qui "devrait" avoir le correctif ...
C. Tewalt

1
@Ramhound Chrome n'est pas vraiment pertinent pour cette question. Ou partagez-vous simplement avec bonté une information utile?
C.Tewalt

Réponses:


16

Le processus collecteur semble être lié à l'instrumentation / diagnostics du code exécuté en mode débogage, dans Visual Studio 2015. Microsoft a reconnu qu'il existe un problème avec l'utilisation de la mémoire illimitée de ce processus, et déclare: «Nous avons recherché la cause racine et avons fait un correctif qui sera fourni dans VS2015 Update 1 "

Assurez-vous donc d'obtenir la dernière mise à jour de Visual Studio 2015. Pour l'atténuation en attendant:

"Pendant ce temps, si vous remarquez que le processus consomme trop de mémoire, vous avez deux façons de récupérer. Le plus simple est simplement de redémarrer votre machine. Cela ramènera tout à un état neuf. L'autre chose que vous pouvez faire pour réduire la consommation de mémoire est pour arrêter le service Visual Studio Standard Collector à l'aide de l'interface utilisateur de Service Manager. Le nom du service est «VSStandardCollectorService140». Il peut être arrêté en toute sécurité lorsque vous ne déboguez pas avec Visual Studio. Si vous arrêtez le service pendant le débogage (même arrêté à un point d'arrêt) ), la fenêtre Outils de diagnostic affiche un message d'erreur après la reprise du processus cible de débogage. "

Regardez ce lien, d'où proviennent les citations ci-dessus: https://connect.microsoft.com/VisualStudio/feedback/details/1630071/visual-studio-standard-collector-unbounded-memory-usage

Ce lien contient également un exemple de code d'une personne qui a vécu cela à partir d'une application console. Il peut être utile d'exécuter cet exemple de code pour voir s'il déclenche le problème sur votre système. La personne qui a signalé le problème a également indiqué qu'il s'était produit par intermittence, mais l'exécution du code en mode de débogage Visual Studio semblait être le seul fil conducteur.

Peut-être que Microsoft a corrigé certaines causes profondes du problème, mais il existe encore d'autres causes non corrigées.


1
Un moyen simple (Windows 7 / Windows 10) pour afficher l'interface graphique des services consiste à démarrer / exécuter et à taper "services.msc" et à appuyer sur Entrée. Dans la liste des services sur ma machine Windows 7, le nom que je crois être celui mentionné apparaît comme "Visual Studio Standard Collector Service".
Developer63 - GoFund Monica

Intéressant, bien que la mise à jour 1 soit installée -> c'est pourquoi j'utilise la fenêtre interactive c # (uniquement disponible dans la mise à jour 1). Il est intéressant de noter que l'exemple de code de votre lien que le gars a reproduit utilise des tâches. Mon application fait également un usage équitable des tâches et du code asynchrone.
C.Tewalt

@matrixugly, si je comprends bien le problème, le service collecteur fonctionne essentiellement tout le temps lorsque VS2015 est en cours d'exécution, collectant les informations d'instrumentation / diagnostic de l'application. Donc, ce que vous faisiez au moment où Windows a émis l'alerte de mémoire faible peut ou non avoir une relation avec le problème. Cela aurait pu être quelque chose de beaucoup plus tôt, où le processus du service des collecteurs n'a pas reconnu qu'il devait commencer à effacer les anciennes données d'instrumentation, a progressivement rempli la mémoire et le message est apparu quelques heures plus tard lors d'une activité indépendante.
Developer63 - GoFund Monica

7
Existe toujours dans la mise à jour 3 RC. :(
SayusiAndo

1
Est-ce toujours un problème pour VS2017? Si oui, quelles sont les conséquences de la désactivation de ce service?
roule le

2

Désactivez le service et il ne mangera plus votre mémoire.

Outils-> Options-> Débogage-> Général, désactivez "Activer les outils de diagnostic pendant le débogage".


2
Vous devez également mentionner que vous n'aurez pas d'outils de diagnostic qui font partie de la suite de débogage que beaucoup de gens utilisent.
roule

1
Personnellement, en tant que développeur, j'ai toujours désactivé les outils de diagnostic parce que je sentais que cela rendait ma machine beaucoup plus lente depuis la première fois que je l'ai vue, et ne l'activer que lorsque j'ai un problème de performances que je dois diagnostiquer (ce qui est assez rare), et encore, une session de profilage me donne généralement beaucoup plus d'informations. Je suis assez curieux de savoir à quoi les gens l'utilisent régulièrement.
Eduardo Wada
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.