[rrd-users] Re: adding datasources to existing RRDs using XML

Selena M Brewington smbrewin at ichips.intel.com
Tue Jan 11 23:55:41 MET 2000


Tobias Oetiker writes:
 > Today you sent me mail regarding [rrd-users] adding datasources to existing...:
 > *> tell me if I did this correctly?  One of the things I am wondering is if
 > *> using NaN vs. 0 makes much of a difference in the rows and the PDP entries I
 > *> am altering/adding.  I tried it out on a few RRDs and it seems to work.
 > 
 > NaN is the correct thing todo ... I guess I should modifie rrdrestore to

Ok.  I'll change that.

 > accept input from stdin ... may I add the script to the contrib area ?

Sure - let me fix it and add the wrapper.  I'll send the results. 

 > you might want to consider to NOT add new rows to existing RRAs but rather
 > have more RRAs ...

I was thinking of compatibility with cricket - I want to add additional
datasources to one target (or instance of a target) that will be visible
inside the same grapher 'view', and compatible with the existing poller.
The view thing I can work around, but I don't know how to add the
datasources and keep my existing data without a) doing this XML conversion,
b) creating an additional branch in the config tree - which loses the
advantage of having the config tree in the first place IMO.  If there's a
way to have the poller recognize additional datasources and RRAs without
killing my existing ones, I'd be all for using more RRAs.

 > I am interested in your 'large' site ... what performance do you see which
 > what hardware ... is anything visible from outside ?

sorry, nothing visible.  although, I could dig up some graphs for you.  

I'm running cricket+rrdtool on two machines right now.  One is a pII
dual-processor, 512 MB RAM, redhat 6.0, 100 Mb eepro100 at full duplex,
nfsv2 - all the rrds are NFS mounted from an auspex server that is accessed 
through the same subnet (no packets tromping through a router first). this
machine serves the cricket web pages. 

the other machine has a pentium pro processor, running redhat 6.0, 384 MB
RAM, 100 Mb eepro100 at full duplex, all the same NFS stuff.  these two
access the same config tree.

RAM seemed to be the limiting factor in getting better performance on both
machines (my only indicator being the time it took to complete jobs). Also,
upgrading the eepro100 driver to the latest version at that i could find at
the time...1.09l (i believe 'r' is the latest version now?), seemed to solve 
some weird crashes I experienced at first.

I have 7200+ RRDs, and 3329 were updated in the last five minutes.  I have
16 jobs that run every 5 min and all pretty much complete within 3 minutes.
The longest job is 1326 rrds getting updated with 2 data points per update
(soon to be 6, actually), and it finishes in 2.5-3 minutes.  These jobs
are grouped according to administrative domains right now (which kind of
sucks for load balancing).

and come june/july, our environment is going to get about 4 times as big
(so far as the network is concerned, anyway), so that should be interesting :) 

do you have some sort of performance testing tool?  i could hack something
out to do really simple tests.  i don't know that much about performance
testing, however.

-selena

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users



More information about the rrd-users mailing list