On Fri, Nov 13, 2015 at 04:57:07PM +0100, 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? I'm proposing to turn it on, and gather statistics ;)
> (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.) Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
