nodejs的mysql内存泄漏大量的高频查询

TL; DR

https://gist.github.com/anonymous/1e0faaa99b8bb4afe3749ff94e52c84f – 演示内存消耗意味着泄漏。 这是在我的代码或在MySQL包？

完整版 ：

我在程序中看到很多内存泄漏（并且每隔几个小时最终会崩溃）。 该程序通过UDP套接字接收大量数据，将相关位存储在内存中的Hash中，并将数据每10秒钟一次写入Mysql DB（AWS RDS实例）。 node.js版本是6.9.4，在RHEL 7.1上运行

我试着用“–inspect”选项和Chrome devtools做一些分析，我最初的怀疑是mysql包。 为此，我做了一个简单的node.js程序，它只是对本地数据库进行了大量的查询，并发现它确实消耗了很多内存。 这里是程序： https ： //gist.github.com/anonymous/1e0faaa99b8bb4afe3749ff94e52c84f

我尝试了一些程序的变化，他们都消耗内存的速度明显指向内存不足的崩溃。 变化是：

1. 使用单个连接
2. 使用30个连接池（这是生产设置）
3. 使用有效的查询语句
4. 使用导致parsing错误的无效查询语句（第27行中的string123之前的空格使其成为错误的查询。删除空格使得该查询是有效的）

这个上面的程序没有像内存中的数据库。 它只做一件事：以高频率向MySQL数据库发出大量的UPDATE查询。

我已经将频率设置为2秒来轻松演示内存消耗。 降低这个频率将减缓内存消耗，但是它将会增长。 它只会延迟崩溃，但崩溃本身是不可避免的。

频率的实际使用要求是10秒，每次运行的更新查询次数将达到10,000次。 所以示例程序中的数字非常接近真实世界的情况，不仅仅是一些假设的模拟数字。

这里是“–trace-gc”的输出，表示内存消耗在一分钟内升至400MB：

[29766:0x36c5120] 52326 ms: Scavenge 324.9 (365.1) -> 314.7 (369.1) MB, 8.3 / 0.0 ms [allocation failure]. [29766:0x36c5120] 53292 ms: Scavenge 330.3 (370.1) -> 317.4 (372.1) MB, 3.3 / 0.0 ms [allocation failure]. [29766:0x36c5120] 53477 ms: Scavenge 333.4 (374.1) -> 329.0 (375.1) MB, 15.6 / 0.0 ms [allocation failure]. [29766:0x36c5120] 53765 ms: Scavenge 335.5 (375.1) -> 331.9 (385.1) MB, 20.8 / 0.0 ms [allocation failure]. [29766:0x36c5120] 54701 ms: Scavenge 346.4 (386.1) -> 334.4 (388.1) MB, 5.3 / 0.0 ms [allocation failure]. [29766:0x36c5120] 55519 ms: Scavenge 349.9 (389.1) -> 338.9 (390.1) MB, 5.7 / 0.0 ms [allocation failure]. [29766:0x36c5120] 55614 ms: Scavenge 353.1 (392.1) -> 350.0 (395.1) MB, 17.8 / 0.0 ms [allocation failure]. [29766:0x36c5120] 56081 ms: Scavenge 356.8 (395.1) -> 351.3 (405.1) MB, 18.5 / 0.0 ms [allocation failure]. [29766:0x36c5120] 57195 ms: Scavenge 367.5 (406.1) -> 354.2 (407.1) MB, 3.2 / 0.0 ms (+ 20.1 ms in 236 steps since last GC) [allocation failure]. [29766:0x36c5120] 57704 ms: Scavenge 369.9 (408.1) -> 362.8 (410.1) MB, 12.5 / 0.0 ms (+ 15.7 ms in 226 steps since last GC) [allocation failure]. [29766:0x36c5120] 57940 ms: Scavenge 372.6 (412.1) -> 369.2 (419.1) MB, 21.6 / 0.0 ms (+ 8.5 ms in 139 steps since last GC) [allocation failure]. [29766:0x36c5120] 58779 ms: Scavenge 380.4 (419.1) -> 371.1 (424.1) MB, 11.4 / 0.0 ms (+ 11.3 ms in 165 steps since last GC) [allocation failure]. [29766:0x36c5120] 59795 ms: Scavenge 387.0 (426.1) -> 375.3 (427.1) MB, 10.6 / 0.0 ms (+ 14.4 ms in 232 steps since last GC) [allocation failure]. [29766:0x36c5120] 59963 ms: Scavenge 392.0 (431.3) -> 388.8 (434.3) MB, 19.1 / 0.0 ms (+ 50.5 ms in 207 steps since last GC) [allocation failure]. [29766:0x36c5120] 60471 ms: Scavenge 395.4 (434.3) -> 390.3 (444.3) MB, 20.2 / 0.0 ms (+ 19.2 ms in 96 steps since last GC) [allocation failure]. [29766:0x36c5120] 61781 ms: Scavenge 406.2 (446.3) -> 393.0 (447.3) MB, 3.7 / 0.0 ms (+ 107.6 ms in 236 steps since last GC) [allocation failure]. [29766:0x36c5120] 62107 ms: Scavenge 409.0 (449.3) -> 404.1 (450.3) MB, 16.0 / 0.0 ms (+ 41.0 ms in 227 steps since last GC) [allocation failure]. [29766:0x36c5120] 62446 ms: Scavenge 411.3 (451.3) -> 407.7 (460.3) MB, 22.6 / 0.0 ms (+ 20.2 ms in 103 steps since last GC) [allocation failure]. 

问题：

1. 这种内存消耗预计会有这么多的查询，或者这是泄漏的指示？
2. 我的代码是否泄漏了内存？ 任何明显的我已经错过了？ 我是否以错误的方式使用软件包？
3. 如果这确实是包装中的泄漏，是否有任何直接的解决办法，直到泄漏是固定的？

我很乐意提供任何其他信息，这是需要的根源。 请告诉我。