carbon_ch always sends metrics to last carbon-cache about carbon-c-relay HOT 4 CLOSED

This is to be expected. The original carbon hash ignores the port number, and has an additional optional target that it takes into account instead. Carbon-c-relay doesn't support this target, therefore your configuration for the hash looks like duplicate hosts, so they all map onto the same hash points. I'm planning to add a fnv1a_ch which uses the same hash behind any_of, but is cheaper, more well-balanced and allows to make your example work as you expect.
Thanks for the report!

from carbon-c-relay.

as I can't change the carbon_ch implementation, but I can add a new hash form, fnv1a_ch is there to work in the configuration as you showed above

from carbon-c-relay.

Thanks! So I'm testing out a new graphite server at the moment using the fnv1a_ch hash and its looking pretty good so far. Currently only pushing ~10K metrics/min but that should increase to about 100K/min when the rest of the cluster comes online next week.

from carbon-c-relay.

Cool! It's interesting to know how much CPU carbon-c-relay takes (we could try to optimise the hash somewhat if necessary), and how many dispatchers are idle under your load. By default you have 16, but you can change that using the -w flag. We do ~1M/min on some relays, but for the aggregators we have had ~10M/min. Memory usage should stay minimal, queue sizes low (but not necessarily 0).

from carbon-c-relay.