Re: Linux File system and Oracle setup

Noons wrote:
> TCQ? That is more relevant at controller level, isn't it?
> Why would the anticipatory IO scheduler bother with it when
> it'd be a lot better handled by things like SANs? Got a feeling
> someone in Loonicks-land is trying to be too smart again.
>
> Why don't they just concentrate in providing efficient aio
> and let the complexities of disk scheduling be handled in
> much better places? There *IS* a reason why mainframes eat all
> other environments in IO throughput: they concentrate only on
> what's important, instead of flights of fancy...
>

You need to tell to Jens Axboe and Nick Piggin. ;)

>> And again:
>>
>> "For some workloads the anticipatory scheduler is around 10% slower
>> than deadline. Most notably, database workloads which seek all
over the
>> disk performing reads and synchronous writes. Database folks will
>> likely
>> want to boot with elevator=deadline to get that last bit of
>> performance back."
>
>
> Holy Macka! Just what we needed: nobody knows for sure
> what happens when! I wonder which workload doesn't seek
> "all over the disk"? :)
>

And the interaction with read-ahead? A tuning hell!

> Thanks for the useful info. I feel another round of reading
> internal stuff coming up. What do you reckon: kerneltrap?
>

Linux kernel mailing list... and of course the old good kerneltrap (one of the most useful RSS feed I check)!

Waiting the next release of "Understanding the Linux Kernel", the best documentation on the scheduler is provided with the kernel sources or readeable online at www.ibiblio.org.

If you are going to test the different schedulers with oracle and several workloads make me know.

-- 
Fabrizio Magni

fabrizio.magni_at_mycontinent.com

replace mycontinent with europe