Eduardo Bragatto | 18 Nov 17:23 2014

Pull requests should go to 1.4 or master?


I have submitted a couple pull requests for the 1.4 branch and today I noticed Tobias created new pull requests for the same changes to the master branch.

Should I have created pull requests for both branches?

Just asking so in the future I can save you some time and do it properly.

- Eduardo Bragatto
rrd-developers mailing list
rrd-developers <at>
Jeroen Massar | 24 Oct 12:29 2014

rrdcached API documentation?

Hola muchachos,

I was checking on adding rrdcached support to the SixXS
statistics daemon[1] to get it a bit out of IO hell...

$ du -hcs rrd
21G	rrd
21G	total

if you get my drift ;) [which might be little for some folks...]

But apart from:

I can't find any API documentation, using those APIs I googled a bit:

A google(rrdc_connect is empty.

A google(rrdc_connect gives only the patches
on the mailinglist.

The Debian librrd-dev does not have anything either and I can't
seem to find it in the source tarballs (see below) unless I am
looking in the wrong location.

Is there a small minimal example application that shows the ropes?

Also, if rrdcached opens the files, how are permissions handled?
Especially when the calling process runs as user X and the daemon
as user Y. Or is it expected that rrdcached runs as X or at least
in the right group?

has nothing about this...


[1] The thing that collects the data for
    but also traffic + latency stats for the individual tunnels

rrdtool-1.4.7$ rgrep rrdc_connect .
./src/rrd_update.c:        int status = rrdc_connect(opt_daemon);
./src/rrd_client.c:static int rrdc_connect_unix (const char *path) /* {{{ */
./src/rrd_client.c:} /* }}} int rrdc_connect_unix */
./src/rrd_client.c:static int rrdc_connect_network (const char *addr_orig) /* {{{ */
./src/rrd_client.c:} /* }}} int rrdc_connect_network */
./src/rrd_client.c:int rrdc_connect (const char *addr) /* {{{ */
./src/rrd_client.c:    status = rrdc_connect_unix (addr + strlen ("unix:"));
./src/rrd_client.c:    status = rrdc_connect_unix (addr);
./src/rrd_client.c:    status = rrdc_connect_network(addr);
./src/rrd_client.c:} /* }}} int rrdc_connect */
./src/rrd_client.c:  rrdc_connect(opt_daemon);
./src/rrd_xport.c:        int status = rrdc_connect(im.daemon_addr);
./src/rrd_graph.c:        int status = rrdc_connect(im->daemon_addr);
./src/rrd_flushcached.c:    status = rrdc_connect(opt_daemon);
./src/rrd_client.h:int rrdc_connect (const char *addr);
./src/rrd_client.h:#	define rrdc_connect(a) 0
./debian/librrd4.symbols: rrdc_connect <at> Base 1.4~rc2
./debian/librrd4.symbols: rrdc_connect <at> Base 1.4~rc2
Tugrul Erdogan | 12 Sep 08:28 2014

Rrdtool fetch performance difference between Linux and Freebsd


I am porting a project which is developed and used on FreeBSD 10 to Linux. After porting rrdtool funuctionalities, I realized that periodic "rrdtool fetch" calls on CentOS 7 spends two times more time than on FreeBSD. The rrdtool version on FreeBSD is 1.4.7 and on Linux 1.4.8 . 

To examine the situation more deeply, I have transfer same rrd file to FreeBSD and I have write a bash script which reports start and end times of 500 "rrdtool fetch" call with same parameters on same rrd file. The results show that "rrdtool fetch" call on Linux is two times slower than "rrdtool fetch" call on Linux.

What can be the cause of this performance decreasing? How can I improve the perfomance of "rrdtool fetch" call on Linux to make it as fast as FreeBSD "rrdtool fetch" call performance?
rrd-developers mailing list
rrd-developers <at>
Peter | 7 Jul 23:25 2014

RRDCached on Windows

is a rrdchached windows service available?
If not, has someone built it from rrd_daemon.c?

View this message in context:
Sent from the RRDtool Developers Mailinglist mailing list archive at
Maciek Kolbusz | 27 Jun 08:09 2014

Proposing a new instruction for rrdraph: DSN

Hello List,

I migrated my growing collection of RRD files to MySQL several months ago and it really reduced the IO load on the data collecting host as well as improved the speed of drawing graphs. A new problem I faced was that the length of rrdgraph commands increased due to longer DEF statements - with sql/ notation on average the length of a single DEF statement is about 250 characters. I have scripts that generate rrdgraph commands to draw complex graphs with tens or sometimes hundreds of DEFs, CDEFs, GPRINTs for formatted legends etc. and many times it happened that rrdgraph failed to generate a picture, because the command was too long (the length limit on my system is 130k characters). It would help to avoid this issue and shorten the command length if it was possible to define a DSN (Data Source Name) and reuse it in DEFs, ie.:

rrdtool graph ... \
DSN:dsn1=sql//mysql/ \
... \
DEF:defA=dsn1/rrdminstepsize=60/TABLE_A/timestamp/value/RRDKeyID='"keyA'":avg:AVERAGE \
DEF:defB=dsn1/rrdminstepsize=60/TABLE_B/timestamp/value/RRDKeyID='"keyB'":avg:AVERAGE \
DEF:defC=dsn1/rrdminstepsize=60/TABLE_C/timestamp/value/RRDKeyID='"keyC'":avg:AVERAGE \

It's debatable what elements should be included in DSN and what should be left for DEF, however I would suggest that DSN only contained host, port, dbname, dbuser and password, because one database can have multiple tables with different step sizes, so the in DEFs it would be possible to use different tables in the same DB referring to the same DSN, but giving different step sizes and table names.

Another feature that I think would be very useful is reading DSN from files: store DSN definition in a text file and then point to this file in the command, ie.:

rrdtool graph ... \
DSN:dsn1=file:///path/to/file \

This way DB credentials would be better protected as there would be no risk that they appear in the commands and later in application logs or elsewhere in the system where other users could see them.

Please share your thoughts and comments on this feature.

Maciek Kolbusz
rrd-developers mailing list
rrd-developers <at>
Peter Childs | 13 Jun 11:41 2014

about [rrdtool-1.x] Fetch callback (#502)

Reading the comments, and the edit to src/rrd_graph.c

   968 +        // remember that we already got this one
   969 +        g_hash_table_insert(im->rrd_map,gdes_fetch_key(im->gdes[i]),GINT_TO_POINTER(i));

I have noted when I tried to build a custom backend using rrdcached protocol that when drawing a graph it appeared to a little inefficient.

For example
  If I had a RRD with DS(s) of inOct, outOct, inErrs, outErrs and then used 'graph' to generate a single graph with all those DS's from the same RRD I would see 4 FETCH operations via rrdcached.

Since the fetch does not specify the DS required, all the datasources in the RRD need to be returned.   This probably isn't a problem for simple RRD files, but for example if you have 12 metrics, and each metric has a 'cost' to 'get', and you only really need two for your graph, you need to fetch them all anyway (or in my example, you need to fetch them all, then remangle them into the appropriate structures, then return them ..)

My question is -- does this change to the rrd_graph data_fetch() mean that I will not see multiple fetch operations ?

(I guess I should just go and test it ...)


rrd-developers mailing list
rrd-developers <at>
Peter | 10 May 11:16 2014

Compile rrdtool-1.4.8 in Visual Studio 2013


I compiled successfully rrdtool-1.4.8 with Visual Studio 2013 after solving
the following 3 issues. At first pay attention to WIN32-BUILD-TIPS.txt and
load / copy  all libraries.
There are 3 issues left:
1. ==============
use a folder without spaces!
Otherwise later come an post build event error:

Error     20     error MSB3073: The command "copy
c:\Users\Peter\Documents\Visual Studio
c:\Users\Peter\Documents\Visual Studio 2013\rrdtool-1.4.8\win32\Debug\\ ...

2. ====================
Error     2     error C2556: 'int round(double)' : overloaded function
differs only by return type from 'double round(double)'    

in math.h is defined
_CRTIMP double __cdecl round(_In_ double _X);

comment out:
//__inline int round(double a ){int x = (a + 0.5); return x;}

possible slower as  inline, but in c++ is not allowed overloaded function
differs only by return.. Is there a faster solution?

3. =======================
Error     14     error C1189: #error :  "Don't know how to deal with TIME_T
other than 4 or 8 bytes"     c:\Users\Peter\Documents\Visual Studio
2013\rrdtool-1.4.8\src\rrd_restore.c     235     1     rrdlib

solution from answer
in rrd_restore.c
        #if SIZEOF_TIME_T == 4
                     temp = strtol(( char *)text,NULL, 0);
        #elif SIZEOF_TIME_T == 8
                     temp = strtoll(( char *)text,NULL, 0);       
        #error "Don't know how to deal with TIME_T other than 4 or 8 bytes"
#ifndef WIN32
        #if SIZEOF_TIME_T == 4
                     temp = strtol(( char *)text,NULL, 0);
        #elif SIZEOF_TIME_T == 8
                     temp = strtoll(( char *)text,NULL, 0);       
        #error "Don't know how to deal with TIME_T other than 4 or 8 bytes"
                     temp = strtoll(( char *)text, NULL, 0);

in  rrd_create.c:
#include "../rrd_config.h"

#ifndef WIN32
#include "../rrd_config.h"

After this changes I can compile it without errors and 110 warnigs.


View this message in context:
Sent from the RRDtool Developers Mailinglist mailing list archive at
Martin Sperl | 8 May 10:09 2014

rrdcached and --skip-past-updates


With regards to template support for rrdcached (on the client side)
which just reacently got merged, I just started to wonder how
"--skip-past-updates" is related to rrdcached.

I wonder if it is really a necessity to have this test in rrd_update.c:
    if (extra_flags != 0) {
        rrd_set_error("The caching daemon cannot be used together with "
                      "templates and skip-past-updates yet.");
        goto out;

It should be fairly easy to "ignore" the error from rrdcached
communication passing extra_opts to rrdc_update and there doing the
sanity check on the response from rrdcached.

Something like that in rrd_client.c in rrdc_update:
/* ignore time update errors in case RRD_SKIP_PAST_UPDATES is set  */
if (status && (extra_flags & RRD_SKIP_PAST_UPDATES))
    if ((strstr(res.message,"illegal attempt to update using time")
        && strstr(res.message," when last update time is "))

Is this a valid observations?

Martin Sperl | 6 May 15:59 2014

rrd_calc and avoid repeated memory allocations/initial setups


It seems as if there is no easy means to store extra data for the whole life-time of the
rpn_calc loop.

The reason why I ask is because I am implementing the predictperc function, which is 
similar to predict and predictsigma but it gives the X percentile.

For this I need to order the data (depending on arguments maybe 50-60 floats),
which means allocating memory (the exactly same amount for every time rpn_calc gets called)
to keep all those values sorted to find the correct percentile.

Unfortunately the way rrd_calc works, there is no data that is kept between calculations,
to avoid the repeated create/teardowns of this structures...

Seems as if an "easy" way would be enhancing rpnp_t by adding this this:
void *extra; /* extra data used during setup */
void (*free_extra)(void *); /* a function used to free the extra structure... 
			     * - if null, then a "normal free" is done */

and some code in rpnstack_free to call the "free" functionpointer with the argument of extra.
(or free directly if the pointer is NULL)

So would something like the above be acceptable?

Svante Signell | 29 Apr 14:35 2014

RFC: [PATCH] Portability by avoiding PATH_MAX


Here are updated patches for rrdtool/rrd_client.c and
rrdtool/rrd_daemon.c. We had some discussions in August last year. I
created a branch and the diffs are against latest git. I've run the
code, especially rrd_daemon with valgrind under Linux, but need some
help to check that also rrd_client works OK (maybe rrd_daemon too). Can
you help me with test cases to run the execute the code modified paths.
I know one application using rrdtool, lm-sensors (build-dependency on
librrd2-dev), but am not sure my computers have the sensors to be a good
test case.

Note that the modified functions get_path() and get_abs_path() are
static, so they don't change the API.

Svante Signell
Attachment (rrd_daemon.patch): text/x-patch, 15 KiB
Attachment (rrd_client.patch): text/x-patch, 3960 bytes
rrd-developers mailing list
rrd-developers <at>
Steve Shipway | 28 Apr 02:37 2014

ROL and ROR for RPN

So, splitting this idea out from the separate post on the predict function,
I propose adding the new operations ROL and ROR to the RPN interpreter.

They would rotate the top 3 items left or right, and have this effect on the
stack ...

1,2,3,ROL  -->  2,3,1
1,2,3,ROR -->  3,1,2

These allow more complex arithmetic to be performed and complement the
existing EXC operator.

A context-diff against 1.4 is attached for your consideration; it is pretty
simple and implemented similarly to EXC.  The modified files are
rrd_rpncalc.h and rrd_rpncalc.c


Steve Shipway
s.shipway <at>

Attachment (rol-ror.patch): application/octet-stream, 2720 bytes
Attachment (smime.p7s): application/pkcs7-signature, 7984 bytes
rrd-developers mailing list
rrd-developers <at>