Issue #12310 has been updated by Brice Figureau.
Daniel Pittman wrote: > Brice Figureau wrote: > > Daniel Pittman wrote: > > > Brice Figureau wrote: > > > > We concluded with RI that having this thread doing nothing is what > > > > causes the general slow-down of the whole process. > > > > As RI mentioned, it's possible that it is dependent on his ruby version > > > > or even compilation options (as was the case in lenny shipped ruby back > > > > a couple of years ago). > > > > > > > > I'll try to come with a patch that defers the creation of the thread to > > > > when the listener is really used. A work-around is to completely remove > > > > the process_name.rb file, thus this way it won't be loaded. > > > > > > This may be a question answered by reading the code, but call me lazy: is > > > there an actual need for the extra thread? Changing `$0` should be > > > pretty fast, and doing it from the main "thread" should have the same or > > > lower cost to doing it in another "thread" - because Ruby is all green > > > threads, so you have a context switch cost, but no actual parallel > > > operation going on. > > > > > > If you did this to rate-limit changes or something, just inline that in > > > the method that handles the "state change" notification and do nothing > > > when updates are too frequent. :) > > > > No this is a scheduled timer to rotate long process names (like a stock > > ticker). So rotating only when there's a new event wouldn't rotate it when > > nothing happens. But maybe there can be some other means to have such > > regular timer that wouldn't consume a thread. > > Hrm. I don't know I consider that a compelling feature, personally, so > losing the thread doesn't feel to me like a big cost and all. Note that this listener was just an example listener for other people to create their own, it shouldn't have even been used normally. Exactly. But we can do better, puppet embeds the event-loop which contains exactly what is needed but without using any threads. ---------------------------------------- Bug #12310: Significant slow down in 2.7.10 apply https://projects.puppetlabs.com/issues/12310 Author: R.I. Pienaar Status: Code Insufficient Priority: Normal Assignee: Patrick Carlisle Category: Target version: 2.7.x Affected Puppet version: 2.7.10 Keywords: Branch: https://github.com/pcarlisle/puppet/tree/ticket/2.7.x/12310-puppet-apply-fact-loading I've been exploring approaches for running puppet masterless and in the same time trying to massage my manifests to be compatible with 2.7.x scoping etc. I noticed a huge increase in run times between 2.6.9 and 2.7.10 with the same manifests, using envpuppet and a git clone I've gathered this information: <pre> ======== 2.6.9 notice: Finished catalog run in 9.95 seconds envpuppet puppet apply --pluginsync 14.45s user 4.99s system 92% cpu 21.098 total ======== 2.7.9 notice: Finished catalog run in 16.52 seconds envpuppet puppet apply --pluginsync 21.92s user 6.90s system 93% cpu 30.814 total ======== 2.7.10 notice: Finished catalog run in 21.34 seconds envpuppet puppet apply --pluginsync 23.58s user 9.42s system 73% cpu 44.662 total </pre> 2.7.0 to 2.7.9 performs the same. While 2.7.0-9 is already a fair bit slower than 2.6 was 2.7.10 adds another 14 seconds to the run using the same manifests on the same machine. Comparing last_run_summary.yaml files I notice that the big change in run time info is service: <pre> 2.6.9: service: 2.920294 2.7.9: service: 8.238562 2.7.10: service: 12.400952 </pre> But this does not on it's own account for the time increase there seems to be a hit somewhere like state.yaml handling or report handling or something that isn't reflected here. Unsure how to gather more useful information to narrow this down -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
