压力测试，模式真实场景，需要调用外部API 2次，数据库写操作2次，读3次位单位的一次请求，测试工具Jmeter，300线程，200组，每次共计6万次请求，服务器为8核8G nodejs api 服务。 1、在8核cpu跑到80～100%，时候，发生延迟，日志显示接受消息比发送端延迟3秒。经过分析，Linux OS是一个文件服务系统，表示CPU处理任务压力导致处理网络请求变慢，而不是网络延迟。发现，日志写存在问题，Jmeter 接受到全部返回后，服务器Log4js 日志还在不停写，内存上看有内存没有释放的问题。 2、memwatch， 和 heapdump 加载后，发现只有在CPU压力达到一定比率时候，才会跳出来memwatch leak，而且近似随即。 heapdump文件，随着时间增加，文件容量不断扩大，文件里面system /JSArrayBufferData 增加最快，里面有大量sequelize 名字，则怀疑数据库问题，则做了数据库测试，对30万条数据库记录进行读写。。发现偶尔只有1-2次的memwatch leak 事件发生，觉得数据库方面问题不大，估计还是其他因素。 3、降低服务器压力，50%左右强度测试压力，memwatch leak 事件没有发生，但是内存还是没有完全释放。表示还是存在程序方面或者软件系统问题，考虑到日志问题，则取消日志输出，恢复正常压力测试，问题消失，判断为日志问题。 4、有群友表示log4js 写不好，很容易出现内存泄漏，则重新写了log4js 相关程序代码，并且在pm2 上引入了pm2-intercom , 利用IPC机制，将日志都集中到主进程读写，降低日志写竞争的问题。重新测试后，一切正常，CPU 跑到了40%上下，每个进程内存消耗120M上下。。一切都是日志问题，程序写的日志处理部分有bug，这个bug只有在高密度访问cpu 时候，才会造成内存泄漏无法释放。 5、吐槽以下node V 8.2.1 版本实在太烂了，不如node V8.1.3， 同样硬件配置机器 V8.2.1 CPU会比 V8.1.3 高20%，造成在pm2 里面看到loop delay 一个是0.34 ， 一个是0.62 。。。。估计是 GCC 4.9.4 版本东西没做好。 觉得V 8.2.1 机器更容易测出问题来。。。。。。 nodejs 的内存问题，如果不上压力测试，估计还有时候还真看不出来啊。。。。代码一定要严谨 啊，严谨，不能太随意，能运行并不一定正确，编码完成后，真的只完成了10%的开发。。。。