Closed vinioliveira closed 6 months ago
@vinioliveira when you say huge, I wonder, how many workers are you using? Is this using BullMQ Pro or Bull? you can just spawn one connection and reuse that one with your workers, although every worker will need one extra dedicated connection.
nder, how many workers a
@manast Thanks for your prompt reply.
Currently, we have about 20 Queues on a single instance that spawns 60+ connections; in our prod environment, we currently have almost 40 instances that handle different queues. Which gives a total of 2.5k + connections.
We are using
"@taskforcesh/bullmq-pro": "^5.3.5",
"@taskforcesh/nestjs-bullmq-pro": "^1.1.0",
I couldn't find how to pass the connection using the decorators. I'm not entertaining the idea of moving workers out of the containers since injecting dependencies and whatnot is a bit more work. Still, if there's no other way, this is probably what we will have to do. I just wanted to check if there is anything else we can do before going down that road.
2.5k connections with the number of instances tells me you are probably instantiating queues and workers and not closing them properly, there is no other way you would reach those amounts otherwise.
Well, the math checks out for the single instance: 3 connections per queue, 20 queues 1 app instance 20 queues 3 connections = 60 40 instances * 60 connections per instance = 2.4K
I'm AFK now, but I'll send the repo reproducing that later.
Meanwhile, here’s how we have things set up.
QueueModule
ProcessorModule
hi @vinioliveira, did you try to pass a factory as a config?
BullModule.forRootAsync({
useFactory: () => ({
connection: yourClientInstance,
}),
});
Here's the repo https://github.com/vinioliveira/nestjs-bull-redis-conns
Thanks, @roggervalf. That has helped to decrease the number of connections. When passing the connection as you described, it does not create connections for every queue registered through BullModule.registerQueue
, which is great. So now, it only creates extra connections per worker created.
The repo has both approaches implemented, and the one sharing the connections is commented out.
Based on what I've seen and @manast's comment about workers getting a dedicated connection, I think this is the best I can get. Please feel free to close this issue if that's the case.
Hello!
We have noticed a huge number of connections used by Bull; after digging into it a bit, we found out that there's no way to prevent that since a new connection is spawned when we create a worker if not pass one connection, which is the case for the decorators we use for nestjs.
The question is, what are the alternatives to preventing that many connections? We are currently running Heroku Redis, which limits the number of allowed connections. We couldn't find a way to share connections while using decorator.