> > Would the system benefit from either having multiple server processes > accepting RRD update commands or a multi-threaded server process, or are all > the updates disk bound (aka the disk is too busy)? I have found that the > RRD update process not to be too disk intensive, at least from the aggregate > I/O perspective. However, disk seeks may be keeping the heads pretty busy. > This I have not evaluated. > > Regards, > > Larry Adams
I am also trying to troubleshoot updating large amounts of rrd files within a 5 minute period. We update around 40,000+ rrd files (and growing) using the basic writer and poller from the Cacti team. Our storage is on a NFS system called BlueArk with top of the line disks. We've tried the multiple instances of rrdtool, the cli just doesn't leave much to be desired in performance. If your updating 40k+ you'll going to have to use the library. Our problem is that we can't get all of the 40,000+ files updated within 5 minutes. We have even forked out their php code to help. While in my struggle to get the write under 5 minutes, I've looked at java and multi-threading. I've been developing hard at using rrd's multi-threaded library, but I'm sad to say this may not be an option. Problems with the multi-threaded rrdtool code and threads beeing blocked on file locks for some unknown reason has put me in a bind where I have to take a different approach (thanks to the community for the help =) Currently, we're in the works of making a 'work cluster' built with java to spread the workload of writing to several machines. Hopefully this will aid us in our goal. We have thought about using a database and just using rrdtool when graphs need to be created, but the values themselves is easily 245,000 rows. With 40,000+ rrd files, that's 9.8 billion rows if stored all in one table. A good schema would definantly be your friend, along with a robust database(s). -- "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on only what he knows, but all that he knows. The ignoramus may be saved, but the fool knows that he is doomed." Robert Halstead -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/rrd-developers WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
