[Orca-users] Re: Orca very heavy on CPU

[Blair Zajac]

David,

How much do you see the uncompress programs using CPU?  Orca will keep
some of these processes lying around on compressed files.

Or is Orca using a large amount of CPU?

Regarding using cron, you would add the -o command line option to Orca.
The current 0.26 Orca will reread each compressed data file upon every
restart of Orca.  The next version of Orca will not do this since it'll
cache the columns of data in the file.

Regards,
Blair

David Aitchison wrote:
> 
> Blair (all),
> 
> I have had Orca running continuously.  In fact it has been running
> continuously since July 21st (reliable).  This I assume would stop
> orca re-reading the data files constantly.
> 
> Any further thoughts on the data files being re-read?
> 
> The servers I monitor use orcallator.se, and so yes they do collect
> new data every 5 minutes.  To be honest I didn't look at the orca
> process over any extended period, but I watched it periodically with
> 'top', and it always seemed to be running.
> 
> When run with the -o option and two -v's, I get a run time of about
> 1m20s.
> 
> On a side issue, I am fond of cron, and would like to know the fix
> to allow Orca to run from cron without re-reading data files.  Any
> tips?
> 
> Thanks,
> 
> David.
> 
> David Aitchison
> David.Aitchison at abci.gov.au
> (02) 6243 5610       ---       0402 057671
> 
>   -----------------------------------------  ooOOoo  ----------------------------------------
> One of the greatest labour saving inventions of today is tomorrow.
>   -----------------------------------------  ooOOoo  ----------------------------------------
> 
> >>> Blair Zajac <blair at akamai.com> 11/01/00 03:43PM >>>
> A couple of questions:
> 
> 1) Do you leave Orca running continuously?  If you run Orca by cron then
>    it will reread each data file every time it starts up.  This bug
>    is currently fixed in my private Orca tree.
> 
> 2) Did you look at Orca over a period of time or just once?  There are
>    times when Orca will be extremely busy and at other times it won't
>    be busy at all, when its waiting for the input data files to be
>    updated with new data.
> 
>    If you leave Orca running by not using the -o command line option,
>    then Orca will sleep waiting for new data to appear in the data files
>    it is watching.  When using orcallator.se, it'll get the new data
>    every 5 minutes, so Orca will generate a load on the server.  With
>    only three machines, there may be times that Orca will be sleeping
>    waiting for more data.
> 
>    Run Orca with one or more -v command line options to see what it
>    is doing.
> 
> Regards,
> Blair
> 
> David Aitchison wrote:
> >
> > Hello,
> >
> > I have been running orcallator on a number of our servers for some
> > time, with Orca 0.26 running on a separate box with percol files
> > being read via NFS mounts.
> >
> > Since it has been working without a hitch, I had not looked at our
> > orca server in some time.  Today I finally had reason to connect to
> > this server, and found that Orca was using 94% of CPU time.
> >
> > The server is a Sun Ultra 5 (single 360MHz cpu), with nothing else
> > running on it except Orca and Apache (to serve the stats pages).
> > Would this kind of CPU utilization look reasonable for graphing stats
> > from 3 servers?
> >
> > What I did notice also was that Orca was forever uncompressing old
> > percol files.  This puzzled me, as I thought all percol files had
> > their contents placed in rrd files, and then compressed the percol
> > file for archive.
> >
> > Has anyone else seen the same behaviour (constant uncompressing)?
> > Perhaps it is normal, but to me it doesn't sound quite right.
> >
> > Any help would be great.
> >
> > David Aitchison
> > David.Aitchison at abci.gov.au
> > (02) 6243 5610       ---       0402 057671
> >
> >   -----------------------------------------  ooOOoo  ----------------------------------------
> > One of the greatest labour saving inventions of today is tomorrow.
> >   -----------------------------------------  ooOOoo  ----------------------------------------
> >
> > *******************************************************************
> > The information contained in this email and any files attached may
> > be confidential information to the intended recipient and may be
> > the subject of legal privilege or public interest immunity.
> >
> > If you are not the intended recipient, any use, disclosure or
> > copying is unauthorised.
> >
> > If you have received this document in error please telephone
> > +61 2 6243 5666.
> >
> > *******************************************************************
> > This footnote also confirms that this email message has been swept
> > by MIMEsweeper for the presence of computer viruses.
> > *******************************************************************
> >
> 
> *******************************************************************
> The information contained in this email and any files attached may
> be confidential information to the intended recipient and may be
> the subject of legal privilege or public interest immunity.
> 
> If you are not the intended recipient, any use, disclosure or
> copying is unauthorised.
> 
> If you have received this document in error please telephone
> +61 2 6243 5666.
> 
> *******************************************************************
> This footnote also confirms that this email message has been swept
> by MIMEsweeper for the presence of computer viruses.
> *******************************************************************
> 
> -------------------------- eGroups Sponsor -------------------------~-~>
> eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9699/13/_/804404/_/973056541/
> ---------------------------------------------------------------------_->