[rrd-users] Problem with seek error in RRA

Alex van den Bogaerdt alex at ergens.op.het.net
Mon Jul 2 13:39:56 CEST 2007

On Mon, Jul 02, 2007 at 12:42:34PM +0200, wallaschwigalla at arcor.de wrote:
> Hi,
> I created a tool for protocol analysing which uses Wireshark as analyser, PERL and the RRD-Tool for generating the graphs. The OS is Solaris 10. RRD-Tool 1.2.19. I’ve created a Database for every protocol. HTTP is one of the biggest protocols caused by the big amount of possible status-codes. The HTTP-DB is splitted in 6 RRDs. The RRA I used is an AVERAGE which doesn’t really average the DATA. “RRA:AVERAGE:0.5:1:$dbzeit”. The variable $dbzeit is set to 31536000(one year). This creates a File with 2000MByte per RRD which results in 8GB for the hole HTTP-DB.
> After nearly one month I got the problem that I can create graphs with an interval from 24hous but I can’t create a graph with a timescale from 5minutes, 15minutes or 1hour. The only message I get is ERROR : seek error in RRA.

There's only one instance of this error in rrd_fetch(), it is for
the following function:

   (rra_base + (rra_pointer * *ds_cnt * sizeof(rrd_value_t)))

> In the first versions of my project I used RRAs with nearly 2 month stored in one file without an Error. Is there a problem with so big RRAs and the resolution from 1second????

Most likely the problem is that
  (rra_base + (rra_pointer * *ds_cnt * sizeof(rrd_value_t)))
is too large (possibly becoming negative).  It's a pitty that the
error message from the OS isn't looked at.

Too many DSes, too many rows, size of rrd_value_t could be different,
too many RRAs in one database; I think this sums up the possible problems.

If you have only one DS and one RRA, the problem has to be a combination
of too many rows times too many bytes per entry (rrd_value_t).

Possible solutions and workarounds (there may be more):

-1- use an OS that can handle larger files; or maybe there's a patch
    to apply
-2- use an OS that uses less bytes per rrd_value_t
    (not sure what yours is using right now, so maybe not applicable)
-3- use multiple files, e.g. one file per three months. This may also
    be preferable from other perspectives such as performance, backup
    and so on.

Not a quick solution, sorry, but HTH nevertheless.
Alex van den Bogaerdt

More information about the rrd-users mailing list