Re: x206-x225

From: "Daniel Blaisdell" <lunk(dot)djedi(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: x206-x225
Date: 2006-03-10 14:27:48
Message-ID: f2af156d0603100627j39303849uc0e17d3ff468b0f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

The primary slow down is probably between your system bus from main memory
to your disk storage. If you notice from your statistics that the select
statements are very close. This is because all the data you need is already
in system memory. The primary bottle neck is probably disk I/O. Scsi will
always be faster than ATA. Scsi devices have dedicated hardware for getting
data to and from the disc to the main system bus without requiring a trip
through the CPU.

You may be able to speed up the ata disc by enabling DMA by using hdparm.

hdparm -d1 /dev/hda (or whatever your device is)

-Daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBEEYzX9SJ2nhowvKERAoiFAKCLR+7a7ReZ2mjjPjpONHLGIQD1SgCeNNON
V1kbyATIFVPWuf1W6Ji0IFg=
=5Msr
-----END PGP SIGNATURE-----

On 3/10/06, Richard Huxton <dev(at)archonet(dot)com> wrote:
>
> H.J. Sanders wrote:
> > X206 IBM X226
> > ---------------------- -------------------
> > processor Pentium 4 3.2
> > Ghz Xeon 3.0 Ghz
> > main memory 1.25
> > GB 4 GB
> > discs 2 x SCSI RAID1 10000RPM
> > 1 x ATA 7200 RPM
>
> Noting that the SCSI discs are on the *slower* machine.
>
> > Time at X206 Time at X226
> > -------------------- ------------------
> > insert record (1 to 10000) 6 sec. 41 sec.
> > select record (1 to 10000) 4 4
> > delete record (1 to 10000) 6 41
> >
> >
> > This is ofcourse a totally unexpected results (you should think off the
> > opposite).
>
> Your ATA disk is lying about disk caching being turned off. Assuming
> each insert is in a separate transaction, then it's not going to do
> 10,000 / 6 = 1667 transactions/sec - that's faster than it's rotational
> speed.
>
> > Funny is that the select time is the same for both machines.
>
> Because you're limited by the speed to read from RAM.
>
> By the way - these sort of tests are pretty much meaningless in any
> practical terms.
> --
> Richard Huxton
> Archonet Ltd
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Hakan Kocaman 2006-03-10 14:32:19 Re: Hanging queries on dual CPU windows
Previous Message Jan de Visser 2006-03-10 14:03:14 Re: Hanging queries on dual CPU windows