Comment surveiller les changements de mémoire dans l'environnement local et l'environnement de production dans le service Node ?

Lors de l'utilisation de Node dans un environnement de production en tant que langage de serveur, une concurrence excessive ou des problèmes de code peuvent entraîner un MOO (manque de mémoire) ou le processeur. être complètement chargé. Ce sont des problèmes courants sur les serveurs. À l'heure actuelle, il est facile de détecter les problèmes en surveillant le processeur et la mémoire, combinés aux journaux et aux versions.

[Recommandation du didacticiel vidéo : Tutoriel node js]

Ce chapitre présentera comment surveiller les changements de mémoire dans l'environnement local et l'environnement de production

Une instance d'application Node

Alors, comment surveiller dynamiquement les changements de mémoire d'un processus Node ?

Ce qui suit est un exemple de serveur Node, et c'est un exemple de problème de fuite de mémoire, et c'est une version simplifiée du problème que Shanyue positionne depuis longtemps dans l'environnement de production.

Dans ce problème de fuite de mémoire, la mémoire dans un seul conteneur est passée de 400 Mo d'origine à 700 Mo de MOO, ce qui s'est parfois produit en dessous de la limite de ressources du conteneur de 800 Mo, entraînant un redémarrage. Le problème n'a pas été localisé pendant un certain temps (le problème a été découvert trop tard, les données de la série chronologique d'il y a un demi-mois avaient été englouties, donc la version n'a pas été localisée), la limite de ressources a donc été augmentée à 1000M. Plus tard, il a été découvert que cela était dû au montage par ctx.request d'un grand champ dans la base de données

const Koa = require('koa')
const app = new Koa()

function getData () {
  return Array.from(Array(1000)).map(x => 10086)
}

app.use(async (ctx, next) => {
  ctx.data = getData()
  await next()
})

app.use(ctx => {
  ctx.body = 'hello, world'
})

app.listen(3200, () => console.log('Port: 3200'))

Surveillance de la mémoire des processus

Certains problèmes doivent être éliminés à temps dans l'environnement local et de test, pour éviter un impact plus important sur l'environnement de production. Il est ensuite crucial de comprendre comment surveiller la mémoire localement.

pidstat est un package de la série sysstat d'outils de débogage de performances Linux. Il peut être utilisé pour déboguer les problèmes de performances Linux, notamment la mémoire, le réseau, les E/S, le processeur, etc.

Cela fonctionne non seulement avec node, mais fonctionne également avec tous les processus, y compris python, java et go

# -r: 指输出内存指标
# -p: 指定 pid
# 1: 每一秒输出一次
# 100: 输出100次
$ pidstat -r -p pid 1 100

lors de l'utilisation de pidstat Avant, vous devez trouver le processus pid

Comment trouver le pid du processus Node

Dans node vous pouvez utiliser process.pid pour trouver le processuspid

> process.pid
16425

Bien que pid puisse être trouvé en écrivant du code, il est intrusif et peu pratique. Alors comment trouver pid par des moyens non invasifs ? Il existe deux manières

1. Combinaison avec des paramètres redondants ps Localisation du processus
2. Combinaison avec le numéro de port lsof Localisation du processus

$ node index.js shanyue

# 第一种方法：通过多余的参数快速定位 pid
$ ps -ef | grep shanyue
root     31796 23839  1 16:38 pts/5    00:00:00 node index.js shanyue

# 第二种方法：通过端口号定位 pid
lsof -i:3200
COMMAND   PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
node    31796 root   20u  IPv6 235987334      0t0  TCP *:tick-port (LISTEN)

Utilisez pidstat pour surveiller la mémoire

À partir du code ci-dessus, nous pouvons savoir que le pid du service de nœud est 31796 Afin d'observer. les changements dynamiques de la mémoire, appliquer Un test de stress

$ ab -c 10000 -n 1000000 http://localhost:3200/

# -r: 指输出内存指标
# -p: 指定 pid
# 1: 每一秒输出一次
# 100: 输出100次
$ pidstat -r -p 31796 1 100
Linux 3.10.0-957.21.3.el7.x86_64 (shuifeng)     2020年07月02日  _x86_64_        (2 CPU)

             UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
19时20分39秒     0     11401      0.00      0.00  566768  19800   0.12  node
19时20分40秒     0     11401      0.00      0.00  566768  19800   0.12  node
19时20分41秒     0     11401   9667.00      0.00  579024  37792   0.23  node
19时20分42秒     0     11401  11311.00      0.00  600716  59988   0.37  node
19时20分43秒     0     11401   5417.82      0.00  611420  70900   0.44  node
19时20分44秒     0     11401   3901.00      0.00  627292  85928   0.53  node
19时20分45秒     0     11401   1560.00      0.00  621660  81208   0.50  node
19时20分46秒     0     11401   2390.00      0.00  623964  83696   0.51  node
19时20分47秒     0     11401   1764.00      0.00  625500  85204   0.52  node

a la signification suivante pour les indicateurs de sortie :

• RSS : Resident Set Size, ensemble de mémoire résident, peut être compris comme mémoire, c'est la mémoire dont nous avons besoin pour surveiller Indicateurs
• VSZ : virtual size, mémoire virtuelle

Comme le montre la sortie, après le stress test a été appliqué, la mémoire est passée de 19M à 85M.

Utiliser top pour surveiller la mémoire

pidstat est un outil de performances Linux sous sysstat, mais comment localiser les changements de mémoire sous Mac ?

Vous pouvez utiliser top/htop

$ htop -p 31796

Surveillance de la mémoire de l'environnement de production

Étant donné que la plupart des environnements de production actuels sont déployés dans k8s, Par conséquent, la surveillance de la mémoire d'une certaine application dans l'environnement de production est essentiellement la surveillance de la mémoire d'un certain workload/deployment par k8s Le flux de données de surveillance de la mémoire metric est à peu près le suivant : <.>

-> k8s -> metric server -> prometheusgrafana

Le schéma d'architecture est le suivant :

Les photos ci-dessus sont tirées des articles suivants

• Surveillance Kubernetes avec Prometheus
• Architecture de surveillance Kubernetes

Enfin, le graphique en temps réel de surveillance de la mémoire d'une application peut être collecté dans

 : grafana

Comme il y a trop de contenu de conception dans cette partie, je le présenterai dans les chapitres suivants

Cela s'applique non seulement aux services de nœuds, mais s'applique également à tout sur k8 workload

Résumé

Ce chapitre présente la surveillance de la mémoire du service Node dans l'environnement local et l'environnement de production

1 Utilisez local htop/top ou pidstat pour surveiller. mémoire de processus

2. Utilisation dans un environnement de productionk8s/metric-server/prometheus/grafana Surveiller la mémoire de l'ensemble de l'application du nœud

Lorsqu'une fuite de mémoire est détectée dans un certain service, comment résoudre le problème ? Par conséquent, le prochain article parlera de

1. Comment l'environnement de production surveille la mémoire de l'ensemble de l'application

2 Lorsque le MOO se produit dans l'environnement de production, comment localiser rapidement

.

3. Plusieurs exemples de positionnement de MOO dans des environnements de production réels

Pour plus de connaissances liées à la programmation, veuillez visiter : Introduction à la programmation ! !

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!