本文摘自PHP中文网,作者青灯夜游,侵删。

当使用 Node 在生产环境作为服务器语言时,并发量过大或者代码问题造成 OOM (out of memory) 或者 CPU 满载这些都是服务器中常见的问题,此时通过监控 CPU 及内存,再结合日志及 Release 就很容易发现问题。
【视频教程推荐:node js教程 】
本章将介绍如何监控本地环境及生产环境的内存变化
一个 Node 应用实例
所以,如何动态监控一个 Node 进程的内存变化呢?
以下是一个 Node Server 的示例,并且是一个有内存泄漏问题的示例,并且是山月在生产环境定位了很久的问题的精简版。
那次内存泄漏问题中,导致单个容器中的内存从原先的 400M 暴涨到 700M,在 800M 的容器资源限制下偶尔会发生 OOM,导致重启。一时没有定位到问题 (发现问题过迟,半个月前的时序数据已被吞没,于是未定位到 Release),于是把资源限制上调到 1000M。后发现是由 ctx.request 挂载了数据库某个大字段而致
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
进程内存监控
一些问题需要在本地及测试环境得到及时扼杀,来避免在生产环境造成更大的影响。那么了解在本地如何监控内存就至关重要。
pidstat
是 sysstat
系列 linux 性能调试工具的一个包,竟然用它来调试 linux 的性能问题,包括内存,网络,IO,CPU 等。
这不仅试用与 node
,而且适用于一切进程,包括 python
,java
以及 go
1 2 3 4 5 |
|
而在使用 pidstat
之前,需要先找到进程的 pid
如何找到 Node 进程的 pid
在 node
中可以通过 process.pid
来找到进程的 pid
1 2 |
|
虽然通过写代码可以找到 pid
,但是具有侵入性,不太实用。那如何通过非侵入的手段找到 pid
呢?有两种办法
- 通过多余的参数结合
ps
定位进程 - 通过端口号结合
lsof
定位进程
1 2 3 4 5 6 7 8 9 10 |
|
使用 pidstat 监控内存
从以上代码中可以知道,node 服务的 pid 为 31796
,为了可以观察到内存的动态变化,再施加一个压力测试
1 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
对于输出指标的含义如下
RSS
:Resident Set Size
,常驻内存集,可理解为内存,这就是我们需要监控的内存指标VSZ
:virtual size
,虚拟内存
从输出可以看出,当施加了压力测试后,内存由 19M 涨到了 85M。
使用 top 监控内存
pidstat
是属于 sysstat
下的 linux 性能工具,但在 mac 中,如何定位内存的变化?
此时可以使用 top/htop
1 |
|
生产环境内存监控
由于目前生产环境大都部署在 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 的示例定位
更多编程相关知识,可访问:编程入门!!
以上就是Node服务中如何监控本地环境及生产环境的内存变化?的详细内容,更多文章请关注木庄网络博客!
相关阅读 >>
更多相关阅读请进入《Node》频道 >>

Vue.js 设计与实现 基于Vue.js 3 深入解析Vue.js 设计细节
本书对 Vue.js 3 技术细节的分析非常可靠,对于需要深入理解 Vue.js 3 的用户会有很大的帮助。——尤雨溪,Vue.js作者