Tuning unit file for medium sized setups

[paddg]

Short description

We would propose to introduce the TasksMax setting in the unit file. The default value of 512 seems too low, at least for our setup. In addition, if present in the unit file, people will be aware of it.

LimitNOFILE=4096 seems also a little bit low.

Our setup consists of 8 DNS backend servers. Each Server with 5 IPv4 and 5 IPv6 addresses. That means dnsdist has to deal with 80 backends. For this setup TasksMax=512 (default) was too low and dnsdist stopped working correctly. We saw many of these messages:

Error creating a TCP thread: Resource temporarily unavailable
Had an error accepting new webserver connection: Resource temporarily unavailable

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled and tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added regression tests
• added unit tests
• checked that this code was merged to master

[rgacogne]

Hi Winfried, thank you for this PR! The TasksMax increase was probably more needed because of the number of TCP threads (setMaxTCPClientThreads()) than because of the number of backends, but it seems like a good idea to increase TasksMax and LimitNOFILE anyway.

[rgacogne]

It looks like TasksMax was introduced in systemd 227, this might be an issue with some distributions.

[paddg]

Yes indeed, it came up here with SLES12-SP2

[pieterlexis]

We could have m4/systemd.m4 detect the version of systemd through pkg-config (e.g. PKG_CHECK_MODULES that sets an AM_CONDITIONAL) and add that line to the generated service file.

[paddg]

From SYSTEMD.UNIT(5)
"If systemd encounters an unknown option, it will write a warning log message but continue loading the unit."

[rgacogne]

Indeed:

Unknown lvalue 'TasksMax' in section 'Service'

[rgacogne]

https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#DefaultTasksMax= suggests than on recent distributions the default value is 4915. I don't think we should lower that value, so how about defaulting to 8192?

[paddg]

For our setup I can say, we started dnsdist a week ago and the number of tasks was at ~250. Afterwards it increases from time to time.

systemctl status dnsdist.service | grep Tasks
    Tasks: 247 (limit: 2048)

Now after a week it looks like this:

systemctl status dnsdist.service | grep Tasks
    Tasks: 1004 (limit: 2048)

I'm curious if that stops at some point.

[rgacogne]

I'm curious if that stops at some point.

We have three kinds of dynamically started threads:

• console threads, to handle console connections
• webserver threads, to handle HTTP requests
• TCP worker threads

The first two are unbounded but the number of TCP worker threads can only grow up to setMaxTCPClientThreads(). I should probably add some options to restrict the maximum number of console and webserver threads too.

[rgacogne]

Looks good, but if you don't mind I'd rather have TasksMax set to 8192 to prevent a possible regression on recent distributions :)

[paddg]

Yes that's fine, thanks!