I have a scenario, were many clients are connecting in a short period. As soon as the CPU usage of the broker reaches 100%, its memory usage starts to increase significantly. And the memory is never released, even after all clients connected successfully. When delaying the connection attempts of the clients, so that the CPU usage of the broker process stays below 100%, the memory usage is much lower (which seems to be the normal amount, needed to handle the connections).
After starting the broker, it's memory consumption is 0.3%
When connecting 10000 clients with a rate of 10 clients per second, the final memory consumption (after all clients are successfully connected) is 7%. This seems to be the required amount to manage the connected clients.
When connecting the same amount of clients with a rate of 100 clients per second, the CPU load reaches 100% (for a short period, during the connection process). In this case the final memory consumption is 21% (3 times more).
In order to mitigate this, a system with large number of clients would need to implement mechanisms to limit the rate of connection attempts under all circumstances, which is not always trivial.
Used setup:
Number of clients: 10000
Broker version: tested with 2.0.11 and 2.0.15
Machine used for the broker:
Steps to reproduce:
1) Start a broker on one machine with the attached config. It's easier to reproduce on smaller CPUs
2) Start the clients on another machine with the attached script. The other machine should be powerful enough to handle 10000 clients ;-)
Before starting the clients:
After starting 10000 clients with a rate of 10 per second:
After starting 10000 clients with a rate of 100 per second:
I have a scenario, were many clients are connecting in a short period. As soon as the CPU usage of the broker reaches 100%, its memory usage starts to increase significantly. And the memory is never released, even after all clients connected successfully. When delaying the connection attempts of the clients, so that the CPU usage of the broker process stays below 100%, the memory usage is much lower (which seems to be the normal amount, needed to handle the connections).
After starting the broker, it's memory consumption is 0.3% When connecting 10000 clients with a rate of 10 clients per second, the final memory consumption (after all clients are successfully connected) is 7%. This seems to be the required amount to manage the connected clients. When connecting the same amount of clients with a rate of 100 clients per second, the CPU load reaches 100% (for a short period, during the connection process). In this case the final memory consumption is 21% (3 times more).
In order to mitigate this, a system with large number of clients would need to implement mechanisms to limit the rate of connection attempts under all circumstances, which is not always trivial.
Used setup: Number of clients: 10000 Broker version: tested with 2.0.11 and 2.0.15 Machine used for the broker:
Broker config: mosquitto.conf.txt
Clients started with: startMqttClients.sh.txt
Steps to reproduce: 1) Start a broker on one machine with the attached config. It's easier to reproduce on smaller CPUs 2) Start the clients on another machine with the attached script. The other machine should be powerful enough to handle 10000 clients ;-)
Before starting the clients:
After starting 10000 clients with a rate of 10 per second:
After starting 10000 clients with a rate of 100 per second: