Pavel Ruzicka wrote: >>OK, I'm going to play devil's advocate here: WHY is it not a good idea? >> Rateup would create the graphs all the time anyway. By switching to >>rrdtool, I get more disk IO efficiency because of the database format. > > > 1. This is not a good idea, because you need much processor time for graph > generating. For example, I have 6500 targets * four graphs = 26000 > pictures/5min.
Only the daily graph is updated every five minutes. In addition, rateup makes all of the graphs in a stock distribution of MRTG, so asking rrdtool to make all of the graphs isn't any worse than stock rateup. > OK at attachment (If mailing list doesn't break it) I send you debug from > 14all.cgi script. This is excellent - thanks for the information! > I was write my own html index maker, which I run every 24 hours after > cfgmaker. Next I have small stupid PERL CGI script, which make possible > pattern search from HTML pages. For example descriptions from router > interfaces. I had to write my own config maker, as cfgmaker wouldn't build the targets in a manner that would represent the logical grouping within a DS3 that we currently use. My config maker builds a per-card page and a per-port page, which references the bandwidth and discard graphs in one configuration file and the 95th percentile graphs in another config file. It also builds a list of customers per city, which very soon will span multiple routers (but already spans multiple cards). Therefore, in order to make a full transition to rrdtool I need to do it in phases; otherwise rolling back to non-rrdtool becomes too risky. I envision writing the customer indexes, per-card pages, and per-port pages manually, but then modifying the references to point to the CGI. However, this is difficult to do in one batch. Pete -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-users WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
