Put another way, consider the savings:
o If today you have to deploy dual-socket servers for enough cycles, especially with
dmcrypt and during recovery.
o Tomorrow you could deploy cost-effective servers with much less expensive single-socket
CPUs (and thus freedom from NUMA hassles)
alternately:
o Denser servers with more OSDs per node but the same number of sockets / cores
For larger clusters the CapEx efficiency will be substantial. Maybe a cluster that
economics previously limited to HDDs can now be all-SSD.
— aad
I do not understand. I talk about simple
comparison metric for any
storage application - IOPS. Since both storage applications
(legacy-osd,
crimson-osd) share absolutely the same Ceph spec - that is a fair
choice.
That way you're actually thinking about IOPS from an OSD instance
*disregarding how much HW resources it spends* to serve your
workload. This comparison ignores absolutely fundamental difference
in architecture:
* crimson-osd is single-threaded at the moment. It won't eat more
than 1 CPU core. That's by design.
* ceph-osd is multi-threaded. By default single instance has up to 16
`tp_osd_tp` and 3 `msgr-worker-n` threads. This translates into upper,
theoretical bound of 19 CPU cores. In practice it's of course much
lower but still far above than for crimson-osd.
Both implementations share the same restriction: amount invested on
hardware resources to run the cluster. How much IOPS you will get from
it is determined by the OSD's *computational efficiency*.
The goal is to maximize IOPS from fixed set of hardware OR, rephrased,
to minimize the hardware resources needed to provide a given amount
of IOPS.
The problem is awfully similar to the performance-per-watt metric and
CPU's power efficiency. Electrical / cooling power is scarce resource
just like number of CPU cores is in a Ceph cluster.
Regards,
Radek
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io