-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Beam VM becomes stucked when the number of connections is high #119
Comments
I am currently in the process of a major rewrite (admittedly it has been going on for a long while), which will bring MQTT 5 support to Tortoise. I hace recently picked up development again, and wrapping my head around what is needed to make it a release candidate, but the architecture differ, so I hope you will let me release that, and then loom at this issue ? And thanks for using Tortoise; spawning 300 tortoises on a single node is not a use-case I anticipated :) |
It's great to hear that you are planning to further develop Tortoise! Maybe the problem will go away after the rewrite? Thanks, I will keep an eye on the project development.
It sounds a big unusual but that's what is need to simulate IoT devices for my team. |
Forgot this information: most of the schedulers processes states were in the same calls when generated a dump (from the original problem, I did not generate a dump of the example):
|
Oh; I have a registry I use as a pubsub, such that processes can subscribe to a tcp socket—I move the tcp socket to the process that will send a QoS=0 message. Could be because the registry gets overwhelmed when too many tortoises are running. …an interesting case. I will look further into this at a later time. |
Maybe related to https://github.com/pallix/veth_network_namespaces_perf |
I have an application that connects to multiple MQTT servers, each running locally in its network namespaces. When the number of connection is too high the beam vm becomes stuck. I have written an example project by extracting code from our codebase and wrote a README to reproduce the problem. You can find it here. I would be happy if you can find the time to try it and tell me if you can reproduce the problem.
I am using Debian 9 (stretch), Elixir 1.8.2 and Erlang/OTP 21.3.8.8.
And thanks for writing this software :-).
P.S: I was once lucky enough to have the observer print a few more graphs before being completely overloaded:
This is surprising because the rate of creation for the network namespace and start of the mosquitto servers is approx one per second.
The text was updated successfully, but these errors were encountered: