d63cb99649
We cannot use a 'quick' lock (i.e. lock spinning on the CPU) for the log lock because it can wait a lot on I/Os. Using a 'quick' lock leads to eating the CPU for no good reason. Example of 'pidstat' output when using various locks for log_lock: - 'quick' lock and slow log file system (tail -f on the log file on XFS on RHEL 8) 04:15:11 PM UID TGID TID %usr %system %CPU CPU Command 04:15:21 PM 998 16431 - 100.00 4.20 100.00 2 unbound 04:15:21 PM 998 - 16431 31.00 1.00 32.00 2 |__unbound 04:15:21 PM 998 - 16432 31.30 0.80 32.10 0 |__unbound 04:15:21 PM 998 - 16433 30.20 1.40 31.60 1 |__unbound 04:15:21 PM 998 - 16434 30.70 1.00 31.70 3 |__unbound - 'quick' lock and log file system being fast 04:15:40 PM UID TGID TID %usr %system %CPU CPU Command 04:15:50 PM 998 16431 - 10.00 1.60 11.60 1 unbound 04:15:50 PM 998 - 16431 2.50 0.50 3.00 1 |__unbound 04:15:50 PM 998 - 16432 2.30 0.40 2.70 3 |__unbound 04:15:50 PM 998 - 16433 2.70 0.30 3.00 0 |__unbound 04:15:50 PM 998 - 16434 2.60 0.40 3.00 2 |__unbound - 'basic' lock (this commit) and slow log file system (tail -f on the log file on XFS on RHEL 8) 04:29:48 PM UID TGID TID %usr %system %CPU CPU Command 04:29:58 PM 998 11632 - 7.10 14.10 21.20 3 unbound 04:29:58 PM 998 - 11632 1.70 3.20 4.90 3 |__unbound 04:29:58 PM 998 - 11633 1.60 3.30 4.90 1 |__unbound 04:29:58 PM 998 - 11634 2.00 4.10 6.10 1 |__unbound 04:29:58 PM 998 - 11635 1.90 3.50 5.40 1 |__unbound We can see in the above example, when 'basic' lock is used, that CPU isn't consumed when log file system is slow. Another reproducer scenario: put the log file on a NFS share with 'sync' option. |
||
|---|---|---|
| cachedb | ||
| compat | ||
| contrib | ||
| daemon | ||
| dns64 | ||
| dnscrypt | ||
| dnstap | ||
| doc | ||
| edns-subnet | ||
| ipsecmod | ||
| ipset | ||
| iterator | ||
| libunbound | ||
| pythonmod | ||
| respip | ||
| services | ||
| sldns | ||
| smallapp | ||
| testcode | ||
| testdata | ||
| util | ||
| validator | ||
| winrc | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| ac_pkg_swig.m4 | ||
| aclocal.m4 | ||
| acx_nlnetlabs.m4 | ||
| acx_python.m4 | ||
| ax_pthread.m4 | ||
| config.guess | ||
| config.h.in | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| install-sh | ||
| LICENSE | ||
| ltmain.sh | ||
| makedist.sh | ||
| Makefile.in | ||
| README | ||
| README.md | ||
| systemd.m4 | ||
Unbound
Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. If you have any feedback, we would love to hear from you. Don’t hesitate to create an issue on Github or post a message on the Unbound mailing list. You can lean more about Unbound by reading our documentation.
Compiling
Make sure you have the C toolchain, OpenSSL and its include files, and libexpat installed. Unbound can be compiled and installed using:
./configure && make && make install
You can use libevent if you want. libevent is useful when using many (10000) outgoing ports. By default max 256 ports are opened at the same time and the builtin alternative is equally capable and a little faster.
Use the --with-libevent=dir configure option to compile Unbound with libevent
support.
Unbound configuration
All of Unbound's configuration options are described in the man pages, which will be installed and are available on the Unbound documentation page.
An example configuration file is located in doc/example.conf.