On Fri, Nov 13, 2015 at 02:49:39PM +0100, Lennart Poettering wrote: > Heya! > > So, I am tempted to make the following changes to systemd, and was > wondering about opinions about it: > > a) The first change is rather uncontroversial I presume: I'd like to > set DefaultTasksAccounting=yes in system.conf by default. This > means we get accounting of the number of tasks per unit enabled by > default. Effectively this turns on the "pids" cgroup controller for > all units. According to the cgroups folks this is OK as this > specific controller is not particularly costly. This means that by > default "systemctl status" will show a "Tasks: " line then, showing > the number of tasks in the service. cgtop will be more efficient, > too, then. > > 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.
> c) In logind.conf I intend to add a TasksMax= setting that sets the > number of tasks for user sessions, and overrides the systemd-wide > setting for user scopes. It would also be set out-of-the-box, and > default to something like 8K or so. (Note that this is very similar > to setting RLIMIT_NPROC via /etc/security/limits.conf, but has the > benefit of covering also suid binaries, being nicely queriable > via systemctl status and controllable during runtime via "systemctl > set-property" and so on) > > d) in systemd's own unit files we'll configure much lower settings by > default, since we know how many tasks they require. +4 Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
