[rrd-developers] RRDcached performance issues (from Users mailinglist)
steve.schnepp at gmail.com
Mon Mar 16 08:53:38 CET 2015
I'm a dev guy from the Munin project(*). We have some heavy RRD among our
Some hints from the trenches:
* I discovered that having multiple rrdcached daemon is actually very bad
for performance. The only way to shard them efficiently is to have them
handling a different FS with different disk subsystem. (I didn't try with
* For some workloads tmpfs+sync (note that a simple cp might be more
efficient than a rsync) is simply the best.
* You have to avoid doing reads on rrds, as it flushes. (1.4.x, don't know
* A very big -w and -z setting (think 3600) helps, as it give rrdcached the
most flexibility to reorder writes
* Always flush manually before closing (FLUSHALL on the socket), to avoid
too long restart times. The restarts journal read is way too slow, a you
Hopes it helps.
On 17:59, Sun, Mar 15, 2015 Tobias Oetiker <tobi at oetiker.ch> wrote:
I guess that very few people have rrdtool setup at your scale ...
so chances for someone coming forward with useful hints may be
Things to look at:
a) try rrdtool 1.5rc2 since this is the latest and greates code
b) go into the cached code and add some debugging output
c) strace/truss may provide some insight in to what rrdcached when
it seems busy
d) attach gdb and break processing to see where in the source this
Yesterday Gaby wrote:
> Dear developers, could you take a look at my post in the Users forum?
> It has no replies, and I'm still very interested in shedding some light on
> View this message in context:
> Sent from the RRDtool Developers Mailinglist mailing list archive at
> rrd-developers mailing list
> rrd-developers at lists.oetiker.ch
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
rrd-developers mailing list
rrd-developers at lists.oetiker.ch
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rrd-developers