[rrd-users] rrdgraph never returns with small step

Josh Wyatt josh.wyatt at hcssystems.com
Thu Jun 19 17:13:00 CEST 2008


Alex,

Thanks for the tips, we may have a handle on it; responses inline... Answer at the bottom for the impatient.

Thanks,
Josh

Alex van den Bogaerdt wrote:
> On Wed, Jun 18, 2008 at 10:10:21PM -0400, Josh Wyatt wrote:
> 
>> This works fine... It does make a big file though, about 7.3MB.
>>
>> The update is via RRDs:
>> $e=RRDs::update('bits.rrd','-t','00:01:02:03:04:05:06:07:08:09:10',"N$total");
>> The way $total is built, it includes a preceding ':' so that a typical line looks like this:
>> $e=RRDs::update('bits.rrd','-t','00:01:02:03:04:05:06:07:08:09:10',"N:35:11:13:12:12:14:10:10:604:591:11");
>>
>> And this updates the RRD every second, in a loop.
> 
> Not that I expect this to be related to the problem you report, but I
> think you may want to consider using timestamps instead of 'N'. When
> updates are a bit delayed (e.g. busy computer) it doesn't really matter
> for 5-minute updates (e.g. 0.1 second on 300 seconds is 0.3%) but it
> does for 1-second updates (e.g. 0.1 second on 1 second is 10%)

I tried this, in addition to creating another test with 10 second step time, but with the same results...

>> Now, I try to graph:
>> /usr/local/bin/rrdtool graph /home/graphs/all.png  -s -30s -w 200 -h 40 -a PNG
>>  -A  \
>> DEF:00=/home/graphs/bits.rrd:00:AVERAGE \
>> LINE1:00#00cccc  
> 
> You don't need "--end" ?

It assumes "now" correct?

> Try to isolate the problem.
> 
> This is 30 seconds, on 200 pixels.  That is 6.66666.... pixels per
> second.  It shouldn't be a problem, but just to be sure you should
> try with something more sane, like -s-30s -w 300.

I tried numerous sizes, but multiples didn't show consistent results.  Sometimes the command succeeded, sometimes it failed, at -s -30s.  On the same RRD file with the same graphing params, with seemingly no changes!  This is the most frustrating thing, is that no variable that I control is changing (not the rrd file, not the graphing opts...), but the behavior is inconsistent.  This tells me it might be based somehow on the time range when endtime=now...

> Try fetching the data (rrdtool fetch -s -30s /home/graphs/bits.rrd AVERAGE).
> Does that hang, or not. If it does, the problem is probably somewhere
> in the data collection part, else if will probably be in the graph part.

Did not try fetch.  But I bet it will work fine everytime :)

> Data:
> Try using another disk (no NFS, no data storage card, different filesystem.)
> Try building RRDtool with/without mmap.

Tried using internal SATA drive (original) and another internal EIDE drive (added)... Same results...

> Graph:
> Try switching off the X-axis label. If it then works, try to find
> a label setting which works for you.  E.g.
> 
> --x-grid none
> --x-grid SECOND:1:SECOND:10:SECOND:10:0:%s
> 
> Do similar for the Y-axis.
> 
> Try another type of image, perhaps there's a problem in the graph
> library.
> 
> Try switching off titles and so on (especially if using non-ascii
> characters).
> 
> Better yet: use "--no-legend" , so that no 'extra' will be in the way.

Now we're getting somewhere.  I tried the following:
-a EPS (instead of PNG): no change.
--no-legend: no change
removing -A: no change
--y-grid none: no change
--x-grid none: AHA.  Graph generates every time.  I tried lots of abusive parameters (different start/stop times, large graphs, adding all the other previous options back in, many CDEFs, etc) and it works fine every time.

So it appears to be something related to how the x grid is drawn, which also explains the dependency on the time.

Now what :) ?  How can I get my X grid without lots of manual --x-grid A:B:C:D:E:F fun?

Thanks again,
Josh



More information about the rrd-users mailing list