[Orca-users] Re: Rsync Interval

[Adam Levin]

On Thu, 14 Feb 2002, bias16 wrote:
> We have about 300 servers rsync'ing with central server every five
> minutes to match the polling interface in orcallator.  

We have about 60 servers here.  We have the central machine pull via
rsync every minute (for LAN) and every 4 minutes (for WAN -- it takes a
bit longer over the T1s).

> * Is there any harm in just syncing the data once and hour while
> maintaining the same polling interval?  

No harm at all.  Pull down new data whenever you want.  As long as Orca
knows the file is there, it'll update the graphs when it sees there's new
info in the file.

> I have noticed that orca graphs are 2-3 hours behind the current time
> anyway.  I also have cron to run orca on central server (creating
> html/graphs) every five minutes.  I would like to split up my server
> rsync times over an hour with one sync per system per hour.

The delay is probably a function of the time it takes to generate the
graphs.  First, I think it's faster to keep Orca running rather than
calling it in a cron job.  The data files that orcallator.se generates
(assuming you're on Solaris) are small (I imagine they're pretty small for
other systems as well).  It takes less than a minute to rsync 30-odd
servers over LAN speeds to our central repository.

Additionally, we happened to have an older server that wasn't doing
anything, so we put its CPUs to work as well.  We have an Enterprise 450
(4x400MHz CPU) doing the bulk of the Orca stuff, as well as other
functions.  We added an E250 (2x400MHz CPU), and with copious use of NFS,
we have both machines running Orca.  One machine handles the LAN machines,
which are dev/test/data warehouse, and the other machine handles the WAN
machines (production web/ftp/ecommerce app servers).  It's working out
very well, and the graphs update much faster because we've effectively
halved the work that Orca must do to process everything.

Naturally, not everybody can throw that much hardware behind Orca, but
when the Chief Weenie in the Sandbox wants performance stats, he gets
performance stats.  :)

> * Is there a distinct speed increase by not bothering to gzip2 these
> files?

It's certainly going to be faster to avoid unzipping.  I don't know as
much about bzip, but gzip unzips very quickly -- it's the zipping that
takes time.  Uncompressing is fast, and happens to a temporary space, so
Orca doesn't have to rezip after unzipping.

However, once the data is in the rrd files, I don't think Orca has to
re-read the old data files.  It might if you re-run Orca in cron, but if
you just keep Orca running as a daemon, it'll just keep going.

In the event that we've had to restart Orca, it takes 6-8 hours for it to
catch up.

> My central server is a T1400 with 2 450Mhz and 2 Gig memory.  It serve
> of lot of management functions and I'm looking to spread the load out
> of orca (as well as other things).  Orca, although niced, is really
> CPU intensive to gather data and make html/graphs.

Well, if you happen to have any extra servers lying around, I'll be glad
to detail how we set up Orca and NFS to effectively get a cluster of
machines working on the graphs.  300 machines' worth of info is a lot of
info to throw at 2 450MHz procs.

-Adam

Adam Levin, Senior Unix Systems Administrator | http://www.audible.com/
Audible, Inc.
Wayne, NJ, 07470                      If you put butter and salt on it,
973-837-2797                               it tastes like salty butter.