On Wed, Aug 19, 2009 at 07:29:07PM -0700, Drew wrote: > > The problem is while Areca is doing the flushing _all_ IOs are really slow, > > including the other raid-10 array for the OS, which uses totally separate physical disks. > > > > Opening another shell in screen takes at least 30 seconds, starting "top" > > takes forever etc.. > > > > While Areca is flushing the caches (and all the IOs are slow), "iostat 1" > > doesn't show any "leftover" IOs from the benchmark. So the benchmark was > > really using direct IO, bypassing kernel caches. > > > > I tried with different io-schedulers (cfq,deadline,noop) but they didn't > > have big effect.. which makes sense, since the OS/kernel is not doing any > > big IO when the 'stalling' happens. > > > > Is there some way to make Areca NOT use all cpu-power for cache flushing? > > Is top showing 100% cpu usage? > No, cpu usage is almost 0%. I was talking about cpu-usage of _Areca_ controller. When the disktest-benchmark ends, Linux cpu usage goes to 0%, and there's no IO anymore (checked with "iostat 1"). But _Areca_ is still flushing it's caches, and all the IO will be slow, even when there's no load in _Linux_. -- Pasi > It wouldn't surprise me if the Areca's internal bus / processor is > getting swamped. With the RAID60 chewing through two PQ calculations > over 14 disks I'd expect the performance of other arrays on the > controller would take a hit > > I've seen similar symptoms when moving massive amounts of data between > disks on my servers. IO maxes out the bus, system responsiveness goes > down as evidenced by slowly loading apps, and top still shows minimal > CPU usage. > > > -- > Drew > > "Nothing in life is to be feared. It is only to be understood." > --Marie Curie -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
