Issue #12310 has been updated by Daniel Pittman.
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. ---------------------------------------- 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.
