[rrd-developers] rrdcached contention when flushing

Daniel Pocock daniel at pocock.com.au
Tue Nov 4 23:22:52 CET 2008



> When files are flushed out to disk, their tree node remain.  That way, the
> structure of the tree doesn't have to be re-balanced over and over for a
> static working set.
>   
That is a sensible approach - however, valgrind reports that some of 
this nodes are still accessible, while those identified are `possibly' 
lost.  It seemed worth mentioning, although I didn't mean to suggest 
that was the ultimate cause of my problems.

>
> That sill should not cause your process to bloat to several gigabytes..
> The size of the tree should be on the order of O(node_count * PATH_MAX).
>   

> What does "STATS" from your daemon look like?
>
>   
After seeing the valgrind output - which only indicates a static amount 
of un-freed memory relating to keys, as you have described - I'm 
thinking that the problem may not be a leak, rather, it may be some kind 
of backlog of updates.  I've got a few more tests planned to investigate 
this, for example, slowing down the IO to see if memory usage grows more 
quickly.

Can you think of anything extra that could be added to the STATS output 
to indicate whether there is a backlog, how long it takes to come back 
to each node, etc?

Is it possible that some files would never get flushed, if the flush 
command was being invoked repeatedly for a subset of the files?




More information about the rrd-developers mailing list