-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
Memory leak in go-dnscollector #810
Comments
Thank you for this type of feedback, it helps improve the tool. Here are a few points to investigate:
|
Ok, will test. |
Er, how does one run a Go profiling? |
It looks like making those changes has sharply curtailed the memory usage; it's now about 125-148MB, although it goes up and down. |
At the moment, each dnsdist frontend is taking 5.7-6.6% of CPU, while each dnscollector backend is taking 3.0-3.7%. With 10 of each, that adds up to a lot. Is there a way to increase the number of dnscollector threads, so I don't need to run ten copies? |
Running 10 dnsdists and dnscollectors uses 3.89GB (12%), so setting buffers to 4096 and commenting out the transforms really helped. Having only 5 dnsdists and dnscollectors changed the CPU numbers a bit:
Since the results are so close, I'll have to check the logs for discards and other warnings to see what to do next. Thanks! |
Oh, there are definitely errors:
|
Partial output of
Given that dnsdist is sending 8000KB/sec of dnstap logs to dnscollector, and dnscollector is sending 10KB/sec of logs to filebeat, I'm thinking that filebeat is not accepting the logs fast enough, by a factor of about 800. And if dnstap is binary and the logs sent to filebeat are json, that factor is even bigger on a per-packet basis. |
The JSON format can be resource-intensive. You can review a benchmark. As you can see, the basic text inline format is the most efficient in terms of CPU usage.
Goroutines are used for each incoming connection, so you can use a single binary and listen on multiple ports simultaneously, effectively handling multiple streams within the same instance.
Currently, no. You can use the DNStap profixier to duplicate the data flow, but it does not support splitting streams across multiple collectors. Feel free to open a feature request to track this enhancement. |
Describe the bug
As we use go-dnscollector, it uses more and more memory until it's killed by the OOM killer.
We initially added
LimitDATA=5500M
and laterMemoryMax=1500M
to the systemd service unit file.Then we graphed MemoryCurrent over time:
The process ran out of memory after 45 seconds.
To Reproduce
We have 10 copies of dnsdist running, each sending dnstap logs to a separate copy of dnscollector.
Excerpt from
/etc/dnsdist/dnsdist-backend1.conf
:Contents of
/etc/dnscollector/config-backend1.yml
:The reason we have 10 copies of dnsdist + dnscollector is because dnsdist started discarding dnstap records under high load, as dnscollector wasn't keeping up. If we could have configured dnscollector to start ten threads, or dnsdist to send dnstap records to ten different backends, we would have. The goal is to handle 200k DNS requests per second, which ends up being 400k records per second.
Expected behavior
No memory leaking. I can't imagine what dnscollector could be retaining records for apart from latency calculations, and those expire after 2 seconds.
Additional context
bacdb535927b96f4c1fde0b753ba55f0189c2199
plus one patch:The text was updated successfully, but these errors were encountered: