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
1.6.11 Memory Leak #1793
Comments
Actually, I think we may have solved it. one of the python scripts was sending as QOS=2 (paho) and was causing RAM to fill up and retain messages, fast... BTW, yes this was crashing mosquitto with out of ram errors within hours. Edit: This was in the config file which should have mitigated what happened, but it didnt: max_queued_bytes 1000 |
Can I just check what was happening? It's not quite clear whether there is a real problem. If you python script was sending retained messages (which the broker must store) to an infinite number of topics, then queueing limits would not help. If your python script was sending rapid qos 2 messages to a single topic, which many clients were subscribed to, then the queueing limits should absolutely have helped. Which situation were you in? |
Let me find out, I have to speak to another person who is operating the server. |
Thanks |
I tried pinging him, Hopefully he will get back with me soon. |
Here is info I got back:
|
This is the pythons cript that had to be modified: This is generally as-is, he mentioned that he modified the log output to go over a topic instead of a file. Thats it really. Edit: This is the modification that was done on line 92 of https://github.com/jpmens/mqtt-launcher/blob/master/mqtt-launcher.py This shouldnt have affected the broker. Also this python script is running on a different machine than the broker. The broker runs in its own VM. |
In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes #1793.
Security release. From the changelog: - In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes eclipse/mosquitto#1793 Changelog: https://mosquitto.org/blog/2020/08/version-1-6-12-released/ Signed-off-by: Karl Palsson <[email protected]>
This was extremely intermittent to reproduce, with seemingly identical runs sometimes succeeding and sometimes not. I'm quite certain this is fixed, but I'd still like your confirmation that you no longer see the problem. |
Security release. From the changelog: - In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes eclipse/mosquitto#1793 Changelog: https://mosquitto.org/blog/2020/08/version-1-6-12-released/ Signed-off-by: Karl Palsson <[email protected]>
I figured it was a "planets alignment" scenario. I will have him recompile and update the server, and try again. Thanks. |
Security release. From the changelog: - In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes eclipse/mosquitto#1793 Changelog: https://mosquitto.org/blog/2020/08/version-1-6-12-released/ Signed-off-by: Karl Palsson <[email protected]>
Security release. From the changelog: - In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes eclipse/mosquitto#1793 Changelog: https://mosquitto.org/blog/2020/08/version-1-6-12-released/ Signed-off-by: Karl Palsson <[email protected]>
Security release. From the changelog: - In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes eclipse/mosquitto#1793 Changelog: https://mosquitto.org/blog/2020/08/version-1-6-12-released/ Signed-off-by: Karl Palsson <[email protected]>
Security release. From the changelog: - In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed. Closes eclipse/mosquitto#1793 Changelog: https://mosquitto.org/blog/2020/08/version-1-6-12-released/ Signed-off-by: Karl Palsson <[email protected]>
Hi guys, I have a situation of memory leak while using mosquitto 2.0.14. Scenario: There is 1 hour forced network outage between the local mosquitto broker and the external mosquitto broker. Upon reconnection, the connection is established seamlessly. Outcome: There is intermittent loss of data from the mosquitto.db for the entire duration. Debugging logs trimmed analysis: Local broker's mosquitto.conf: tls_version tlsv1.2 persistence true include_dir /etc/mosquitto/conf.d connection external-mosquitto-bridge External mosquitto broker's .conf: tls_version tlsv1.2 persistence true include_dir /etc/mosquitto/conf.d max_queued_messages 0 How can I help you with more information? If not, how can I tweak my settings to make this thing fly? Thank you in advance. |
I am running into a severe memory leak, and I dont know why. Whether I am sending data through it or not, it still munches up RAM.
The more data I push through, the worse it is of course. but I checked for retained messages, and nothing comes up. So I am not sure where to go from here. tried deleting, recompiling/installing the broker with no change in behavior. Even tried removing and disabling the ACL we had implemented. We send about 1.3GB an hour on traffic on a normal day. (This equates to about 361.1KB/s)
Here is the ubuntu version we are running: This is running inside a VM on an unraid server.
After restarting the broker:
any ideas?
The text was updated successfully, but these errors were encountered: