我们的情况：
业务就是从mysql中查列表，有redis缓存；
server跑在单机(aws上的m3.large机型，配置是cpu*2，内存7.5g)上，开了两个node进程，mysql和redis都在其他机器上；
高峰qps：100左右，平时qps：60~80左右；
高峰时系统的负载值在3以下，cpu使用大概增加到70~80%，这个时候内存会非常迅速从100M增加到1.4G，然后整个node进程会挂掉，监控显示每10分钟就会重启，而且重启后server也是残废，请求基本都会超时。
按之前php的经验，服务器扛不住时，负载会变得非常高。这下发现平时负载在1.5左右，高峰也就在3左右；qps涨得也不是特别多，平时60~80的时候指标都很平稳，没道理涨20就扛不住；然后内存涨得特别猛，沿着内存泄露的方向找了半个月也没有结果。就在最后没有办法的时候，增加了一台服务器，把流量分了一半出去。现在跑了一个星期，各项指标都平稳了，内存一直维持在100M左右，也一直没有重启过。
我的疑惑：
1. node扛不住大概会是什么表现呢，是跟我上面描述我们的情况类似吗？
2. 内存暴增是不是因为cpu处理不过来，请求堆积导致，有没有办法优化？
3. 有什么办法预警node扛不住了？
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
php 是因为进程多，所以会体现在 load 上面。load 值本质上是指同时运行的进程数，node 就是个单线程的东西，就算两个进程 CPU 跑满了也不会让 load 超过 2。
你的情况应该就是 node 没有足够的 CPU 资源处理请求，导致各种异步回调都堆积起来，内存释放不了，最终就恶性循环造成崩溃了。我其实没有 node 的 CPU 占用率的经验值，你可能可以从这个经验里面得出一个适合 AWS 的经验值。
预警的方法是做一个内存监控，或者干脆就设定一个内存上限，一旦超过就杀掉重启。对 node 来说，杀掉进程是比任何一种保守疗法更好的做法。
装个munin，把系统的各项参数都记录下来，你很容易就分析到系统瓶颈。
我同意CPU资源不够的说法，但是没有证据，或许是socket连接限制呢？毕竟系统里面也没涉及到复杂的运算。
另外，作为AWS用户，如果CPU不够，可以选CPU更强但是内存小一点的产品，很划算的。