I spent quite a bit of time refactoring standard_services to work better with systemd. https://groups.google.com/forum/#!topic/help-cfengine/2Vd7op97Tz4
We actually spend 95% + of our CPU time in policy in standard_services. I haven't had time to trace down where we're spinning at, but I'm guessing its probably the regex parsing with all of the process promises. With the implementation above, we probe systemd's state once, raise namespace classes, and then use those classes for the rest of execution. Basically, we only enter the policy once and use the cached raised classes from the first pass, instead of entering the policy a million times to re-evaluate process state. Its orders of magnitude more efficient. On Thu, Jun 23, 2016 at 6:28 PM, Nick Anderson <[email protected]> wrote: > The standard_services bundle is quite long and I find it a bit hard to > track all thats going on. > > I have been thinking that perhaps we should break it up into > implementation specific bundles which standard_services can call as it > does the classic services bundle. > > Pull request illustrating the idea for systemd: > https://github.com/cfengine/masterfiles/pull/754 > > Thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "dev-cfengine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dev-cfengine/576C6297.8070000%40cfenigne.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "dev-cfengine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dev-cfengine/CAPPY8H2h%3DiUm5YkkBjM_nDgN6Go4xyEDgD3N4gKzdjqiMC4RNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
