Question #271250 on Graphite changed:
https://answers.launchpad.net/graphite/+question/271250
Status: Open => Answered
Jason Dixon proposed the following answer:
I'm reading your post (which has good details, thank you) yet I'm
failing to find anything that sounds like an actual bug. The behaviors
you describe sound appropriate, at least according to how I understand
Carbon is designed to operate. Points to consider:
1) You say that the cache grows unbounded when MAX_CACHE_SIZE = inf.
This is what it's supposed to do.
2) You say it drops datapoints when it reaches MAX_CACHE_SIZE. This is
what it's supposed to do.
3) You've tuned MAX_UPDATES_PER_SECOND, which has an effect on IO. It
should, especially if you coerce it into bulk writes by setting
MAX_UPDATES_PER_SECOND to a value less than the number of current write
operations. This will be evident by your pointsPerUpdate stats
increasing above 1.0. The higher, the better.
Perhaps you can clarify why you feel Carbon should be "purging its
cache"? Carbon's cache is intended to hold the most recent metrics in
memory, and sort & write them according to the CACHE_WRITE_STRATEGY.
I don't doubt that the behavior has changed between 0.9.12 and 0.9.13.
Many bugs were fixed, including those associated with fixing "correct"
behavior. It sounds like you might've been caught off-guard after
getting used to the operational "personality" of 0.9.12, but I don't
think that you've presented any evidence of a bug.
--
You received this question notification because your team graphite-dev
is an answer contact for Graphite.
_______________________________________________
Mailing list: https://launchpad.net/~graphite-dev
Post to : graphite-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~graphite-dev
More help : https://help.launchpad.net/ListHelp
