From: Mark Nelson <mnelson@redhat.com>
To: "Moreno, Orlando" <orlando.moreno@intel.com>,
"fio@vger.kernel.org" <fio@vger.kernel.org>,
"ceph-users@lists.ceph.com" <ceph-users@lists.ceph.com>
Cc: "'cbt@lists.ceph.com'" <cbt@lists.ceph.com>
Subject: Re: [Cbt] Poor libRBD write performance
Date: Mon, 20 Nov 2017 10:16:12 -0600 [thread overview]
Message-ID: <8024d5cc-daeb-be4a-5f88-28d91e69d46e@redhat.com> (raw)
In-Reply-To: <034AAD465C6CBE4F96D9FB98573A79A62C2C92E0@FMSMSX108.amr.corp.intel.com>
On 11/20/2017 10:06 AM, Moreno, Orlando wrote:
> Hi all,
>
>
>
> I�ve been experiencing weird performance behavior when using FIO RBD
> engine directly to an RBD volume with numjobs > 1. For a 4KB random
> write test at 32 QD and 1 numjob, I can get about 40K IOPS, but when I
> increase the numjobs to 4, it plummets to 2800 IOPS. I tried running the
> same exact test on a VM using FIO libaio targeting a block device
> (volume) attached through QEMU/RBD and I get ~35K-40K IOPS in both
> situations. In all cases, CPU was not fully utilized and there were no
> signs of any hardware bottlenecks. I did not disable any RBD features
> and most of the Ceph parameters are default (besides auth, debug, pool
> size, etc).
>
>
>
> My Ceph cluster is running on 6 nodes, all-NVMe, 22-core, 376GB mem,
> Luminous 12.2.1, Ubuntu 16.04, and clients running FIO job/VM on similar
> HW/SW spec. The VM has 16 vCPU, 64GB mem, and the root disk is locally
> stored while the persistent disk comes from an RBD volume serviced by
> the Ceph cluster.
>
>
>
> If anyone has seen this issue or have any suggestions please let me know.
Hi Orlando,
Try seeing if disabling the RBD image exclusive lock helps (if only to
confirm that's what's going on). I usually test with numjobs=1 and run
multiple fio instances with higher iodepth values instead to avoid this.
See:
https://www.spinics.net/lists/ceph-devel/msg30468.html
and
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-September/004872.html
Mark
>
>
>
> Thanks,
>
> Orlando
>
>
>
> _______________________________________________
> Cbt mailing list
> Cbt@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/cbt-ceph.com
>
prev parent reply other threads:[~2017-11-20 16:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <034AAD465C6CBE4F96D9FB98573A79A62C2C92E0@FMSMSX108.amr.corp.intel.com>
2017-11-20 16:10 ` [ceph-users] Poor libRBD write performance Jason Dillaman
2017-11-20 17:00 ` Moreno, Orlando
2017-11-20 17:01 ` Jason Dillaman
2017-11-20 16:16 ` Mark Nelson [this message]
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=8024d5cc-daeb-be4a-5f88-28d91e69d46e@redhat.com \
--to=mnelson@redhat.com \
--cc=cbt@lists.ceph.com \
--cc=ceph-users@lists.ceph.com \
--cc=fio@vger.kernel.org \
--cc=orlando.moreno@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox