Issue #12310 has been updated by Brice Figureau.
Daniel Pittman wrote: > Brice Figureau wrote: > > Daniel Pittman wrote: > > > Brice Figureau wrote: > > > > 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. > > Huh. I would think the process name was the most likely listener to benefit > our users - like PostgreSQL, being able to get a summary of state with `ps > -ef` or `ps axwww` is a big win to knowing what is going on. Yes, that's true. > > Exactly. But we can do better, puppet embeds the event-loop which contains > > exactly what is needed but without using any threads. > > Given the one use of that, we were looking to strip that out, actually. > Almost everything (like listen mode) just uses a background thread, and it is > a heavy bit of code to carry just to check if the config changed every 15 > seconds, and to wake up when configured in daemon mode. Adding more > consumers isn't really high on the agenda, and I don't think we return to the > event loop regularly except when the daemonized agent is idle. I can see plenty of advantages of having a real timer. But I understand your point of view. I'll see how I can fix the original bug later on (too bad for me as I had the EL one almost ready :) ---------------------------------------- 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.
