Version 1 (modified by oetiker, 16 years ago) (diff)

--

RRD Accelerator Design

Problem

The rrd data format is quite efficient when it comes to minimize the amount of data that has to be written to disk for a single update. Big installations feature many rrd files. With this the OS is not able to cache everything anymore and updateing 60'000 rrd file can become incredibly slow. Writing the same amount of data into 10 files would be incredibly fast.

Solution

Instead of writing updates straight to the rrd file, they are stored in memory until:

  • a configurable amount of time has passed
  • a configurable number of updates have been accumulated for a file
  • memory is full
  • we receife a flush command
  • rrdgraph needs the rrd file

Implementation

When rrdtool accelerator daemon is running, it creates a unix domain socket in a well known location (/tmp/rrd-accelerator-$USER/socket). When any of the rrdtool commands are run, they first check if the socket is there. If it is they will either send a flush command for the file they are interested in, or the data for rrdtool update.

Problems

When running rrdtool accelerator in combination with a mix of rrdtool versions, some knowing about the acelerator and others NOT knowing about it, then interesting things may happen.


NOTE: The content of this website is accessible with any browser. The graphical design though relies completely on CSS2 styles. If you see this text, this means that your browser does not support CSS2. Consider upgrading to a standard conformant browser like Mozilla Firefox or Opera but also Apple's Safari or KDE's Konqueror for example. It may also be that you are looking at a mirror page which did not copy the CSS for this page. Or if some pictu res are missing, then the mirror may not have picked up the contents of the inc directory.