All of lore.kernel.org
 help / color / mirror / Atom feed
* bonnie++ uninterruptible under heavy I/O load
@ 2005-03-11 11:08 Simone Piunno
  2005-03-11 11:35 ` Denis Vlasenko
  0 siblings, 1 reply; 12+ messages in thread
From: Simone Piunno @ 2005-03-11 11:08 UTC (permalink / raw)
  To: linux-kernel, Fabio Coatti


Hello,

I'm testing a pair of new servers we just bought.
They are HP DL585 dual Opteron 844 with 8G RAM, RAID1 over 2x72G SCSI disks 
(HP CISS driver) and running 2.6.11.  In /proc/driver/cciss/cciss0 we have:

cciss0: HP Smart Array 5i Controller
Board ID: 0x40800e11
Firmware Version: 2.56
IRQ: 18
Logical drives: 1
Current Q depth: 0
Current # commands on controller: 0
Max Q depth since init: 6
Max # commands on controller since init: 190
Max SG entries since init: 31
cciss/c0d0:       72.83GB       RAID 1(1+0)

As a test, I'm running bonnie++ while two md5sum are checksumming /dev/zero.
I see 98% CPU is correctly allocated on the two md5sum processes, but when 
bonnie is in the "Writing intelligently phase" the system appears noticeably 
unresponsive (high latency) and bonnie and pdflush are uninterruptible almost 
all the time (D in top output).  If I try to kill -9 bonnie++, it goes on 
consuming I/O bandwith for several tens of seconds, before finally dieing.

Unresponsiveness is not 2.6.11 specific (we've seen the same thing on 2.6.10 
and 2.6.8), not I/O scheduler specific ("as" and "deadline" behave the same)
and not CPU/SMP specific (reproduced on single P4 HT and single P3), but only 
on these two DL585 servers we've seen bonnie++ resisting kill -9 for tens of 
seconds.

Of course on request I can provide any other useful info.
Any help is appreciated.

TIA,
  Simone Piunno

-- 
Simone Piunno, chief architect
Wireless Solutions SPA - DADA group
Europe HQ, via Castiglione 25 Bologna
web:www.dada-ws.com tel:+39512966811 fax:+39512966800

^ permalink raw reply	[flat|nested] 12+ messages in thread
* bonnie++ uninterruptible under heavy I/O load
@ 2005-03-11 14:24 Christian Guggenberger
  0 siblings, 0 replies; 12+ messages in thread
From: Christian Guggenberger @ 2005-03-11 14:24 UTC (permalink / raw)
  To: fabio.coatti; +Cc: vda, linux-kernel, simone.piunno

>> >
>> > Unresponsiveness is not 2.6.11 specific (we've seen the same thing on
>> > 2.6.10 and 2.6.8), not I/O scheduler specific ("as" and "deadline" behave
>> > the same) and not CPU/SMP specific (reproduced on single P4 HT and single
>> > P3), but only on these two DL585 servers we've seen bonnie++ resisting
>> > kill -9 for tens of seconds.
>> >
>> > Of course on request I can provide any other useful info.
>> > Any help is appreciated.
>>
>> I think Alt-SysRq-T will be interesting to see
>
>Unfortunately this machine is on a remote location, so we don't have access to 
>keyboard. In some days we will be able to have a report of Alt-SysRq-T, but 
>until this  of course we can provide any information that can be gathered on 
>a remote shell.

what about a: (if sysrq was enabled in the kernel)

echo "1" > /proc/sys/kernel/sysrq
echo "6" > /proc/sysrq-trigger
echo "t" > /proc/sysrq-trigger

 - Christian




^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2005-03-11 16:24 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-11 11:08 bonnie++ uninterruptible under heavy I/O load Simone Piunno
2005-03-11 11:35 ` Denis Vlasenko
2005-03-11 13:20   ` Fabio Coatti
2005-03-11 13:29     ` Baruch Even
2005-03-11 14:14       ` Simone Piunno
2005-03-11 15:16         ` Jens Axboe
2005-03-11 15:50           ` Fabio Coatti
2005-03-11 15:54             ` Jens Axboe
2005-03-11 15:58               ` Simone Piunno
2005-03-11 16:00                 ` Jens Axboe
2005-03-11 16:24                   ` Simone Piunno
  -- strict thread matches above, loose matches on Subject: below --
2005-03-11 14:24 Christian Guggenberger

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.