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?
next prev parent 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.