[Unbound-users] Issues with Unbound 1.4.18
Phil Davies
phil at enta.net
Fri Aug 31 11:45:24 UTC 2012
On 31/08/2012 08:50, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Phil,
>
> On 08/31/2012 09:28 AM, Phil Davies wrote:
>> Hi,
>>
>> I have 6 DNS caching Resolvers serving many thousands queries.
>> Until recently all 6 were running Bind. As i've heard such great
>> things about Unbound I decided to switch 3 of them to Unbound. So
>> i've installed the latest Unbound 1.4.18 with Libevent and at first
>> things seemed good but i've noticed at least 4 times a day Unbound
>> is crashing with:
>>
>> kernel: pid 82301 (unbound), uid 59: exited on signal 11
>>
>> I have a script that automatically restarts programs that should
>> be running, so I didn't notice at first. I've tried tweaking loads
>> of config options but nothing seems to make a difference. The
>> servers aren't exactly that High spec:
>>
>> FreeBSD 8.3 Dual Core CPU 4G Ram
>>
>> However with Bind running the server is stable and if anything Bind
>> uses a lot more CPU than Unbound for the same task. Can someone
>> give me some idea's on what I can do to find out whats causing it
>> to crash.
> Get it to store coredumps. Compile with debuginfo (-g option to gcc,
> enabled by default I believe). Store coredump with a ulimit statement
> before you start the daemon to allow coredumps; I think it ends up in
> the working directory. Then use gdb executable coredump; bt for stack
> backtrace. (coredump without executable is not workable for me, I
> would rather have the stack backtrace than the coredump itself).
>
> A quick question, some people have ulimit set up to limit memory size
> (heap size), and then configure unbound to use, e.g., XGb memory.
> Does this seem the case? (this seems more common on BSDs) (if its out
> of memory unbound should still not segv, but print errors).
>
> If the above fails, tcpdump to capture the packets at the time of crash.
>
> If you compile with assertions enabled (debug-mode), then you might
> get an assertion failure (and what line number it crashed on), and not
> sigsegv. Assertions are fairly cheap in performance terms.
>
> The worst option for performance is to enable verbosity (level 4 or
> so), it would likely slow down your system so that it could not handle
> your incoming traffic any longer. Produce Gbs of logfile. More
> useful if you can trigger the error yourself (thus keep logfile short).
>
> Best regards,
> Wouter
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQQGzUAAoJEJ9vHC1+BF+NrbwQALDAtnaxd2K3KrhykhISGl4v
> IR0bXDVB0o1F3UYJdiAl89OQG0SCQLEeltqA6UuKVRCeWSYUydc+k2qViDhcLj7n
> ieJWz/wz35UOUFbUsrhAUGKEa2CaZ9QJzTeF6d9qL+uLsNzSa69bf6kxSdgmUl62
> mVSZnKH3r7UCx9s9bMUJmSIG+Pxf7css9kW9UFe4vjRJxSekIGWR75MXBszkIlBM
> DO1MDbPhfJniSYfM6iI3FVQL97lLXvOdA5ahry6ZpCgXlMMMGL2UmD8TDMp/L4R4
> WzlDnAZcJqZt4G7wZRJrZtoDfgcR9nAf4+7tFN2oWAuxJMnsJm+GpSXKGD6oVTj2
> yG5pxUzlsgFUDaH5u2/nvWZie3r4KBLBqyLoFJ5ulJqBk6Bp57mIN6HXoYYMowXB
> 5e/sI0KCp0w/0WUg3JX8t4Tg/5QvHFWC+YNLo/e+JmVIAnb6HK0aisEmmFDhTqCA
> gAdn82xgKtt9jM3H3qqQvd2UxHOXuHALFk+I6TrMtfIOvajlZqcafTUOgZyUtctx
> yrfLGBc0eWwAYW18LnBZb+PxWUvIIvt2O9sVoj2Y5zmDCr38nKtMLNA/PctbWIbH
> tTdvlUqWEV2D7Uyx0NJjJkk+OVNkQRNgxDLee6fI+7CBWjM9yUkIR2KWqcWo7KWT
> S8gxanTgp2qELNO3hIWJ
> =ClQT
> -----END PGP SIGNATURE-----
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at unbound.net
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
Hi Wouter,
Thanks for the advice , I've recompiled unbound with debug enabled, So
I'll wait until the next crash and see if I get any extra information.
In terms of load these servers are doing about 1400 queries per second
and when they are running handle this with about 10-15% CPU. As for
ulimit I haven't changed any defaults.
Regards
Phil
More information about the Unbound-users
mailing list