On 2/15/23 07:18, Thomas Lamprecht wrote:
Am 14/02/2023 um 17:14 schrieb Aaron Lauterer:
Seems like the `osd df tree` call is about 25% slower, plus minus.
Tested on our AMD test cluster that is currently set up with 3 nodes with 4
OSDs each. 50k iterations.
root@jura1:~# ./bench.pl
Am 14/02/2023 um 17:14 schrieb Aaron Lauterer:
> Seems like the `osd df tree` call is about 25% slower, plus minus.
>
> Tested on our AMD test cluster that is currently set up with 3 nodes with 4
> OSDs each. 50k iterations.
>
> root@jura1:~# ./bench.pl
> Rate osd-df-treeosd-t
Seems like the `osd df tree` call is about 25% slower, plus minus.
Tested on our AMD test cluster that is currently set up with 3 nodes with 4 OSDs
each. 50k iterations.
root@jura1:~# ./bench.pl
Rate osd-df-treeosd-tree
osd-df-tree 9217/s ---27%
osd-tree
I compared the returned values, but did not benchmark it.
I'll follow up with the results.
On 2/14/23 14:19, Thomas Lamprecht wrote:
On 14/02/2023 09:13, Aaron Lauterer wrote:
By switching from 'ceph osd tree' to the 'ceph osd df tree' mon API
equivalent , we get the same data structure with m
On 14/02/2023 09:13, Aaron Lauterer wrote:
> By switching from 'ceph osd tree' to the 'ceph osd df tree' mon API
> equivalent , we get the same data structure with more information per
the change looks almost too neat for using a completely different command,
a bit fishy, but hey, if it works (rou
By switching from 'ceph osd tree' to the 'ceph osd df tree' mon API
equivalent , we get the same data structure with more information per
OSD. One of them is the number of PGs stored on that OSD.
The number of PGs per OSD is an important number, for example when
trying to figure out why the perfor
