我们目前有一个性能不佳的生产型node.js应用程序。现在,该应用程序是一个实时竞标平台,并且可以运行定时拍卖。运行实时销售的实际系统是完美的,并且可以按要求工作。我们注意到,在运行定时销售时(销售中的项目具有计时器,它们会逐步完成,如果有人在最后设置的时间内出价,则时间会增加X秒钟)。
现在,我发现的问题是,如果商品在每批之间有60秒的间隔,并且如果用户在最后10秒钟竞标,则可以延期,这是在定时销售完成(可以持续数小时)期间进行的。这样我们就可以通过devtools进行连接,并且我已经完成了堆内存导出,以查看发生了什么,但是我所能看到的是所有指示都指向可写流和缓冲区。所以我的问题是我在做什么错。参见下面的堆内存导出屏幕截图:
从上面可以看到,使用1473MB的物理RAM专门为此使用了很多内存。我们非常迅速地(在30分钟内)看到了这种增长,并且每次增长似乎都超过了最后一次。因此,当它达到3.5GB时,它以每秒约120MB的速度递增,然后,当它达到约5GB时,它以每秒500MB的速度递增,并达到约6GB,然后该工人崩溃了(最大堆大小为8GB),然后我们陷入困境。
所以让我告诉您有关平台的信息。正如我之前所说,它当然是一个竞标平台,该平台使用Node(v11.3.0),并使用内置的群集库进行群集。它产生4个工人,并具有主要过程(总共5个)。该系统接受投标,检查其他投标,计算谁胜出,并实质上通过Redis PUB / SUB将更新发送给所连接的客户端,然后广播给该工人所连接的用户。
所有数据都存储在redis中,并且mysql用于将数据刷新到redis,因为redis的执行速度比mysql快10倍。
现在,在连接上工作的方式是针对该连接创建一个小型会话,然后将其用于验证用户(这是从客户端发送的消息),所有消息事件均发送到处理程序,该处理程序将其推送到正确的命令然后将这些命令全部设置为异步函数并运行异步。
现在这在小范围内没有问题,但是我们有250多个连接,并且看到上述行为,并且不确定在哪里可以找到修复程序。我们注意到在打开顶部对象时,它也连接到buffer.js和stream_writable.js。我还可以看到所有引用都已连接到system / JSArrayBufferData,并且所有引用都返回到这些引用,其中有很多对象,我们无法解决此问题。
我们认为以下情况之一:
我们使用追加模式登录到文件,该模式使用fs.writeFile和追加模式将大量信息记录到控制台和文件中。我们进行了一些研究,发现编写控制台可能是这种行为的原因。
获取数量功能,每次完成一个项目时都会输出该页面的所有数量(当前设置为50),因此,如果计时器结束,它将要求加载所有项目的完整页面该页面,而不是添加新的批次。
这里我们还没有意识到其他事情,也许我们正在使用的外部库可能没有删除引用。
我已经列出了我们需要的感兴趣的库:
无论如何,如果有任何令人痛心的显而易见的事情,我很想听听,因为我在网上关注的所有内容以及其他堆栈溢出问题与我们所面临的问题之间的联系不够密切。