All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Bashkirtsev <vladimir@bashkirtsev.com>
To: Josh Durgin <josh.durgin@inktank.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: Poor read performance in KVM
Date: Fri, 20 Jul 2012 15:01:43 +0930	[thread overview]
Message-ID: <5008ED3F.4080203@bashkirtsev.com> (raw)
In-Reply-To: <50085518.80507@inktank.com>

> Yes, they can hold up reads to the same object. Depending on where 
> they're stuck, they may be blocking other requests as well if they're
> e.g. taking up all the filestore threads. Waiting for subops means
> they're waiting for replicas to acknowledge the write and commit it to
> disk. The real cause for slowness of those ops is the replicas. If you
> enable 'debug osd = 25', 'filestore = 25', and 'debug journal = 20' you
> can trace through the logs to see exactly what's happening with the
> subops for those requests.
Looks like I hit exactly the same issue as described in "Slow request 
warnings on 0.48" but from different angle. As our client has run mysql 
updates performance started to degrade across the cluster bringing the 
rest of VMs to standstill and producing incredible latency. At some 
point slow request warnings started to pop up and now it seems I cannot 
get rid of them at all: I have shut down all clients, all ceph 
subsystems, restarted everything and it is back to the same behaviour - 
slow request warnings.

Before rebuilding osds I will enable debug as you suggested in attempt 
to find underlying issue. Then will rebuild osds as a measure of last 
resort to make sure that indeed osds causing the issue.

  reply	other threads:[~2012-07-20  5:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-15 13:13 Poor read performance in KVM Vladimir Bashkirtsev
2012-07-16  6:16 ` Josh Durgin
2012-07-18  5:46   ` Vladimir Bashkirtsev
2012-07-18 15:27     ` Josh Durgin
2012-07-19 10:46       ` Vladimir Bashkirtsev
2012-07-19 12:19       ` Vladimir Bashkirtsev
2012-07-19 15:52         ` Tommi Virtanen
2012-07-19 18:06           ` Calvin Morrow
2012-07-19 18:15             ` Mark Nelson
2012-07-20  5:24               ` Vladimir Bashkirtsev
2012-07-20  5:24             ` Vladimir Bashkirtsev
2012-07-20  5:20           ` Vladimir Bashkirtsev
     [not found]       ` <50080D9D.8010306@bashkirtsev.com>
2012-07-19 18:42         ` Josh Durgin
2012-07-20  5:31           ` Vladimir Bashkirtsev [this message]
2012-07-20 16:17           ` Vladimir Bashkirtsev
2012-07-20 16:42             ` Tommi Virtanen
2012-07-20 16:53               ` Mark Nelson
2012-07-20 16:53               ` Vladimir Bashkirtsev
2012-07-29 15:31               ` Vladimir Bashkirtsev
2012-07-29 16:13                 ` Mark Nelson
2012-07-18 15:34     ` Josh Durgin
2012-07-18  5:49   ` Vladimir Bashkirtsev
2012-07-18  5:51   ` Vladimir Bashkirtsev

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=5008ED3F.4080203@bashkirtsev.com \
    --to=vladimir@bashkirtsev.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=josh.durgin@inktank.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.