public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Sun, 22 Aug 2004 17:43:18 +0200	[thread overview]
Message-ID: <003f01c4885e$bf688d20$0600640a@guendalin> (raw)
In-Reply-To: <4127F7FD.5060804@yahoo.com.au>

Nick Piggin wrote:

> 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.

Created a big file:
 -rw-r--r--    1 root     root     1073740800 Aug 22 17:22 /testfile

time dd if=/testfile of=/dev/null gives:
On 2.6.8.1 ext3 raid
  real    0m11.493s
  user    0m0.657s
  sys     0m2.796s
On 2.6.8.1 xfs:
  real    0m18.214s
  user    0m0.697s
  sys     0m3.778s

Tests on 2.6.8.1 has been done with elevator=deadline

On 2.4.7 ext3 raid:
  real    0m20.513s
  user    0m0.704s
  sys     0m2.626s

On 2.4.7 xfs:
  real    0m28.414s
  user    0m0.686s
  sys     0m3.320s

So it seems that read access to disks is better on 2.6 tree.


> Regarding your worse non-RAID XFS database results, try 
> booting 2.6 with elevator=deadline and test again. 

This are results obtained with deadline:

filippo:~# dmesg |grep deadline
Using deadline io scheduler

A) [schema]
2b) 2.6.8.1 and xfs
  real    0m0.551s
  user    0m0.027s
  sys     0m0.012s

B) [Importing data]
2b) 2.6.8.1 and xfs
  real    1m1.474s
  user    0m3.281s
  sys     0m1.505s

It seems performance does not get better.

I have tried other tests:
With ext2 FS results are: 



A)
1c) 2.4.7 and ext2 (no raid)
  real    0m0.625s
  user    0m0.028s
  sys     0m0.018s
2c) 2.6.8.1 and ext2 (no raid)
  real    0m1.667s
  user    0m0.026s
  sys     0m0.010s
B)
1c) 2.4.7 and ext2 (no raid)
  real    1m28.542s
  user    0m3.232s
  sys     0m1.384s
2c) 2.6.8.1 and ext2
  real    1m30.200s
  user    0m3.304s
  sys     0m1.461s

Still, even with ext2, 2.4.7 performs much better with postgres (and
likely other databases).

I have no idea nor no clue how to improve this.

> If yes, 
> are you using queueing (TCQ) on your disks?

How can i check ?


 Massimo Cetra



  reply	other threads:[~2004-08-22 15:43 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 [this message]
2004-08-22 16:54   ` Massimo Cetra
2004-08-23 11:46   ` Massimo Cetra
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='003f01c4885e$bf688d20$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