On Wednesday 24 Feb 2010 15:56:17 James Turnbull wrote:
> On 24/02/10 3:00 AM, Michael Gliwinski wrote:
> > I see your point, but this is perhaps specific to the domain of
> > configuration management systems? I mean just look at some of the
> > largest free software communities like KDE, which is
On Tue, Feb 23, 2010 at 11:38:29AM +0200, Ohad Levy wrote:
> On Tue, Feb 23, 2010 at 11:11 AM, Oliver Schad wrote:
> >
> >
> > Do you know process priorities? It's very easy to run puppet with this.
> > Most CPUs has so much idle times that puppet is not a problem. The RAM
> > usage could be a mor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/02/10 3:00 AM, Michael Gliwinski wrote:
> I see your point, but this is perhaps specific to the domain of configuration
> management systems? I mean just look at some of the largest free software
> communities like KDE, which is primarily writ
On Wed, Feb 24, 2010 at 6:00 AM, Michael Gliwinski
wrote:
> I see your point, but this is perhaps specific to the domain of configuration
> management systems? I mean just look at some of the largest free software
> communities like KDE, which is primarily written in C++ which doesn't seem to
> b
I see your point, but this is perhaps specific to the domain of
> configuration
> management systems? I mean just look at some of the largest free software
> communities like KDE, which is primarily written in C++ which doesn't seem
> to
> be in any way diminishing the number of contributors.
>
>
On Wednesday 24 Feb 2010 10:19:57 Nigel Kersten wrote:
> > You make it sound like it's impossible to write a well performing,
> > expressive and stable system in C/C++, etc. Surely you can't think that?
>
> I don't think that.
>
> What I do think is that something like Puppet that needs to abstr
Brice Figureau wrote:
It would be interesting in finding where (when?) the time is taken. I'm
wondering if it comes from the master or puppetd itself. Does running
with --debug gives more information.
Maybe it does. I do need to look into this sometime, but I won't have
the time for yet a cou
On Wed, Feb 24, 2010 at 1:59 AM, Michael Gliwinski
wrote:
> On Tuesday 23 Feb 2010 16:22:44 Lindsay Holmwood wrote:
>> Performance, expressiveness, stability. Pick two.
>>
>
> You make it sound like it's impossible to write a well performing, expressive
> and stable system in C/C++, etc. Surely y
On Tuesday 23 Feb 2010 16:22:44 Lindsay Holmwood wrote:
> Performance, expressiveness, stability. Pick two.
>
You make it sound like it's impossible to write a well performing, expressive
and stable system in C/C++, etc. Surely you can't think that?
I once had an idea of using puppet to also m
On Wed, 2010-02-24 at 01:10 +0100, Thomas Bellman wrote:
> Trevor Vaughan top-posted:
>
> > Just out of curiosity, do the ones that take longer happen to be 64 bit?
>
> Well, yes, they are indeed 64 bit (x86_64). But that doesn't
> distinguish them from the quicker ones. They are all running
>
Thanks everyone for their input. I'll press on with Puppet and if I
run into performance issues then I'll bring them up in this forum.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups
On Tue, Feb 23, 2010 at 6:23 PM, Disconnect wrote:
> ..or perhaps they used the native hosts type that exists to manage
> /etc/hosts entries?
Dooh, thank you. I wish I could remove the previous email to prevent
my own misunderstanding from spreading. I should go read the paper.
> On Tue, Feb 2
Trevor Vaughan top-posted:
Just out of curiosity, do the ones that take longer happen to be 64 bit?
Well, yes, they are indeed 64 bit (x86_64). But that doesn't
distinguish them from the quicker ones. They are all running
CentOS 5.4 for x86_64, and they all have identical quad-core
Opteron C
..or perhaps they used the native hosts type that exists to manage
/etc/hosts entries?
On Tue, Feb 23, 2010 at 5:55 PM, Jeff McCune wrote:
> On Tue, Feb 23, 2010 at 12:58 PM, tobyriddell
> wrote:
> > The result was either to add entries to /etc/hosts or to confirm the
> > contents of /etc/hosts
On Tue, Feb 23, 2010 at 12:58 PM, tobyriddell wrote:
> The result was either to add entries to /etc/hosts or to confirm the
> contents of /etc/hosts.
I haven't read the article, but from this piece of information I'm
_highly_ skeptical of the results having much to do with puppet
itself.
I very
Just out of curiosity, do the ones that take longer happen to be 64 bit?
Also, does using --tags do what you want in terms of testing speed?
Trevor
On Tue, Feb 23, 2010 at 3:43 PM, Thomas Bellman wrote:
> James Cammarata wrote:
>
>> Also, this doesn't seem to be CPU load, just time. It took pu
James Cammarata wrote:
Also, this doesn't seem to be CPU load, just time. It took puppet longer
to apply a manifest than CFengine, I'm assuming they made the same changes
on both systems and had both CFengine and puppet correct the same
differences. Wall clocks != higher load.
In my opinion,
On 23 February 2010 03:49, tobyriddell wrote:
>> Comparing CPU utilisation is like benchmarking cars by seeing how well
>> they float.
>
> Without wanting to appear flippant, perhaps I want a floating car :)
Then perhaps you should be looking for a boat?
Puppet's performance and scaling problems
On Tue, 23 Feb 2010 08:57:37 -0800 (PST), Tim Stoop
wrote:
> On 23 feb, 10:02, tobyriddell wrote:
>> From the results in the article, Puppet required between 10x and 56x
>> more CPU seconds.
>
> Out of curiosity, which part of puppet is causing this load? If it's
> the puppetmaster, well then,
> Also, this doesn't seem to be CPU load, just time. It took puppet longer
> to apply a manifest than CFengine, I'm assuming they made the same changes
> on both systems and had both CFengine and puppet correct the same
> differences. Wall clocks != higher load.
The difference was found to be in
> Out of curiosity, which part of puppet is causing this load? If it's
> the puppetmaster, well then, that shouldn't be a big problem. I'd
> recommend a dedicated puppetmaster in most setups anyway. Or when
> puppet is actually applying a whole manifest instead of just checking
> if things are set
On 23 feb, 10:02, tobyriddell wrote:
> From the results in the article, Puppet required between 10x and 56x
> more CPU seconds.
Out of curiosity, which part of puppet is causing this load? If it's
the puppetmaster, well then, that shouldn't be a big problem. I'd
recommend a dedicated puppetmast
On Tue, Feb 23, 2010 at 11:11 AM, Oliver Schad wrote:
>
>
> Do you know process priorities? It's very easy to run puppet with this.
> Most CPUs has so much idle times that puppet is not a problem. The RAM
> usage could be a more significant problem in smaller systems.
>
Using nice is not an option
Am Tuesday 23 February 2010 schrieb mir tobyriddell:
> > Comparing CPU utilisation is like benchmarking cars by seeing how
> > well they float.
>
> Without wanting to appear flippant, perhaps I want a floating car :)
>
> In my case I need a tool that *if* run during production hours will
> consum
> I'd have to see the article to know for sure if the CPU utilization
> difference is negligible, but having run puppet for several months now I
> have not seen any performance impact myself. Most systems have so may
> extra cores nowadays that aren't doing anything (especially in our case,
> runn
> Comparing CPU utilisation is like benchmarking cars by seeing how well
> they float.
Without wanting to appear flippant, perhaps I want a floating car :)
In my case I need a tool that *if* run during production hours will
consume very little CPU - we've got very stringent requirements for
appli
On Feb 22, 1:17 pm, Toby Riddell wrote:
> I received my copy of ;login (the Usenix magazine) today. There's an
> article* comparing CPU utilisation of Puppet and Cfengine. To
> abbreviate massively: Puppet requires much more CPU than Cfengine when
> both verifying and fixing configuration.
I had
27 matches
Mail list logo
