On Sat, Mar 21, 2015 at 12:08:07PM -0700, Robert Inder wrote:
>    On Friday, 20 March 2015 08:18:15 UTC, jamese wrote:
> 
>      Try running puppet with "--debug" and "--evaltrace" to see where it's
>      taking the time.
> 
>    Ah!  As before, the evaltrace for the empty node definition lists a
>    handful of things
>    being evaluated in negligible times.
> 
>    But that out put is bracketed by debug info.  It is preceded by...
> 
>        Debug: Loaded state in 40.54 seconds
>        Debug: Loaded state in 90.30 seconds
> 
>    And followed by
> 
>       Debug: Stored state in 130.67 seconds
>       Notice: Finished catalog run in 224.24 seconds
> 
>    So the time appears to be going on loading and saving "State". 
> 
>    So I look.  And I find the answer.
> 
>    Our server is running applications written in Perl, using Catalyst.
>    Those applications track user sessions.in files created below a "sessions"
>    directory.
>    We have configured Puppet to Tidy the sessions directories, by removing
>    files over 3 days old.
>    Currently, we have something like 1200 files in the "sessions" directory
>    tree.  A few hundred sessions per day.  Plausible.
> 
>    /var/lib/puppet/state/state.yaml has four hundred thousand lines related
>    to these session files.
> 
>    So in its state file, Puppet is keeping a record of every session file it
>    has ever deleted. 
>    It looks like every time it starts, it reads them all in.  And every time
>    it finishes, it writes them all back out again,
>    even though they don't exist.
> 
>    If I remove the "state" directory, puppet processes the empty node in "no
>    time at all"
> 
>    FFS!
> 
>    This is not quite the behaviour I want.
> 
>    But how can I stop it?

In your place I'd probably just purge stale sessions with a cron job. Any 
particular reason why puppet's tidy is better than find->rm?

>    --
>    You received this message because you are subscribed to the Google Groups
>    "Puppet Users" group.
>    To unsubscribe from this group and stop receiving emails from it, send an
>    email to [1]puppet-users+unsubscr...@googlegroups.com.
>    To view this discussion on the web visit
>    
> [2]https://groups.google.com/d/msgid/puppet-users/154122c1-d228-4de6-82db-d1df8fe1bd9c%40googlegroups.com.
>    For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>    Visible links
>    1. mailto:puppet-users+unsubscr...@googlegroups.com
>    2. 
> https://groups.google.com/d/msgid/puppet-users/154122c1-d228-4de6-82db-d1df8fe1bd9c%40googlegroups.com?utm_medium=email&utm_source=footer
>    3. https://groups.google.com/d/optout

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20150321220819.GA30516%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Reply via email to