All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Massimo Cetra <mcetra@navynet.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Production comparison between 2.4.27 and 2.6.8.1
Date: Sun, 22 Aug 2004 11:33:49 +1000	[thread overview]
Message-ID: <4127F7FD.5060804@yahoo.com.au> (raw)
In-Reply-To: <004f01c487a3$e8f8e060$0600640a@guendalin>

Massimo Cetra wrote:
> Hi everybody.
> 
> #***********************************************************
> 
> Environment:
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 6
> model           : 10
> model name      : AMD Athlon(tm) XP 3000+
> stepping        : 0
> cpu MHz         : 2091.477
> 
> #***********************************************************
>              total       used       free     shared    buffers
> cached
> Mem:       1030844     258500     772344          0      36924
> 167092
> -/+ buffers/cache:      54484     976360
> Swap:      2056304          0    2056304
> 
> #***********************************************************
> # lspci
> 0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different
> version?) (rev c1)
> 0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1
> (rev c1)
> 0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4
> (rev c1)
> 0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3
> (rev c1)
> 0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2
> (rev c1)
> 0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5
> (rev c1)
> 0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
> 0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
> 0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller
> (rev a4)
> 0000:00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller
> (rev a4)
> 0000:00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller
> (rev a4)
> 0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
> Controller (rev a1)
> 0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge
> (rev a3)
> 0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
> 0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
> 0000:01:04.0 Ethernet controller: Marvell Technology Group Ltd. Yukon
> Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13)
> 0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD
> Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev
> 02)
> 0000:03:00.0 VGA compatible controller: nVidia Corporation NV11
> [GeForce2 MX/MX 400] (rev b2)
> 
> #***********************************************************
> 
> Distro is Debian Woody with all necessary packages backported in order
> to have 2.6 working.
> 
> I used postgres 7.4.3 to make some tests on a server which will go in
> producton in a short time.
> 
> The test was really simple:
> 
> dropdb mydb
> createdb mydb
> time psql -U blus mydb <schema.sql
> time psql -U blus mydb <data.sql
> 
> #***********************************************************
> 
> I tried both 2.6.8.1 vanilla and 2.4.7 with -lck patches applied and run
> the same test changing kernels.
> 
> Tests were run:
> - on a raid1 partition on 2 serial Ata disks	(ext3) [software raid)
> - on a non raid partition on /dev/sda0 (xfs)
> 
> (only postgres data has been switched from raid-ext3 to xfs)
> 
> 
> My purpose was merely have a difference of time between the 2 kernels in
> performing that task.
> 
> Case 1a is 2.4.27-lck1 with raid1 ext3
> Case 1b is 2.4.27-lck1 without raid on xfs
> Case 2a is 2.6.8.1 with raid1 ext3
> Case 2b is 2.6.8.1 without raid on xfs
> Results were:
> 
> A) for creating the schema (which involves creating tables and indexes)
> 1a:
>   real    0m1.312s
>   user    0m0.030s
>   sys     0m0.008s
> 1b:
>   real    0m0.508s
>   user    0m0.024s
>   sys     0m0.012s
> 2a:
>   real    0m0.941s
>   user    0m0.025s
>   sys     0m0.010s
> 2b:
>   real    0m0.560s
>   user    0m0.024s
>   sys     0m0.005s
> 
> B) to import the data (which implies both writing data to disk and
> recalculating indexes)
> 1a:
>   real    4m12.757s
>   user    0m3.376s
>   sys     0m1.700s
> 1b:
>   real    1m0.467s
>   user    0m3.290s
>   sys     0m1.646s
> 2a:
>   real    2m42.861s
>   user    0m3.590s
>   sys     0m1.523s
> 2b:
>   real    1m30.746s
>   user    0m3.255s
>   sys     0m1.501s
> 
> #**********************************************
> HDPARM shows:
> # hdparm -v
> hdparm - get/set hard disk parameters - version v5.5
> 
> 2.4.7:
> /dev/sda:
>  Timing buffer-cache reads:   2188 MB in  2.00 seconds = 1094.00 MB/sec
>  Timing buffered disk reads:  164 MB in  3.02 seconds =  54.34 MB/sec
> 
> 2.6.8.1:
> /dev/sda:
>  Timing buffer-cache reads:   2176 MB in  2.00 seconds = 1087.08 MB/sec
>  Timing buffered disk reads:  136 MB in  3.04 seconds =  44.77 MB/sec
> 
> #**********************************************
> 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?

  reply	other threads:[~2004-08-22  1:36 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 [this message]
2004-08-22 15:43   ` Massimo Cetra
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=4127F7FD.5060804@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcetra@navynet.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.