All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sage Weil <sweil@redhat.com>
To: Somnath Roy <Somnath.Roy@sandisk.com>
Cc: Mark Nelson <mnelson@redhat.com>,
	Ceph Development <ceph-devel@vger.kernel.org>
Subject: RE: Bluestore-Performance regression in the latest master
Date: Fri, 7 Oct 2016 13:17:31 +0000 (UTC)	[thread overview]
Message-ID: <alpine.DEB.2.11.1610071317080.18626@piezo.us.to> (raw)
In-Reply-To: <BY2PR02MB396C9E7D9CB33A1CDD204AAF4C70@BY2PR02MB396.namprd02.prod.outlook.com>

On Thu, 6 Oct 2016, Somnath Roy wrote:
> Mark,
> If you see the graph in the below link , you will see it is choppy and faster till 1 hour , beyond that it is degrading fast..
> If you see the left side graph that is holding the constant performance throughout for 10 hour (old master)
> Have you checked the latency with the shorter run with the latest master as well ? Even with the shorter run it is 4X more latency (even though aggregated throughput is bit more) for me..
> Anyways, I am trying to reproduce this in another setup just to eliminate HW issues in case..

You mentioned yesterday you had tried switching the rocksdb compaction 
mode.. could that be it?

sage

> 
> Thanks & Regards
> Somnath
> 
> -----Original Message-----
> From: Mark Nelson [mailto:mnelson@redhat.com] 
> Sent: Thursday, October 06, 2016 3:13 PM
> To: Somnath Roy; Sage Weil
> Cc: Ceph Development
> Subject: Re: Bluestore-Performance regression in the latest master
> 
> This is bluestore specific?  My guess is the cache sizes as well. 
> Bluestore on master is actually significantly faster for me in all of the tests I've thrown at it vs earlier this week, but my onode hit rate is still "decent".
> 
> I still see higher performance by increasing the min alloc size to 16k and then bumping up the onode cache size a bit with the memory savings.
> 
> Mark
> 
> On 10/06/2016 04:52 PM, Somnath Roy wrote:
> > I have increased the cache size at the point where it is started swapping after 30 min run or so , but, still I am seeing the huge latest difference.
> > Will try to find out what went wrong recently..
> >
> > Thanks & Regards
> > Somnath
> >
> > -----Original Message-----
> > From: Sage Weil [mailto:sweil@redhat.com]
> > Sent: Thursday, October 06, 2016 2:17 PM
> > To: Somnath Roy
> > Cc: Ceph Development
> > Subject: Re: Bluestore-Performance regression in the latest master
> >
> > On Thu, 6 Oct 2016, Somnath Roy wrote:
> >> Sage,
> >> I am seeing the performance with the latest master is not stable compare to 3 days old master. The peak performance is higher but it is jumping up and down. Analyzing further I suspect recent cache changes has an impact. While the performance is high , I am seeing lower disk reads (probably because of cache hits) , but the low point is much lower when it is missing the cache probably. You were saying on the standup about adding buffers in the cache in the write path , is that merged into the master ?
> >
> > The buffered writes by default is not merged:
> >
> > https://github.com/ceph/ceph/pull/11301
> >
> >> The following pull request for cache that got merged seems reasonable.
> >>
> >> https://github.com/ceph/ceph/pull/11295
> >
> > This cut the cache size down by 4x, plus whatever your sharding factor is/was.  Could that be it?
> >
> >> Any hunch what is causing this degradation recently ? Otherwise, I 
> >> need to dig down to find that out :-(
> >>
> >> See the graph in the following link for the performance difference.
> >>
> >> https://docs.google.com/spreadsheets/d/1JO3FaBbfT5jEdyYGB8EhHnAl5bAHe
> >> 0
> >> 6ojLE85mPzsK4/edit?usp=sharing
> >>
> >> The left side graph is with old master and right one is with latest master..Old one I ran for 10 hour and latest master I ran it for 2 hours.
> >> The new one has *4X more* latency as well..
> >
> > My guess is the cache size.  I can't think of what else would have much of an effect on latency...
> >
> > s
> > PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
> > --
> > 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
> >
> --
> 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
> 
> 

  reply	other threads:[~2016-10-07 13:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 21:04 Bluestore-Performance regression in the latest master Somnath Roy
2016-10-06 21:16 ` Sage Weil
2016-10-06 21:52   ` Somnath Roy
2016-10-06 22:12     ` Mark Nelson
2016-10-06 23:04       ` Somnath Roy
2016-10-07 13:17         ` Sage Weil [this message]
2016-10-07 16:20           ` Somnath Roy
2016-10-07 22:16           ` Somnath Roy

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=alpine.DEB.2.11.1610071317080.18626@piezo.us.to \
    --to=sweil@redhat.com \
    --cc=Somnath.Roy@sandisk.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=mnelson@redhat.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.