From: matilda matilda (matilda_at_grandel.de)
Date: Mon Apr 02 2007 - 15:02:06 CEST
Message-Id: <46111AF2.117B.0044.0@grandel.de> Date: Mon, 02 Apr 2007 15:02:06 +0200 From: "matilda matilda" <matilda@grandel.de> Subject: Antw: SPAM: Re: [suse-sles-e] Re: catastrophic disk-performance on SLES10 with SATA drives
Hi all,
we experienced two main problems:
1) As soon as we have write requests for large files in combination with regular read requests performance
is suffering dramatically.
2) We have a second problem and I would be interested to see, if other people with that controller have
the same phaenomena. I never got a satsifying answer from Novell support. (SLES9 SP3, I'm also interested in
seeing that with SLES 10).
When you start the command 'time dd if=/dev/zero of=data.out bs=8192 count=1310720' (10 737 418 240 Bytes,
10GB, something much bigger than physical memory) everything seems fine. As soon as data copuldn't be stored to
memory (dirty buffers) performance of the whole system is decreasing dramatically. cat /proc/loadavg shows a
increase of avarage system load of approx. 10 (!). Shell is very very unresponsive and you have suddenly
very much [pdflush] kernel threads compared to the situation when you started the test.
As far as I know/read pdflush kernel thread is responsible to write the dirty buffers back to physical storage.
And this thread tries to do this as quick as possible. BUT: In my opinion it does not make sense that so many
of them try to write to the very same pyhsical disk. It will not be faster because the "spindle" is the
bottleneck. If we try the very same on a physical device not controlled by cciss driver we never see such
a big increase of [pdflush] threads. In this case system behaves as I expect it.
Any way, the system should be responsive as the processor has nothing to do but waiting on the blocks written
to disk, but the system's performance is going down dramatically. I don't understand this behaviour.
At the moment it's the best local DOS-attack you can think of. :-))
Would someone please make such test? It's rather simple and would be very interesting.
Thank you in advance
Andreas Mock
>>> Markus Roeffen <markus.roeffen@iws.uni-stuttgart.de> 02.04.2007 11:29 >>>
Hi Andreas,
hi all,
thanks for posting your experience in the mailinglist.
It seems that you are right. There are some people who have difficulties
with the SmartArray-Controller on HP ProLiant DL360 G4p.
Our controller is a SmartArray-Controller 6i with latest firmware.
I've got news from the HP support team. HP suggested us to buy an
additional module for the SmartArray Controller:
HP Battery Backed Write Cache Enabler Kit - für ProLiant
for Smart Array 6i: optional 128MB BBWC
According to HP there are more options with this module in the HP Array
Configuration Utility panel available (Read/write IO cache ratio).
Has anyone on this mailinglist experience with the BBWC module? Could
this module solve our problems?
Best regards
Markus
matilda matilda wrote:
> Hi all, hi Heiko,
>
> it's really interesting to hear that there are more people out there
> being not too satisfied by the I/O-Performance of the SmartArray-Controller.
> Is it a SmartArray-Controller you're talking about?
> We're using it with SLES9 and have/had problems in certain circumstances.
>
> Would like to heare if you're also talking about the SmartArray-Controller.
>
> Best regards
> Andreas Mock
>
-- ------------------------------- Markus Roeffen Institut für Wasserbau IWS Universität Stuttgart Pfaffenwaldring 61 70569 Stuttgart Tel: +49(0)711/685-67010 Fax: +49(0)711/685-67020 Mail: markus.roeffen@iws.uni-stuttgart.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com For additional commands, e-mail: suse-sles-e-help@suse.com --------------------------------------------------------------------- To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Mon Apr 02 2007 - 17:06:45 CEST