graphite-dev team mailing list archive

[Michal Czerwinski <question248879@xxxxxxxxxxxxxxxxxxxxx>]

New question #248879 on Graphite:
https://answers.launchpad.net/graphite/+question/248879

I am testing some graphite performance and I am trying to see how much updates per second I can have before it becomes IO bound.
I run this on c3.xlarge instance with 500GB EBS volume which has in front 40GB SSD cache - both are setup using bcache in writeback mode, I use naive method for sorting metrics.

I found this weird relation between number of metrics I can push and number of updates per second I am getting on carbon daemons.
To get rid of IO limits II set number of updates per second to some high value like 25000 which for three agents should sum up to 75000 - quite high.
Now, when I send around 620K metrics per minute I get a decent 10K updates per second and 8% IOWAIT, when I push this to around 1.3M metrics per minute I only get 7K updates per second and around 2% IOWAIT + carbon agent memory usage grows which indicates that more metrics are being cached.
Ideas?


-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.