Thank you very much Lennart for the help. I was eager to know whether there was any known limitation, hence this question.
Hi Andy, I am currently building a diagnostics data collector that collects various diagnostics data at different scheduled intervals as configured by the user. systemd-timer is used for running the schedules. I need to enforce a limit on the maximum number of schedules the user can use for this feature. Currently, I am deciding the limit, hence interested in the maximum value upto which we can allow the user to configure without creating much/noticeable performance impact. I will do a performance testing in raspberry pi 3 and share my observation. Thank you all for your support On Wed, Feb 3, 2021 at 9:35 PM Lennart Poettering <[email protected]> wrote: > On Mi, 03.02.21 12:16, P.R.Dinesh ([email protected]) wrote: > > > Do we have any limitation on the maximum number of systemd timers / units > > that can be active in the system? > > We currently enforce a limit of 128K units. This is controlled by > the MANAGER_MAX_NAMES define, which is hard compiled in. > > > Will it consume high cpu/memory if we configure 1000s of systemd timers? > > It will consume a bit of memory, but I'd guess it should scale OK. > > All scalability issues regarding number of units we saw many years > ago, by now all slow paths have been fixed I am aware of. I mean, we > can certainly still optimize stuff (i.e. "systemctl daemon-reload" is > expensive), but things to my knowledge having a few K of units should > be totally Ok. (But then again I don't run things like that myself, my > knowledge is purely based on feedback, or the recent lack thereof) > > Lennart > > -- > Lennart Poettering, Berlin > -- With Kind Regards, P R Dinesh
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
