Visual Studio 2017 - Processus serveur Node.JS - Désactiver?


132

Je travaille sur une application ASP.NET dans Visual Studio 2017 et je remarque un Node.JS: processus Javascript côté serveur s'exécutant entre 1,3 Go et 1,8 Go de mémoire. Mon processus de travail IIS a la taille normale dans VS 2015.

Mon application n'inclut aucune bibliothèque Node.JS. Je ne suis pas en mesure de comprendre comment désactiver ce processus Node.JS: Javascript côté serveur. Cela consomme trop de mémoire pour quelque chose dont je n'ai pas besoin.

Existe-t-il un moyen de tuer cela en dehors de la désinstallation de VS 2017 et du retour à VS 2015?

entrez la description de l'image ici

Tuer le processus principal dans le Gestionnaire des tâches n'affecte rien dans VS, mais si je vais dans l'onglet Détails et que je tue les processus individuels en cours d'exécution, cela plante Visual Studio. J'ai pris une vidéo de ce qui s'est passé après avoir tué le processus et exécuté ma page Web locale (désolé pour la qualité, taille d'image tellement limitée à 2 Mo):

entrez la description de l'image ici


1
Utilisez-vous TypeScript?
SLaks

Nous en utilisons une petite quantité.
Ryan Ternier

J'ai mis fin à ce processus et je n'ai constaté aucun effet néfaste. Le compilateur Web compile MOINS de fichiers sans lui.
Glen Little

@GlenLittle Cela fonctionne, mais comme le chat ... il est revenu. Je me demande si c'est quelque chose installé au début et est toujours en cours d'exécution. Je viens d'installer VS2017 sur mon lappy et cela m'a donné la possibilité d'installer le serveur. Je mettrai à jour ceci quand je testerai dessus
Ryan Ternier

Pouvez-vous déposer un commentaire à ce sujet? Il y a quelques fonctionnalités différentes dans les outils de développement Web qui utilisent Node sous le capot (comme JSLint / CSSLint / etc) qui pourraient être impliquées ici. Celles-ci apparaîtront pour n'importe quel projet Web, pas seulement TypeScript ou Node.
Jimmy

Réponses:


183

Outils> Options> Editeur de texte> JavaScript / TypeScript> Service de langage ...

Décochez "Activer le nouveau service de langage JavaScript".

Cela semble empêcher le processus NodeJS de démarrer.


19
Cette solution a aidé, devrait être votée pour. Mais vous devez redémarrer Visual Studio pour que cela prenne effet.
madd

14
Je l'ai fait, j'ai redémarré VS2017 et cela n'a toujours pas empêché "Node.js: JavaScript côté serveur" de démarrer lorsque j'ai démarré VS2017. Il monopolise environ 800 Mo sur ma machine et je ne peux plus déboguer dans Chrome.
Bill

1
Même problème ici @Bill - la désactivation de l'extension TypeScript selon la réponse de Gabriel semble l'avoir résolue.
Dunc

1
Que se passe-t-il? Pourquoi cela se passe-t-il dans les paramètres de l'éditeur de texte? : P
Sнаđошƒаӽ

3
Ce n'est même pas une option pour moi dans mes menus
BradLaney

29

J'ai soulevé des commentaires sur ce problème:

https://developercommunity.visualstudio.com/content/problem/31406/visual-studio-2017-nodejs-server-process-turn-off.html

J'ai reçu une réponse d'une équipe MS - il m'a dirigé vers ce post:

https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html?childToView=27629#comment-27629

Le processus node.exe a la ligne de commande: entrez la description de l'image ici

En effet, on m'a dit:

Dans VS 2017, plusieurs fonctionnalités sont implémentées dans JavaScript. Node.js est utilisé par Visual Studio pour exécuter ce JavaScript. Entre autres choses, Node est utilisé pour exécuter le code qui fournit des services de mise en forme et d'intellisense lorsqu'un utilisateur édite TypeScript ou JavaScript. C'est un changement par rapport à VS 2015.

Cela répond à ma question, mais en amène une autre - pourquoi avez-vous besoin de 1,4 Go de mémoire pour me donner de l'intellisense sur les fichiers JavaScript ... ou est-ce l'une des solutions qui a été intégrée à VS afin qu'elle utilise moins de mémoire, donc il ne le fait pas N'atteignez pas la limite de 2 Go (4 Go) des processus 32 bits? Questions questions questions.


En effet, il est important de rendre le processus VS principal plus réactif et d'optimiser les performances en lazifiant certaines choses comme Intellisense dans un autre processus, et avec plus de RAM pour chaque processus 32 bits. Mais cela n'a pas d'importance pour nous dans ce cas. Ce que j'ai trouvé, c'est que Node consomme plus de mémoire si vous avez plus de fichiers de code source ouverts et Intellisense activé. Si vous manquez vraiment de mémoire, essayez de désactiver Intellisense et d'autres fonctionnalités dont vous pourriez vous passer.
user1306322

2
Cela a eu l'effet inverse pour moi et a rendu VS2017 si paresseux (jeu de mots) que je reviens à VS2015. Je trouve ridicule que MS doive utiliser des frameworks externes tiers pour faire quelque chose d'aussi simple qu'Intellisense. Cela a toujours été l'une de leurs forces ... et maintenant? J'ai désactivé TypeScript et Node.js et si je regarde juste Chrome VS2017 se bloque si mal, je dois parfois redémarrer. Revenons donc à Firefox et VS2015 pour moi, du moins pour le moment. Et c'est sur un i7, 16GM de RAM et toutes les configurations SSD avec Win10 Pro. Choquant.
Neville

d'après le post référencé ici ... Désactiver l'extension TypeScript est une solution pour le moment, du moins pour moi. Cliquez sur Outils, extensions et mises à jour, recherchez «TypeScript» et désactivez-le. Redémarrez Visual Studio.
pat capozzi

Eh bien, cela explique pourquoi Intellisense est allé en enfer.
Andy

19

Vous devez désactiver la prise en charge de TypeScript sur Visual Studio:

Outils> Extensions et mises à jour> TypeScript pour Microsoft Visual Studio> Désactiver

Après cela, redémarrez simplement Visual Studio et vous êtes prêt à partir.


1
toujours en cours d'exécution après avoir suivi ces étapes
Jervie Vitriolo

1
Cours toujours. Cela n'a rien fait.
BradLaney

16

La réponse de Ryan Ternier m'a orienté dans ce que je crois être la bonne direction. Suite à son lien ( https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html?childToView=27629#comment-27629 ) m'a conduit à la réponse de Bowden Kelly , juste en dessous de la réponse acceptée.

Voici la réponse de Bowden Kelly:

Le processus de nœud que vous voyez alimente le service de langage JavaScript. Vous verrez ce processus apparaître à chaque fois que vous modifiez un fichier JS, un fichier TS ou tout autre fichier contenant JS / TS (html, cshtml, etc.). Ce processus est ce qui alimente IntelliSense, la navigation dans le code, la mise en forme et d'autres fonctionnalités d'édition et il le fait en analysant l'ensemble du contexte de votre projet. Si vous avez beaucoup de fichiers .js dans votre projet, cela peut devenir volumineux, mais le problème est plus que probable que vous avez beaucoup de fichiers de bibliothèque en cours d'analyse. Par défaut, nous analyserons tous les fichiers .js / .ts de votre projet. Mais vous pouvez remplacer ce comportement et régler le service de langage pour qu'il se concentre uniquement sur votre code. Pour ce faire, créez un tsconfig.json dans la racine de votre projet avec les paramètres suivants:

    {
    "compilerOptions": {
        "allowJs": true,
        "noEmit": true
    },
    "exclude": [
        "wwwroot/lib" //ignore everything in the lib folder (bootstrap, jquery, etc)
        // add any other folders with library code here
    ],
    "typeAcquisition": { 
        "enable": true,
        "include": [
            "bootstrap",
            "jquery"  //list libraries you are using here
        ]
    }
}

Une fois que j'ai ajouté le dossier avec toutes mes bibliothèques de scripts dans le fichier tsconfig.json, la vie était à nouveau belle.


Après que ma boîte à savon siffle dans la réponse précédente, cela semble avoir sauvé la journée !!! Une chose si simple mais si obscure et qui ne m'a pris que trois jours de bataille avec VS2017 pour enfin trouver cela!
Neville

L'ajout de ce fichier a conduit à toutes sortes d'erreurs TypeScript lorsque j'ai construit le projet. Supprimé et les erreurs ont disparu.
John81

4

La solution de contournement la plus sale qui soit: renommez simplement le ServiceHub.Host.Node.x86.exeen quelque chose d'autre. Cela ne m'a pas dérangé depuis. Quand (si) vous en avez réellement besoin, renommez-le simplement.

La même astuce fonctionne dans Adobe Photoshop qui exécute également Node pour une raison que je n'ai pas encore découverte dans mon flux de travail habituel.


Il s'avère que...

Vous ne pouvez pas simplement le renommer et vous attendre à ce que les choses continuent de fonctionner. Qui savait!

Apparemment, cette astuce de changement de nom ne fonctionne que si vous suspendez le processus VS et tuez Node, puis reprenez VS. Si vous essayez de lancer VS avec le fichier exe Node renommé, il plantera lors de l'ouverture d'un projet avec une "erreur matérielle inconnue". De plus, tout en travaillant sur un projet déjà chargé, le compteur de référence paresseux ci-dessus ne fonctionnera pas car apparemment, cela dépend de la présence de Node.

Donc, il peut être correct de simplement suspendre le processus Node et de laisser la pagination Windows échanger sa mémoire de la RAM vers le disque dur, sans renommer l'exe afin que vous puissiez redémarrer le VS plus tard sans avoir à vous soucier du changement de nom. Si vous êtes prêt à vivre avec les conséquences, c'est.


Malheureusement, je pense qu'il existe un code qui détectera si le processus de nœud ne répond pas et en lancera un nouveau à la place. Je ne connais pas cette partie du code VS, mais c'est ainsi qu'elle m'a été décrite.
Jimmy

J'aime toujours l'idée de priver par la force , vous voyez ce que je veux dire ... ;-)
Sнаđошƒаӽ

3

Quelque chose qui peut aider les projets à atténuer le poids de nodejs: est de réaffecter la version de nœud utilisée sous Outils> Options> Projets et solutions> Gestion des packages Web à une version 64 bits installée. Studio lancera toujours son Node interne pour une instance tsserver.js, mais tout dactylographié dans le projet utilisera par défaut la version fournie - et cela m'a aidé de première main.

De plus, une autre fois, j'ai trouvé que le service de langue était en panne, j'ai découvert en utilisant un simple tsconfig.jsonau-dessus des répertoires utilisés comme référentiels, et en spécifiant skipLibCheck: trueet en ajoutant node_modules à exclure - énormément aidé le long du service, et un fichier fait tous les dossiers sous indépendamment des références directes au projet. PS - si vous voulez toujours la prise en charge de JavaScript intellisense, assurez-vous de définir l' option allowJs: trueet noEmit: true.

Enfin, vérifiez dans les Options Typescript sous Outils> Options> Editeur de texte> Javascript / Typescript> Projet qu'il n'est pas coché pour compiler automatiquement les fichiers Typescript qui ne font pas partie d'un projet car cela peut également attacher des ressources pour des projets tiers auxiliaires en utilisant un nœud ou un texte dactylographié.

Ce ne sont pas infaillibles, chacun doit trouver son goulot d'étranglement exact, mais j'ai constaté que cela a fonctionné pour moi et mon équipe le plus souvent


Cela a fonctionné pour moi. Ajout de 'C: \ Program Files \ nodejs' (où j'ai précédemment installé manuellement NodeJS), en haut de cette liste, et le processus Node.js est passé de 50-60% de charge CPU à 0%.
andynil

1

Il suffit de noter que la consommation de mémoire élevée a été corrigée dans la version du 10 mai 2017 - Visual Studio 2017 version 15.2 (26430.04).

Notes de version ici: https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes

Notes spécifiques sur le correctif ici: https://developercommunity.visualstudio.com/content/problem/27033/nodejs-server-side-javascript-process-consuming-to.html


2
Exécution de 15.2 (26430.16) ici et je dirais qu'ils ont peut-être résolu un problème ridiculement - de consommation de mémoire élevée, mais seulement réussi à le rétrograder en une consommation de mémoire élevée :)
PJUK

1
D'accord. Le problème est principalement dû au fait que node.js est mal écrit en premier lieu (en ce sens que les fonctions "objet" sont répliquées maintes et maintes fois) - puis encore une fois, les frameworks pour corriger les lacunes de JS ralentiront toujours les choses. C'est ce qui se passe lorsque des utilisateurs de Linux développent pour Windows - un gros désordre compliqué.
MC9000

J'ai signalé ce problème sur github.com/aspnet/JavaScriptServices/issues/1298 J'ai observé ce problème avec VS 2015 en 2015 avec les projets JavaScript, mais le problème s'aggrave.
monde merveilleux

toujours 2 Go en 2017
Geomorillo

Pas fixe pour moi. Toujours en train de consommer des tonnes de mémoire avec la version 15.6.6
John81

0

Pour désactiver les services de langage dans VS Code, accédez aux extensions, puis filtrez sur les extensions intégrées et désactivez le service de langage TypeScript / Javascript.

J'ai finalement découvert cela après que le service de nœud de VS code a planté mon serveur environ un million de fois. Ennuyeux que ce soit si difficile de trouver de la documentation.

désactiver l'extension de service de langue ts / js intégrée


0

Dans mon cas, j'ai fait que bot voulait tuer le processus node.js et j'ai fait les choses suivantes pour réduire la consommation de processeur des processus Node.Js qui s'exécutent sous Visual Studio 2019:

  • J'ai supprimé le dossier "Program Files (x86) / MicrosoftSDK / TypeScript
  • je cours npm rebuild fsevents
  • J'ai désactivé dans le navigateur Chrome: Paramètres-Système-Continuer à exécuter les applications d'arrière-plan ...

Cela me semble beaucoup mieux maintenant. Mais pas à 100% malheureux.

J'espère que cela aide quelqu'un là-bas aussi. Bonne chance les gars! :-)

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.