From: Markus Roeffen (markus.roeffen_at_iws.uni-stuttgart.de)
Date: Tue Apr 03 2007 - 09:39:15 CEST
Message-ID: <461204A3.4080700@iws.uni-stuttgart.de> Date: Tue, 03 Apr 2007 09:39:15 +0200 From: Markus Roeffen <markus.roeffen@iws.uni-stuttgart.de> Subject: Re: Antw: Re: [suse-sles-e] Re: catastrophic disk-performance on SLES10 with SATA drives
Hello Andreas,
we've run a few benchmarks and the result are similar.
On the internal SCSI-RAID (RAID 1) we have made the same experiences. As
soon as the data grows big the performance decreases.
server:~ # time dd if=/dev/zero of=/frei/test bs=16k count=100000
100000+0 records in
100000+0 records out
1638400000 bytes (1.6 GB) copied, 48.4464 seconds, 33.8 MB/s
real 0m48.789s
user 0m0.060s
sys 0m3.404s
server:~ # time dd if=/dev/zero of=/frei/test bs=16k count=10000
10000+0 records in
10000+0 records out
163840000 bytes (164 MB) copied, 0.297434 seconds, 551 MB/s
On our external RAID (RAID 5) the results are different. The peformance
is poor in both cases.
server:~ # time dd if=/dev/zero of=/home/jan/test bs=16k count=10000
10000+0 records in
10000+0 records out
163840000 bytes (164 MB) copied, 4.13542 seconds, 39.6 MB/s
real 0m6.016s
user 0m0.000s
sys 0m0.476s
server:~ # time dd if=/dev/zero of=/home/jan/test bs=16k count=100000
100000+0 records in
100000+0 records out
1638400000 bytes (1.6 GB) copied, 43.4186 seconds, 37.7 MB/s
real 0m43.457s
user 0m0.048s
sys 0m4.412s
Do you use an internal or an external RAID?
I've got news from HP, too. They wanted us to check our server with a
special version of cfg2html-linux (cfg2html-linux HP Proliant Version
1.24). The results have been mailed to HP, so maybe we'll get an answer
this week.
Best regards
Markus
matilda matilda wrote:
> 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 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
This archive was generated by hypermail 2.1.7 : Tue Apr 03 2007 - 11:43:20 CEST