On 26-6-2017 09:01, Christian Wuerdig wrote:
Well, preferring faster clock CPUs for SSD scenarios has been floated
several times over the last few months on this list. And realistic or
not, Nick's and Kostas' setup are similar enough (testing single disk)
that it's a distinct possibility.
Anyway, as mentioned measuring the performance counters would probably
provide more insight.
I read the advise as:
prefer GHz over cores.
And especially since there is a sort of balance between either GHz or
cores, that can be an expensive one. Getting both means you have to pay
relatively substantial more money.
And for an average Ceph server with plenty OSDs, I personally just don't
buy that. There you'd have to look at the total throughput of the the
system, and latency is only one of the many factors.
Let alone in a cluster with several hosts (and or racks). There the
latency is dictated by the network. So a bad choice of network card or
switch will out do any extra cycles that your CPU can burn.
I think that just testing 1 OSD is testing artifacts, and has very
little to do with running an actual ceph cluster.
So if one would like to test this, the test setup should be something
like: 3 hosts with something like 3 disks per host, min_disk=2 and a
nice workload.
Then turn the GHz-knob and see what happens with client latency and
throughput.
--WjW
In a high concurrency/queue depth situation, which is probably the most common workload, there is no question that adding more cores will increase IOPS almost linearly in case you have enough disk and network bandwidth, ie your disk and network % utilization is low and your cpu is near 100%. Adding more cores is also more economic to increase IOPS versus increasing frequency.
But adding more cores will not lower latency below the value you get from the QD=1 test. To achieve lower latency you need faster cpu freq. Yes it is expensive and as you said you need lower latency switches and so on but you just have to pay more to achieve this.
