-
Notifications
You must be signed in to change notification settings - Fork 20
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
Crash and burn during performance test #27
Comments
[ Quoting <[email protected]> in "[coredns/unbound] Crash and burn du..." ]
I did performance testing on CoreDNS with Unbound DNS Recursion support
yesterday evening, and im gutted 🙁
The test goes fine up until ~100 queries pr. second and then the CPU usage
spins out of control to 100% and hundreds og CoreDNS processes spawn in some
kind of loop until the entire thing crashes in a panic condition.
I ran the test on current master with dnsperf and standard query file. First in
a build with Unbound2 on Debian Stretch, then with Unbound8 on Debian Buster to
the same result.
hmm :sadface: I won't have time to debug. If I would guess it's OOMing because with cgo
each goroutine takes 2MB instead of 2KB of memory
|
As input here, the VM's i tried this on has 24GB available to them - and was not using up that memory at all. |
I have the same issue too. СoreDNS + unbound suddenly start to consume all the cpu-s. Also I see increased memory, threads, go routine and file descriptors consumption. After that my vm stops to respond on healthchecks and then it is rebooted. |
[ Quoting ***@***.***> in "Re: [coredns/unbound] Crash and bur..." ]
I have the same issue too. СoreDNS + unbound + cache suddenly start to consume
all the cpu-s. Also I see increased memory, threads, go routine and file
descriptors consumption. After that my vm stops to respond on healthchecks and
then it is rebooted.
as, said previously, happy to merge something that fixes this, but don't look at me.
|
I did performance testing on CoreDNS with Unbound DNS Recursion support yesterday evening, and im gutted 🙁
The test goes fine up until ~100 queries pr. second and then the CPU usage spins out of control to 100% and hundreds og CoreDNS processes spawn in some kind of loop until the entire thing crashes in a panic condition.
I ran the test on current master with dnsperf and standard query file. First in a build with Unbound2 on Debian Stretch, then with Unbound8 on Debian Buster to the same result.
The text was updated successfully, but these errors were encountered: