All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brunner <chb@muc.de>
To: ceph-devel@vger.kernel.org
Subject: Re: [PATCH] rbd: add queuing delay
Date: Sun, 27 Jun 2010 23:05:00 +0200	[thread overview]
Message-ID: <20100627210500.GB1568@chb-desktop> (raw)
In-Reply-To: <AANLkTilzf9GqS4Nqyz02IH59Wyb28gy5ojgxDU78CWsK@mail.gmail.com>

> >> > 10.06.20 22:10:07.337108 b67dcb70 client4136.objecter  pg 3.437e on [0] is laggy: 33
> >> > 10.06.20 22:10:07.337708 b67dcb70 client4136.objecter  pg 3.2553 on [0] is laggy: 19
> >> > [...]
> >> >
> >> > Everything is working fine, though. I think that the large number of
> >> > queued requests is the cause for this behaviour and I would propose to
> >> > delay futher requests (see attached patch).
> >>
> >> It seems that the osd is lagging behind. The usleep might work for you
> >> as you avoid the pressure, but it's also somewhat random and will
> >> probably hurt performance on other setups. I'd rather see a
> >> configurable solution that lets you specify a total in-flight bytes or
> >> some other resizable window scheme.
> >
> > I'm not sure if I understand what "lagging behind" means. If the in-flight
> > bytes are the sum of all requests in the queue, a solution could look like
> > this (although it isn't configurable yet).
> >
> The problem is that the sleep will lead to having the osd being
> underutilized in certain configurations. What you probably need here
> is some mechanism that keeps feeding the osd with pending data
> whenever old data has been cleared. E.g., make use of the async
> callbacks to wake up the sender whenever the amount of pending
> outgoing data has fell below some threshold.

Do you mean replacing the sleep with something like a futex? 

When thinking about this a little bit more I'm not sure if doing this in
the client is the right way to handle this. The client has no way to 
judge if the delay is caused by a general high load or by a single slow osd.
Maybe it would be better if libraos could notify the client to slow down?

Christian
--
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:[~2010-06-27 21:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-20 20:44 [PATCH] rbd: add queuing delay Christian Brunner
2010-06-21 23:52 ` Yehuda Sadeh Weinraub
2010-06-22 20:27   ` Christian Brunner
2010-06-22 21:03     ` Yehuda Sadeh Weinraub
2010-06-27 21:05       ` Christian Brunner [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=20100627210500.GB1568@chb-desktop \
    --to=chb@muc.de \
    --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.