From: Mark Nelson <mnelson@redhat.com>
To: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: newstore performance update
Date: Tue, 28 Apr 2015 19:00:43 -0500 [thread overview]
Message-ID: <55401F2B.60206@redhat.com> (raw)
In-Reply-To: <554016E2.3000104@redhat.com>
On 04/28/2015 06:25 PM, Mark Nelson wrote:
> Hi Guys,
>
> Sage has been furiously working away at fixing bugs in newstore and
> improving performance. Specifically we've been focused on write
> performance as newstore was lagging filestore but quite a bit
> previously. A lot of work has gone into implementing libaio behind the
> scenes and as a result performance on spinning disks with SSD WAL (and
> SSD backed rocksdb) has improved pretty dramatically. It's now often
> beating filestore:
>
> http://nhm.ceph.com/newstore/newstore-5d96fe6-no_overlay.pdf
>
> On the other hand, sequential writes are slower than random writes when
> the OSD, DB, and WAL are all on the same device be it a spinning disk or
> SSD. In this situation newstore does better with random writes and
> sometimes beats filestore (such as in the everything-on-spinning disk
> tests, and when IO sizes are small in the everything-on-ssd tests).
>
> Newstore is changing daily so keep in mind that these results are almost
> assuredly going to change. An interesting area of investigation will be
> why sequential writes are slower than random writes, and whether or not
> we are being limited by rocksdb ingest speed and how.
>
> I've also uploaded a quick perf call-graph I grabbed during the
> "all-SSD" 32KB sequential write test to see if rocksdb was starving one
> of the cores, but found something that looks quite a bit different:
>
> http://nhm.ceph.com/newstore/newstore-5d96fe6-no_overlay.pdf
Oops, wrong link:
nhm.ceph.com/newstore/newstore_perf_report_32k_write_ssd.txt.gz
>
> Mark
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-04-29 0:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 23:25 newstore performance update Mark Nelson
2015-04-29 0:00 ` Venkateswara Rao Jujjuri
2015-04-29 0:07 ` Mark Nelson
2015-04-29 2:59 ` kernel neophyte
2015-04-29 4:31 ` Alexandre DERUMIER
2015-04-29 13:11 ` Mark Nelson
2015-04-29 13:08 ` Mark Nelson
2015-04-29 15:55 ` Chen, Xiaoxi
2015-04-29 19:06 ` Mark Nelson
2015-04-30 1:08 ` Chen, Xiaoxi
2015-04-29 0:00 ` Mark Nelson [this message]
2015-04-29 8:33 ` Chen, Xiaoxi
2015-04-29 13:20 ` Mark Nelson
2015-04-29 15:00 ` Chen, Xiaoxi
2015-04-29 16:38 ` Sage Weil
2015-04-30 13:21 ` Haomai Wang
2015-04-30 16:20 ` Sage Weil
2015-04-30 13:28 ` Mark Nelson
2015-04-30 14:02 ` Chen, Xiaoxi
2015-04-30 14:11 ` Mark Nelson
2015-04-30 18:09 ` Sage Weil
2015-05-01 14:48 ` Mark Nelson
2015-05-01 15:22 ` Chen, Xiaoxi
2015-05-02 0:33 ` Sage Weil
2015-05-04 17:50 ` Mark Nelson
2015-05-04 18:08 ` Sage Weil
2015-05-05 17:43 ` Mark Nelson
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=55401F2B.60206@redhat.com \
--to=mnelson@redhat.com \
--cc=ceph-devel@vger.kernel.org \
/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.