Nick Piggin wrote:
It is my first experience with 2.6 branch kernels, because
i am trying
to figure out if the tree is performing well to switch
production, so my ideas may be wrong...
Raid tests may be faked because of the overhead caused by
md sync (and
probably raid is better on 2.6). However it seems that libsata has better performance on 2.4 (hdparm) xfs tests shows that 2.4
performance if compared to 2.6 and the difference, in my
not linked on libsata better performance.
What is your opinion ?
What can I try to improve performance ?
I wouldn't worry too much about hdparm measurements. If you want to test the streaming throughput of the disk, run dd if=big-file of=/dev/null or a large write+sync.
Regarding your worse non-RAID XFS database results, try booting 2.6 with elevator=deadline and test again. If yes, are you using queueing (TCQ) on your disks?
Tried even with 188.8.131.52-mm and 184.108.40.206-ck
No performance improvement.
From Documentation/block/as-iosched.txt i read:
Attention! Database servers, especially those using "TCQ" disks should
investigate performance with the 'deadline' IO scheduler. Any system
disk performance requirements should do so, in fact.
If you see unusual performance characteristics of your disk systems, or
see big performance regressions versus the deadline scheduler, please
me. Database users don't bother unless you're willing to test a lot of
from me ;) its a known issue.
So it's probably known that 2.6 performance with databases and heavy HD
access is an issue.
I don't believe that 2.6.x tree is performing as well as 2.4.x(-lck) on
Is this issue being analyzed ?
Should we hope in an improvement sometime?
Or I'll have to use 2.4 to have good performance ?