[<prev] [next>] [day] [month] [year] [list]
Message-ID: <44D09125.1090901@conterra.de>
Date: Wed, 02 Aug 2006 13:48:53 +0200
From: Dieter Stüken <stueken@...terra.de>
To: linux-kernel@...r.kernel.org
Subject: Re: 3ware disk latency?
Jan Kasprzak wrote:
> dean gaudet wrote:
>
> : my suspicion is the 3ware lacks any sort of "fairness" in its sharing of
> : buffer space between multiple units on the same controller. and by
> : disabling the write caching it limits the amount of controller memory that
> : the busy disk can consume.
>
> Hmm, do you have a battery backup unit for 9550sx? I don't,
> and the 3ware BIOS does not even allow me to enable write caching without it.
> So I don't think the write caching on the controller side is related
> to my problem.
>
> I have been able to improve the latency by upgrading the firmware
> to the newest release (wow, they even have a firmware updating utility
> for Linux!).
>
I just discovered this thread, as I have similar problems
with my 9550sx. I will perform a firmware upgrade tomorrow,
hope that helps. I have a BBU installed, thus my controller
should be able to handle concurrent requests for read and write.
But I also want to understand, what causes this problems. I have
several VMWare servers running on a RAID5 setup. Several times
a day I observe periods of excessive IO-waits and the guest systems
become unusable for a while. I may use "top", but all I see is
the high iowait and 4 idling processors. I not even found which
processes are actually waiting. Is there a way to trace,
which IO requests are pending, their block numbers and the
process ids that issued the requests? I found there are different
IO scheduler available, which have access to all these informations.
Is it possible to plug in some debug module to trace the IO
traffic similar to "strace" for processes?
Dieter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists