Question #296337 on Graphite changed:
https://answers.launchpad.net/graphite/+question/296337
Status: Open => Answered
Jason Dixon proposed the following answer:
My general philosophy is to go "as vertical as possible" (e.g. scaling
out with many carbon instances within any single node) before
distributing across multiple nodes. You should have some notion of your
iops capacity on each server so you know how much of your theoretical
ceiling you're hitting before scaling horizontally. Once you know that
you want to try and hit that number (write iops), but then go further by
increasing the batch write size (as reported by carbon's pointsPerUpdate
metric). This is largely done by decreasing your UPDATES_PER_SECOND
below the high water mark so that carbon-cache is forced to perform a
write_many().
(Note, much of this is elaborated on further in my book:
http://shop.oreilly.com/product/0636920035794.do)
Also of note: thanks to jjneely's merge TimeSeries patch in 0.9.14
(https://github.com/graphite-project/graphite-web/pull/1293), Graphite
is much more forgiving with misbalanced or even overlapping (the same
Whisper metric existing on more than one node) metrics than it was
prior.
--
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
