Node效劳中怎样监控当地环境及生产环境的内存转变?
当使用 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'))
进程内存监控
一些问题需要在当地及测试环境得到及时抹杀,来幸免在生产环境造成更大的影响。那么理解在当地怎样监控内存就至关重要。
pidstat
是 sysstat
系列 linux 机能调试工具的一个包,居然用它来调试 linux 的机能问题,包罗内存,网络,IO,CPU 等。
这不仅试用与 node
,并且适用于一切进程,包罗 python
,java
乃至 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
呢?有两种方法
- 通过余外的参数结合
ps
定位进程 - 通过端标语结合
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 监控内存
从以上代码中可以知道,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
生产环境内存监控
由于当前生产环境大都摆设在 k8s
,因此生产环境关于某个利用的内存监控本质上是 k8s 关于某个 workload/deployment
的内存监控,关于内存监控 metric
的数据流向大致如下:
k8s
-> metric server
-> prometheus
-> grafana
架构图如下:
以上图片取自以下文章
- 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 的示例定位