[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