Re: [PATCH] rbd: add queuing delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 22, 2010 at 1:27 PM, Christian Brunner <chb@xxxxxx> wrote:
> On Tue, Jun 22, 2010 at 09:50:24PM +0200, Christian Brunner wrote:
>> > while running tests with qemu-io I've been experiencing a lot of
>> > messages when running a large writev request (several hundred MB in
>> > a single call):
>> >
>> > 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).
>> >
>> > What do you think about it?
>>
>> 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.

Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux