Alle 17:00, venerdì 11 marzo 2005, Jens Axboe ha scritto:
> > It was after running bonnie++.
>
> Are you sure? It lists only 190 commands run since it initialized,
> that's basically nothing.
Yes I'm sure!
Isn't this number the MAX value ever samplef for "Current # commands on
controller"? It
On Fri, Mar 11 2005, Simone Piunno wrote:
> Alle 16:54, venerdì 11 marzo 2005, Jens Axboe ha scritto:
>
> > I'd guess that your problem is queueing, if you have a ton of pending
> > requests in the hardware it will take forever to get a new request
> > through. There's nothing the io scheduler
Alle 16:54, venerdì 11 marzo 2005, Jens Axboe ha scritto:
> I'd guess that your problem is queueing, if you have a ton of pending
> requests in the hardware it will take forever to get a new request
> through. There's nothing the io scheduler can do to help you there,
> really. The
On Fri, Mar 11 2005, Fabio Coatti wrote:
> Alle 16:16, venerdì 11 marzo 2005, Jens Axboe ha scritto:
> > On Fri, Mar 11 2005, Simone Piunno wrote:
> > > Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
> > > > echo t > /proc/sysrq-trigger
> > >
> > > Before killing bonnie:
> >
> > I'm
Alle 16:16, venerdì 11 marzo 2005, Jens Axboe ha scritto:
> On Fri, Mar 11 2005, Simone Piunno wrote:
> > Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
> > > echo t > /proc/sysrq-trigger
> >
> > Before killing bonnie:
>
> I'm guessing your problem is that bonnie dirtied tons of data
On Fri, Mar 11 2005, Simone Piunno wrote:
> Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
>
> > echo t > /proc/sysrq-trigger
>
> Before killing bonnie:
I'm guessing your problem is that bonnie dirtied tons of data before you
killed it, so it has to flush it out. If you run out of
>> >
>> > 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
Fabio Coatti wrote:
Alle 12:35, venerdì 11 marzo 2005, Denis Vlasenko ha scritto:
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
Alle 12:35, venerdì 11 marzo 2005, Denis Vlasenko ha scritto:
> >
> > 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
>
On Friday 11 March 2005 13:08, Simone Piunno wrote:
>
> 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
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:
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:
On Friday 11 March 2005 13:08, Simone Piunno wrote:
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
Alle 12:35, venerdì 11 marzo 2005, Denis Vlasenko ha scritto:
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
Fabio Coatti wrote:
Alle 12:35, venerdì 11 marzo 2005, Denis Vlasenko ha scritto:
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
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
On Fri, Mar 11 2005, Simone Piunno wrote:
Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
echo t /proc/sysrq-trigger
Before killing bonnie:
I'm guessing your problem is that bonnie dirtied tons of data before you
killed it, so it has to flush it out. If you run out of request
Alle 16:16, venerdì 11 marzo 2005, Jens Axboe ha scritto:
On Fri, Mar 11 2005, Simone Piunno wrote:
Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
echo t /proc/sysrq-trigger
Before killing bonnie:
I'm guessing your problem is that bonnie dirtied tons of data before you
On Fri, Mar 11 2005, Fabio Coatti wrote:
Alle 16:16, venerdì 11 marzo 2005, Jens Axboe ha scritto:
On Fri, Mar 11 2005, Simone Piunno wrote:
Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
echo t /proc/sysrq-trigger
Before killing bonnie:
I'm guessing your problem
Alle 16:54, venerdì 11 marzo 2005, Jens Axboe ha scritto:
I'd guess that your problem is queueing, if you have a ton of pending
requests in the hardware it will take forever to get a new request
through. There's nothing the io scheduler can do to help you there,
really. The
On Fri, Mar 11 2005, Simone Piunno wrote:
Alle 16:54, venerdì 11 marzo 2005, Jens Axboe ha scritto:
I'd guess that your problem is queueing, if you have a ton of pending
requests in the hardware it will take forever to get a new request
through. There's nothing the io scheduler can do to
Alle 17:00, venerdì 11 marzo 2005, Jens Axboe ha scritto:
It was after running bonnie++.
Are you sure? It lists only 190 commands run since it initialized,
that's basically nothing.
Yes I'm sure!
Isn't this number the MAX value ever samplef for Current # commands on
controller? It
22 matches
Mail list logo
