百分百源码网-让建站变得如此简单! 登录 注册 签到领金币!

主页 | 如何升级VIP | TAG标签

当前位置: 主页>网站教程>JS教程> Node效劳中怎样监控当地环境及生产环境的内存转变?
分享文章到:

Node效劳中怎样监控当地环境及生产环境的内存转变?

发布时间:09/01 来源:未知 浏览: 关键词:

当使用 Node 在生产环境作为效劳器说话时,并发量过大或者代码问题造成 OOM (out of memory) 或者 CPU 满载这些都是效劳器中常见的问题,此时通过监控 CPU 及内存,再结合日志及 Release 就很容易发明问题。

【视频教程引荐:node js教程 】

本章将介绍怎样监控当地环境及生产环境的内存转变

一个 Node 利用实例

所以,怎样动态监控一个 Node 进程的内存转变呢?

以下是一个 Node Server 的示例,并且是一个有内存走漏问题的示例,并且是山月在生产环境定位了很久的问题的精简版。

那次内存走漏问题中,致使单个容器中的内存从本来的 400M 暴涨到 700M,在 800M 的容器资源限制下偶然会发生 OOM,致使重新启动。一时没有定位到问题 (发明问题过迟,半个月前的时序数据已被淹没,于是不决位到 Release),于是把资源限制上调到 1000M。后发明是由 ctx.request 挂载了数据库某个大字段而致
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'))

进程内存监控

一些问题需要在当地及测试环境得到及时抹杀,来幸免在生产环境造成更大的影响。那么理解在当地怎样监控内存就至关重要。

pidstatsysstat 系列 linux 机能调试工具的一个包,居然用它来调试 linux 的机能问题,包罗内存,网络,IO,CPU 等。

这不仅试用与 node,并且适用于一切进程,包罗 pythonjava 乃至 go

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

而在使用 pidstat 此前,需要先寻到进程的 pid

怎样寻到 Node 进程的 pid

node 中可以通过 process.pid 来寻到进程的 pid

> process.pid
16425

虽然通过写代码可以寻到 pid,但是具有侵入性,不太有用。那怎样通过非侵入的手段寻到 pid 呢?有两种方法

  1. 通过余外的参数结合 ps 定位进程
  2. 通过端标语结合 lsof 定位进程
$ 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)

使用 pidstat 监控内存

1.png

从以上代码中可以知道,node 效劳的 pid 为 31796,为了可以视察到内存的动态转变,再施加一个压力测试

$ 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

关于输出目标的含义如下

  • RSS: Resident Set Size,常驻内存集,可懂得为内存,这就是我们需要监控的内存目标
  • VSZ: virtual size,虚拟内存

从输出可以看出,当施加了压力测试后,内存由 19M 涨到了 85M。

使用 top 监控内存

pidstat 是属于 sysstat 下的 linux 机能工具,但在 mac 中,怎样定位内存的转变?

此时可以使用 top/htop

$ htop -p 31796

2.png

生产环境内存监控

由于当前生产环境大都摆设在 k8s因此生产环境关于某个利用的内存监控本质上是 k8s 关于某个 workload/deployment 的内存监控,关于内存监控 metric 的数据流向大致如下:

k8s -> metric server -> prometheus -> grafana

架构图如下:

3.png

4.png

以上图片取自以下文章

  • Kubernetes Monitoring with Prometheus
  • Kubernetes monitoring architecture

终究能够在 grafana 中收集到某一利用的内存监控实时图:

由于本部分设计内容过多,我将在以下的章节中停止介绍

这不仅仅适用于 node 效劳,并且适用于一切 k8s 上的 workload

总结

本章介绍了关于 Node 效劳的内存在当地环境及生产环境的监控

1、当地使用 htop/top 或者 pidstat 监控进程内存

2、生产环境使用 k8s/metric-server/prometheus/grafana 监控 node 整个利用的内存

当监控到某一效劳发生内存走漏后,怎样解决问题?因此接下来的文章将会讲到

1、生产环境是怎样监控整个利用的内存的

2、当生产环境发生 OOM 后,怎样快速定位

3、真实生产环境若干 OOM 的示例定位

打赏

打赏

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

百分百源码网 建议打赏1~10元,土豪随意,感谢您的阅读!

共有154人阅读,期待你的评论!发表评论
昵称: 网址: 验证码: 点击我更换图片
最新评论

本文标签

广告赞助

能出一分力是一分吧!

订阅获得更多模板

本文标签

广告赞助

订阅获得更多模板