[systemd-devel] RFC: Setting TasksMax= by default

[Alexander E. Patrakov]

13.11.2015 20:57, Lennart Poettering wrote:
> On Fri, 13.11.15 14:27, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>
>>> b) I'd like to introduce DefaultTasksMax= that controls the default
>>>     value of the per-unit TasksMax= by default, and would like it to
>>>     set to some value such 1024 out-of-the-box. This will mean that any
>>>     service or scope created will by default be limited to 1024
>>>     tasks. This of course is a change from before that has the
>>>     potential to break some daemons that maintain an excessive number
>>>     of processes or threads. However, I think it's a much better choice
>>>     to raise the limit for them, rather than stay unlimited for all
>>>     services by default. I think 1024 is not particularly low, but also
>>>     not particularly high. Note that the kernel by default limits the
>>>     number of processes to 32K in total anyway.
>> Shouldn't it be lower than 1024? For services which have many tasks,
>> 1024 will not be enough, but for 99.9% of services it will be two
>> orders of magnitude too many. I guess we can start with those
>> settings, and the controller turned on, and then maybe readjust based
>> on real-world usage.
>
> What are you proposing? 256? 512?
>
> (For comparison: if I read the docs right, then Apache defaults to
> something between 256 and 400 max workers by default, depending on the
> MPM you pick. If that's a good benchmark, then we should probably not
> set our own max to anything below 512.)

I'd rather not set any default based on Apache. On the contrary, I'd 
rather force it to be an exception that visibly (for the sysadmin) 
requires adjusting the limits in the unit file (in other words, has a 
TasksMax= line with a comment that it has to be changed together with 
ServerLimit), as it creates one thread or process per connection.

-- 
Alexander E. Patrakov