Renaud Métrich d63cb99649 Changed log lock from 'quick' to 'basic' because this is an I/O lock.
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.
2019-11-26 16:32:07 +01:00
2019-11-22 14:30:56 +01:00
2018-10-22 10:19:30 +00:00
2018-12-03 11:24:51 +00:00
2019-05-01 13:39:32 +02:00
2012-02-10 10:34:15 +00:00
2019-09-19 09:55:23 +02:00

Unbound

Travis Build Status Packaging status Fuzzing Status

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. Dont 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.

S
Description
No description provided
Readme BSD-3-Clause
135 MiB
Languages
C 83.7%
Shell 6.1%
M4 2.4%
Makefile 2%
Yacc 1.8%
Other 4%