From: "Massimo Cetra" <mcetra@navynet.it>
To: "'Nick Piggin'" <nickpiggin@yahoo.com.au>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: Production comparison between 2.4.27 and 2.6.8.1
Date: Mon, 23 Aug 2004 13:46:33 +0200 [thread overview]
Message-ID: <000001c48906$d70bf270$0600640a@guendalin> (raw)
In-Reply-To: <4127F7FD.5060804@yahoo.com.au>
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
> everithing in
> > 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
> has better
> > performance if compared to 2.6 and the difference, in my
> opinion, is
> > 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 2.6.8.1-mm and 2.6.8.1-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
with high
disk performance requirements should do so, in fact.
If you see unusual performance characteristics of your disk systems, or
you
see big performance regressions versus the deadline scheduler, please
email
me. Database users don't bother unless you're willing to test a lot of
patches
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
server tasks.
Is this issue being analyzed ?
Should we hope in an improvement sometime?
Or I'll have to use 2.4 to have good performance ?
Max
next prev parent reply other threads:[~2004-08-23 11:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-21 17:25 Production comparison between 2.4.27 and 2.6.8.1 Massimo Cetra
2004-08-22 1:33 ` Nick Piggin
2004-08-22 15:43 ` Massimo Cetra
2004-08-22 16:54 ` Massimo Cetra
2004-08-23 11:46 ` Massimo Cetra [this message]
2004-08-24 2:05 ` Nick Piggin
2004-08-24 14:15 ` Massimo Cetra
2004-08-25 2:28 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2004-08-25 7:23 rwhron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001c48906$d70bf270$0600640a@guendalin' \
--to=mcetra@navynet.it \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox