Question #271250 on Graphite changed:
https://answers.launchpad.net/graphite/+question/271250
Status: Answered => Open
Christopher Swingler is still having a problem:
Thanks guys.
I continued to twiddle the MAX_UPDATES_PER_SECOND and MAX_CACHE_SIZE
values trying to get carbon to stay caught up, or at least not start
denying a ton of data when the MAX_CACHE_SIZE value was hit, and just
plain couldn't get anything to stick. At 1000000 I'd start seeing
"MetricCache is full: self.size=1000000", it would flush a _few_ out,
but never really stay down until a restart took place, and then would
start climbing again. The difference between metricsReceived and
committedPoints continued to diverge by a large amount (it's recently
climbed to a >50k difference).
Last thing I tried was to switch CACHE_WRITE_STRATEGY from "sorted" to
"naive". That fixed it. I personally didn't expect that to work.
metricsReceived and committedPoints pretty close to line up now. It's
been keeping up for the past 30 minutes, and the cache size hasn't
broken 400k points.
This system's backed by solid state storage, and seems to have no
serious performance hit from that change.
@piotr: Does the above description line up closer to what's been
outlined in issue #371 and/or PR #266? I think an issue with duplicate
timestamps not being accounted for would make sense, though I'm not sure
how to conclusively link to that.
--
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
