13.11.2015 20:57, Lennart Poettering wrote:
On Fri, 13.11.15 14:27, Zbigniew Jędrzejewski-Szmek (zbys...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
