[Orca-users] Re: Digest Number 244

[John Mastin]

> By databases do you mean the source input data files?  The source
> input data files are not reread if you run Orca with -o unless the
> last modified time Orca last stored in its state file for the
> particular input data file is different than the current last modified
> time.  Orca will also compare the file's inode to see if the file has
> changed.
>
Yes, what I meant was the raw data files (source input data files) as
they get put into the rrd databases.  I see this is where the orca.state
file comes into play.  It provides a pointer of what was last read into
the rrd databases.

> Sure.  But any help here would be great :)  The orcallator.se part
> shouldn't be hard, but modifing Orca would be harder.
>
Not sure how much help I can do personally (I'm a poor perl programmer!)
but I might have roped in another guy that might be able to help out.

Anyhow, we've found that our little Ultra 10 was pigged out.  First
mistake I made was putting the rrds, source input data files and the
html pages all on the same disk (ouch!).  While it worked good in the
beginning, it hurt me in the long run.  You know how it goes, "Hey this
is neat, let's put it here for now and if it goes big, we'll do it
right".  Well, we left it there and it grew. :-)  We split it up into 5
volumes.  Four volumes of grouped servers' source input data files, one
for rrds, and one for the software distribution/html pages.  This has
helped but now we're more memory and processor bound (single proc, 128MB
ram).  Second mistake I made was that after the filesystem went to 100%,
I zorched the rrds and the state files.  I figured I'd rebuild the rrds
from scratch (in case I had corrupted databases).  Well, it is taking a
while to sluff through all of the source input data files.

I found a couple of boxes that I might be able to bang on for this.  A
pair of Ultra 2's, 2 procs each and 1GB ram each.  Both of them share a
single A5000 (14 9GB disks).  This should be a better setup than a
single Ultra 10!  While I'd like to throw a E4500 at it, my boss would
probably nix it because of the cost (yet they figure it is important to
have the graphs.  Go figure...).  We plan on splitting production and
non-production servers onto the two boxes with separate volumes for the
disk intensive routines.  We'll see what we get with that.

Stay tuned!
Johnny
--
John Mastin, Jr.              email: john.mastin at bms.com
Bristol-Myers Squibb            phone: (609) 818-3788
PRI Infomatics              fax: (609) 818-7693
Princeton  NJ