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 <lennart@xxxxxxxxxxxxxx> wrote:
On Mi, 03.02.21 12:16, P.R.Dinesh (pr.dinesh@xxxxxxxxx) 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
P R Dinesh
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
