[Orca-users] Orca is eating up both my CPUs.

[Sean O'Neill]

At 02:21 PM 11/8/2002 -1000, Camron W. Fox wrote:
>Alle,
>
>         We've been running orca in daemon mode for around two days now 
> and it has
>sustained this CPU usage level almost constantly.

Good, that means Orca is working hard and your hardware is earning its keep 
- seriously - Orca is a /very/ compute intensive application.  I don't have 
81 systems but I do have close to 30 on a Ultra 5.  That U5 is 100% 
utilized 24 hours day nonstop doing nothing but Orca crunching and I live 
with it.  The only "issue" with your Orca machine being pegged (and your 
doesn't appear bad at all) is your graphs aren't updated as often as you 
would like them to be.

You should start getting worried when your system is truly 100% utilized 
and your graphs are 30+ minutes behind being updated.  Actually you may 
even live with this.  The graphs only tell one part of the story.  The text 
data is still available if you need to do quick diagnosis.  You just need 
to learn how to use orcallator_column.

>CPU0 states: 54.1% user,  3.1% system,  0.0% nice, 42.2% idle
>CPU1 states: 48.0% user,  4.3% system,  0.0% nice, 47.1% idle
>Mem:   772200K av,  729748K used,   42452K free,       0K shrd,   30772K
>buff
>Swap:  530136K av,   52640K used,  477496K free                  471440K
>cached

 From your stats above, you have all kinds of head left - I WISH I had this 
much idle time on my Orca computer servers.  This is nothing to complain 
about.  You might even consider running setiathome just to use up the 
remaining idle time on your system or some other worthy compute-charity-ware.


>         We have been receiving the alot of the following types of errors 
> for all
>systems from /var/log/orca:
>
>/usr/local/bin/orca: number of columns in line 130 of
>`/usr/local/var/orca/orcallator/g21/orcallator-2002-09-24-000' does not
>match column description.

Not sure what this is.  I've never seen this before.  You didn't mention 
which Orca version you are running.  You running 0.27b2 ?  Maybe you need 
to upgrade.

>         Both of these I'm sure are because of the rsync we have to run to 
> get the
>data from the customer's machines on to our server (an ssh rsync job) and
>the info conflicts with the state file, but is there any way to avoid it?

This isn't because of rsync - I'm pretty sure anyway.  On rsync systems, 
just be sure your clocks on the Orca and remote systems are closely in sync.

To stop the email, edit orcallator.cfg and change this:

warn_email             root at localhost

to this:

#warn_email             root at localhost

Restart the orca after making this change.  These emails will stop.


>         We'd like to keep running orca, but it continues to use more and more
>computing resources, making it unfeasible to do so.

Like I said above, you have lots of headroom left.  Just because a system 
is 100% utilized (which your data doesn't represent) doesn't necessarily 
mean you have a problem.  In many environment, any amount of idle time 
means you have bottlenecks in the architecture.  Your data indicates you 
still have basically one "virtual" CPU sitting there doing nothing.


--
........................................................
......... ..- -. .. -..- .-. ..- .-.. . ... ............
.-- .. -. -... .-.. --- .-- ... -.. .-. --- --- .-.. ...

Sean O'Neill