以为是node程序有问题，导致内存爆表，频繁宕机，目前看来应该是被人盯上了，无奈对网络安全一无所知，看访问日志，一堆的未知来源反向代理，回访回去更是细思极恐。

宕机问题搞清楚了，是内存爆表导致的，观察了一上午，访问密集的话，内存使用率急剧升高，给pm2加了max_memory_restart参数，内存超过160m自动重启；

其实还有个小坑，nuxt的项目启动可以用npm也可以nuxt命令，pm2启动"nuxt"会导致直接性的没法run，具体原因未知，略复杂；

最后在mac进程管理里看到真实运行时的形态，把这个形态转移到配置文件就可以了，如下：

          
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
          module.exports = {
  apps: [
    {
      name: "surmon.me",
      watch: true,
      cwd: "./",
      script: "node",
      args: "./node_modules/.bin/nuxt start",
      max_memory_restart: "160M",
      log_date_format: "YYYY-MM-DD HH:mm Z",
      error_file: "/usr/local/wwwlogs/surmon.me/error.log",
      out_file: "/usr/local/wwwlogs/surmon.me/out.log",
      env: {
        "NODE_ENV": "production",
      }
    }
  ]
}
        

坑：在pm2中以"npm"为script执行，无法检测到真实运行的程序的内存等相关情况。

最终产品的稳定还是需要产品本身的稳定，不是这些奇技淫巧，笨办法是办法，但一定不是最优办法；所以周末需要对项目做深度优化，找到内存泄漏的节点，kill it。

关于第二点异常访问的情况，是真实存在的，我正在寻找防火墙或nginx部分来解决这个问题。

最终使用 idle-gc 模块来收集垃圾，实现内存平衡。

idle-gc是在node早期版本中被废除的功能，主要负责空闲时的堆内存回收，然后早期被认为有bug，经常会导致cpu满载，于是从node中移除了，此项目作者修复了这个bug，并发布了模块。

大致工作原理就是每次“程序活动结束”5秒后执行一次垃圾回收，当然可以手动指定时间，但是如果有定时器，则定时器会被认为是“活动事件”，也就意味着永远不会回收垃圾，要注意。

2017-03-25更新

最终新建了一个主程序文件，server.js，作为node程序启动，将nuxt作为node程序的中间件，使程序更加可控，也更利与管理。 代码在这

完