Que dois-je faire si le processeur du service de nœud est trop élevé ? Parlons d'idées de dépannage

nodeQue dois-je faire si le processeur du service est trop élevé ? Comment vérifier ? L'article suivant triera et partagera avec vous les idées de dépannage en cas de processeur trop élevé du service de nœud. J'espère qu'il vous sera utile !

Aidez un collègue à examiner un problème de CPU excessif

• Le CPU ne peut pas descendre après avoir augmenté. Finalement, le collègue a découvert qu'une certaine dépendance avait été mise à niveau vers une version majeure et la version par défaut. La configuration publique de Redis était hors ligne (le projet est plus ancien, personne n'y a touché depuis longtemps) mais vous devez configurer et fermer le service Redis dans le code métier. Le côté commercial a un manque d'informations, donc ils ne savent pas fermer Redis. Par conséquent, après s'être connectés, ils continuent de réessayer de se connecter à Redis (une demande de plus signifie une nouvelle tentative)

Enfin, nous avons résumé le idées de dépannage, comme suit, bienvenue à ajouter

Idées de dépannage

0. Redémarrez l'instance

Certains problèmes peuvent être résolus en redémarrant l'instance.

Redémarrez d’abord l’instance. C’est une étape nécessaire pour rendre le service disponible en premier. Si le processeur suivant augmente toujours trop rapidement, vous devrez peut-être d'abord envisager de restaurer le code. Si la surtension n'est pas rapide, vous pouvez résoudre le problème dès que possible sans revenir en arrière

1 Shell Linux Déterminez si cela est causé par le processus du nœud

Commande 1 : toptop

• 可以发现，主要是node进程在占用CPU。【相关教程推荐：nodejs视频教程】

  [root@*** ~]# top
  
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                     
  680 root      20   0 2290976 168176  34976 S  30.3  2.0 103:42.59 node                                                                                                                        
  687 root      20   0 2290544 166920  34984 R  26.3  2.0  96:26.42 node                                                                                                                        
   52 root      20   0 1057412  23972  15188 S   1.7  0.3  11:25.97 ****                                                                                                           
  185 root      20   0  130216  41432  25436 S   0.3  0.5   1:03.44 ****                                                                                                         
  ...

命令二： vmstat.

Vous pouvez constater que c'est principalement le processus de nœud qui utilise le CPU. [Recommandations de didacticiel associées :
• Tutoriel vidéo Nodejs
]

[root@*** ~]# vmstat 2
procs -----------memory---------------- ---swap-- -----io---- --system-- -----cpu-----
 r  b      swpd  free   buff   cache      si   so    bi    bo   in cs   us sy id wa st
 0  0      0 233481328 758304 20795516    0    0     0     1    0    0  0  0 100  0  0
 0  0      0 233480800 758304 20795520    0    0     0     0  951 1519  0  0 100  0  0
 0  0      0 233481056 758304 20795520    0    0     0     0  867 1460  0  0 100  0  0
 0  0      0 233481408 758304 20795520    0    0     0    20  910 1520  0  0 100  0  0
 0  0      0 233481680 758304 20795520    0    0     0     0  911 1491  0  0 100  0  0
 0  0      0 233481920 758304 20795520    0    0     0     0  889 1530  0  0 100  0  0

• Commande 2 : vmstat

  Premier coup d'œil à une commande vmstat 2, ce qui signifie collecter toutes les deux secondes

  rrreee

• procs
  r #Représente la file d'attente en cours d'exécution (c'est-à-dire le nombre de processus réellement alloués au processeur). Lorsque cette valeur dépasse le nombre de processeurs, un goulot d'étranglement du processeur se produit. Ceci est également lié à la charge de top. Généralement, si la charge dépasse 3, elle est relativement élevée. Si la charge dépasse 5, elle est élevée. Si elle dépasse 10, c'est anormal. . La charge de top est similaire à la file d'attente d'exécution par seconde. Si la file d'attente d'exécution est trop volumineuse, cela signifie que votre processeur est très occupé, ce qui entraîne généralement une utilisation élevée du processeur.
  b #Représente un processus bloqué, un processus en attente de ressources Je n'en dirai pas grand-chose, mais tout le monde sait que le processus est bloqué.
  memory
  swpd #La taille de la mémoire virtuelle utilisée. Si elle est supérieure à 0, cela signifie que la mémoire physique de votre machine est insuffisante. Si ce n'est pas la cause d'une fuite de mémoire du programme, alors vous devez mettre à niveau la mémoire. ou migrez les tâches gourmandes en mémoire vers d’autres machines.
• free # La taille de la mémoire physique libre
  buff #Le système Linux/Unix est utilisé pour stocker, mettre en cache le contenu du répertoire, les autorisations, etc.
  cache #cache est directement utilisé pour mémoriser les fichiers que nous ouvrons et faisons le traitement des fichiers Buffering utilise une partie de la mémoire physique libre pour mettre en cache les fichiers et les répertoires afin d'améliorer les performances d'exécution du programme. Lorsque le programme utilise de la mémoire, le tampon/mis en cache sera utilisé rapidement.

• swap
  si #La taille de la mémoire virtuelle lue sur le disque par seconde Si cette valeur est supérieure à 0, cela signifie que la mémoire physique n'est pas suffisante ou que la mémoire est perdue. processus et le résoudre. Ma machine a beaucoup de mémoire et tout fonctionne bien.
  donc #La taille de la mémoire virtuelle écrite sur le disque par seconde, si cette valeur est supérieure à 0, comme ci-dessus.

• io
  bi #Le nombre de blocs reçus par le périphérique de bloc par seconde. Le périphérique de bloc fait ici référence à tous les disques et autres périphériques de bloc du système. La taille de bloc par défaut est de 1024 octets
  bo #Le nombre de. blocs envoyés par le périphérique de bloc par seconde Quantité, par exemple, lorsque nous lisons un fichier, bo doit être supérieur à 0. Bi et bo sont généralement proches de 0, sinon les IO sont trop fréquentes et doivent être ajustées.

• system
  in #Le nombre d'interruptions du processeur par seconde, y compris les interruptions de temps
  cs #Le nombre de changements de contexte par seconde Par exemple, lorsque nous appelons une fonction système, nous devons effectuer un changement de contexte, un thread. commutation et changement de contexte de processus. , cette valeur doit être aussi petite que possible Si elle est trop grande, vous devriez envisager de réduire le nombre de threads ou de processus
  cpu
  us #Temps CPU utilisateur, j'étais sur un. serveur qui effectuait le cryptage et le déchiffrement très fréquemment, vous pouvez voir qu'au moment où nous sommes proches de 100, la file d'attente en cours d'exécution a atteint 80 (la machine effectue des tests de résistance et ses performances sont médiocres).
• sy #Temps CPU système, s'il est trop élevé, cela signifie que le temps d'appel système est long, comme des opérations d'E/S fréquentes.
  id #Temps CPU inactif, d'une manière générale, id + us + sy = 100, en général, je pense que id est l'utilisation du processeur inactif, us est l'utilisation du processeur de l'utilisateur et sy est l'utilisation du processeur du système. 🎜🎜wt #En attente du temps CPU IO. 🎜🎜🎜🎜Pratique🎜

  procs r : De nombreux processus sont en cours d'exécution et le système est très occupé.
  bi/bo : La quantité de données écrites sur le disque est légèrement plus importante. S'il s'agit d'un fichier volumineux, il n'y a pratiquement pas lieu de s'inquiéter. moins de 10M. S'il s'agit d'un petit fichier, c'est fondamentalement normal s'il est inférieur à 2M.
  cpu us : Il est continuellement supérieur à 50%, ce qui est acceptable pendant les périodes de pointe de service. Pendant longtemps, vous pouvez envisager une optimisation
  cpu sy : Le pourcentage de processus réels du noyau. La valeur de référence de us + sy ici est de 80 %. Si us + sy est supérieur à 80 %, cela indique que le CPU peut être insuffisant.
  cpu wa : la colonne indique le pourcentage de temps CPU occupé par l'attente des E/S. La valeur de référence de wa est ici de 30 %. Si wa dépasse 30 %, cela signifie que l'attente d'E/S est importante. Cela peut être dû à un grand nombre d'accès aléatoires au disque, ou à un goulot d'étranglement de bande passante. le contrôleur d'accès au disque ou au disque (opérations de blocage principalement)

Lien de référence : https://www.cnblogs.com/zsql/p/11643750.html

2. Regardez le code diff

. Le redémarrage de l'instance n'a pas résolu le problème et il est déterminé qu'il s'agit d'un problème avec le processus du nœud. Si tel est le cas,

Vérifiez le commit en ligne, vérifiez la différence de code et voyez si vous pouvez trouver le problème

3. Ouvrez le profileur de CPU d'exécution

Cette méthode de fonctionnement est similaire à mon autre articleComment localiser rapidement le problème de fuite de mémoire côté serveur SSR est similaire à

• Utilisez node --inspect pour démarrer le service

• pour simuler l'environnement en ligne localement. Si vous utilisez le code construit, la construction directe peut ne pas fonctionner Vous devez contrôler les variables d'environnement et la compression laide doit être désactivée

  • Par exemple, laissez certaines variables d'environnement. (nom de domaine CDN, etc.) pointent vers le local, car le package est local et n'est pas téléchargé sur le CDN

• Générer un profileur de CPU

Et si l'environnement en ligne ne peut pas être simulé localement ?

Par exemple, le RPC en aval est isolé du local, vous ne pouvez donc ajouter du code que pour créer un profilnodejs.org/docs/latest…

Après avoir obtenu le fichier de profil, ouvrez-le avec Chrome devtool

4. Analysez le profileur de CPU

• Combinez le profileur et le code diff pour trouver la cause

• Vous pouvez également télécharger le fichier de profil sur www.speedscope.app/ (téléchargement de fichier) pour obtenir le graphique de flamme du profil du processeur (Introduction d'utilisation plus détaillée : www.npmjs.com/package/spe...

5. Vérification du test de pression

Vous pouvez utiliser ab , ou d'autres outils de test de pression

Résumé Trouvez la raison

Vérification du test de contrainte

• Pour plus de connaissances sur les nœuds, veuillez visiter :
Tutoriel Nodejs
•  !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!