nodejs mysql 大量高频查询的内存泄漏
nodejs mysql memory leak on large volume of high frequency queries
TL;DR
https://gist.github.com/anonymous/1e0faaa99b8bb4afe3749ff94e52c84f - 演示内存消耗意味着泄漏。这是在我的代码中还是在 mysql 包中？
完整版：
我发现我的程序中存在大量内存泄漏（并且最终每隔几个小时就会崩溃）。该程序通过 UDP 套接字接收大量数据，将相关位存储在内存中的哈希中，并每 10 秒将其哈希中的数据写入 Mysql DB（AWS RDS 实例）一次。 node.js 版本是 6.9.4，运行ning on RHEL 7.1
我尝试使用“--inspect”选项和 Chrome devtools 进行一些分析，我最初怀疑是 mysql 包。为此，我制作了一个简单的 node.js 程序，它只对本地数据库进行大量查询，并观察到它确实非常快地消耗了大量内存。这是程序：https://gist.github.com/anonymous/1e0faaa99b8bb4afe3749ff94e52c84f
我尝试了该程序的几个变体，所有变体都以明显指向内存不足崩溃的速度消耗内存。变化是：
- 使用单一连接
- 使用具有 30 个连接的池（这是生产设置）
- 使用有效的查询语句
- 使用导致解析错误的无效查询语句（第 27 行字符串 123 之前的 space 使其成为错误查询。删除 space 使其成为有效查询）
上面的程序与内存数据库完全不同。它只做一件事：以高频率向 Mysql 数据库发出大量更新查询。
为了方便演示内存消耗，我把频率设置为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].
问题：
- 对于如此多的查询来说，这种内存消耗是预期的还是这表明存在泄漏？
- 我的代码是否泄漏了内存？我错过了什么明显的事情吗？我是不是用错了包？
- 如果这确实是包中的泄漏，在修复泄漏之前是否有任何立即的解决方法？
我非常乐意提供任何其他所需的信息来找出问题的根源。请告诉我。
在这里给出答案只是为了让面临类似问题的人受益。
在我的例子中，问题不是内存泄漏而是吞吐量。我是 运行 的 Mysql 服务器无法在如此短的时间内处理如此多的查询。以这样的频率，我有点窒息 Mysql 服务器。
Nodejs 只会继续为每个新查询创建一个新连接 and/or 一个查询对象。一旦查询完成，该对象将从内存中释放。但是客户端以如此高的频率发送如此多的查询，以至于 Mysql 服务器花费大量时间来完成每个查询。
简而言之，提出查询的速度远高于完成这些查询的速度。因此，查询/连接对象刚刚开始在客户端堆积，导致内存使用量不断增加。
这看起来像是泄漏。但事实并非如此。
我学到的区分泄漏和吞吐量问题的一项技术是停止创建工作（在本例中停止新查询）并检查内存使用量是否下降。如果是，则说明是吞吐量问题，如果不是，则可能是内存泄漏。
在我的例子中，每秒大约 8,000 个查询就可以正常工作。大约 8.5k 到 9k 会导致此吞吐量问题，最终导致崩溃。
TL;DR
https://gist.github.com/anonymous/1e0faaa99b8bb4afe3749ff94e52c84f - 演示内存消耗意味着泄漏。这是在我的代码中还是在 mysql 包中？
完整版：
我发现我的程序中存在大量内存泄漏（并且最终每隔几个小时就会崩溃）。该程序通过 UDP 套接字接收大量数据，将相关位存储在内存中的哈希中，并每 10 秒将其哈希中的数据写入 Mysql DB（AWS RDS 实例）一次。 node.js 版本是 6.9.4，运行ning on RHEL 7.1
我尝试使用“--inspect”选项和 Chrome devtools 进行一些分析，我最初怀疑是 mysql 包。为此，我制作了一个简单的 node.js 程序，它只对本地数据库进行大量查询，并观察到它确实非常快地消耗了大量内存。这是程序：https://gist.github.com/anonymous/1e0faaa99b8bb4afe3749ff94e52c84f
我尝试了该程序的几个变体，所有变体都以明显指向内存不足崩溃的速度消耗内存。变化是：
- 使用单一连接
- 使用具有 30 个连接的池（这是生产设置）
- 使用有效的查询语句
- 使用导致解析错误的无效查询语句（第 27 行字符串 123 之前的 space 使其成为错误查询。删除 space 使其成为有效查询）
上面的程序与内存数据库完全不同。它只做一件事：以高频率向 Mysql 数据库发出大量更新查询。
为了方便演示内存消耗，我把频率设置为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].
问题：
- 对于如此多的查询来说，这种内存消耗是预期的还是这表明存在泄漏？
- 我的代码是否泄漏了内存？我错过了什么明显的事情吗？我是不是用错了包？
- 如果这确实是包中的泄漏，在修复泄漏之前是否有任何立即的解决方法？
我非常乐意提供任何其他所需的信息来找出问题的根源。请告诉我。
在这里给出答案只是为了让面临类似问题的人受益。
在我的例子中，问题不是内存泄漏而是吞吐量。我是 运行 的 Mysql 服务器无法在如此短的时间内处理如此多的查询。以这样的频率，我有点窒息 Mysql 服务器。
Nodejs 只会继续为每个新查询创建一个新连接 and/or 一个查询对象。一旦查询完成，该对象将从内存中释放。但是客户端以如此高的频率发送如此多的查询，以至于 Mysql 服务器花费大量时间来完成每个查询。
简而言之，提出查询的速度远高于完成这些查询的速度。因此，查询/连接对象刚刚开始在客户端堆积，导致内存使用量不断增加。
这看起来像是泄漏。但事实并非如此。
我学到的区分泄漏和吞吐量问题的一项技术是停止创建工作（在本例中停止新查询）并检查内存使用量是否下降。如果是，则说明是吞吐量问题，如果不是，则可能是内存泄漏。
在我的例子中，每秒大约 8,000 个查询就可以正常工作。大约 8.5k 到 9k 会导致此吞吐量问题，最终导致崩溃。