> 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? _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
