all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Aaron Lauterer <a.lauterer@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] ceph osd: ui: show PGs per OSD
Date: Tue, 14 Feb 2023 17:14:58 +0100	[thread overview]
Message-ID: <27365ccf-542c-ff70-2e96-aaf92ea4c66d@proxmox.com> (raw)
In-Reply-To: <e0cec464-00cb-6b52-f718-5f5ad8f10075@proxmox.com>

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-tree    osd-tree
osd-df-tree  9217/s          --        -27%
osd-tree    12658/s         37%          --
root@jura1:~# ./bench.pl
                Rate osd-df-tree    osd-tree
osd-df-tree  9141/s          --        -25%
osd-tree    12136/s         33%          --
root@jura1:~# ./bench.pl
                Rate osd-df-tree    osd-tree
osd-df-tree  9940/s          --        -23%
osd-tree    12987/s         31%          --
root@jura1:~# ./bench.pl
                Rate osd-df-tree    osd-tree
osd-df-tree  8666/s          --        -20%
osd-tree    10846/s         25%          --
root@jura1:~#

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 more information per
> 
> the change looks almost too neat for using a completely different command,
> a bit fishy, but hey, if it works (roughly as fast) as the other one its
> fine to me.
> 
>> OSD. One of them is the number of PGs stored on that OSD.
>>
> 
> did you benchmark the both to compare for any bigger runtime difference?
> 
> E.g., some loop with a few thousands rados mon_command calls in perl for each
> using HiRes timer to measure total loop time and compare?
> 
> I'd not care for a few percent, but would be good to know if this is
> order of magnitudes slower - which I'd not expect, but its to easy to
> check to not do so IMO.




  parent reply	other threads:[~2023-02-14 16:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14  8:13 Aaron Lauterer
2023-02-14 13:19 ` Thomas Lamprecht
2023-02-14 15:05   ` Aaron Lauterer
2023-02-14 16:14   ` Aaron Lauterer [this message]
2023-02-15  6:18     ` Thomas Lamprecht
2023-02-15  9:20       ` Aaron Lauterer
2023-02-15 11:25 ` [pve-devel] applied: " Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27365ccf-542c-ff70-2e96-aaf92ea4c66d@proxmox.com \
    --to=a.lauterer@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal