Re: 7.2 is slow?

From: Jussi Mikkola <jussi(dot)mikkola(at)bonware(dot)com>
To: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)tm(dot)ee>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, inxc(at)itmeedia(dot)ee
Subject: Re: 7.2 is slow?
Date: 2001-12-19 11:00:03
Message-ID: 3C207332.28B28249@bonware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I haven't tested with the new 7.2 betas, but here are some results from
7.1.

We have a developement computer, IBM x series 250, with 4 processors
(PIII Xeon 750Mhz), 1 Gb memory and 2SCSI disks (u160).

The software is writing new rows to a table, and after this it reads the
id from that row. There are currently about 50 connections doing the
same thing.

When I run this test with the Redhat 7.1, with SMP kernel, I noticed, that
the
processors are more than 90% idle. Disks utilisation is not the
bottleneck either, since there is very low disk usage. Some data is
written to disks every 4-5 seconds. Fsync is turned of. In transactions,
this means about 200 inserted rows per second. The software that is used
to give the feed, is capable of several thousand rows per second.

Okey, so I tried this also with the same computer, but using the not SMP
supported kernel. So only with one processor. The result was about 600
rows per second. The configuration file was unchanged. Now, the
processor is about 100% utilized.

I didn't find any parameters that should help in this, but if you have a
version of 7.2 that you would like to get information about, let me
know, so I'll test.

Jussi

Zeugswetter Andreas SB SD wrote:

> > I think you are right that the difference between 7.1 and 7.2 may have
> > more to do with the change in VACUUM strategy than anything else. Could
> > you retry the test after changing all the "vacuum" commands in pgbench.c
> > to "vacuum full"?
>
> Might there also be a difference in chosen query plans ?
> Wasn't 7.1 more willing to choose an index over seq scan,
> even though the scan would be faster in the single user case ?
> Or was that change after 7.0 ?
>
> The seq scan would be slower that the index in the case of
> many concurrent accesses.
>
> Andreas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

--
Jussi Mikkola Project Manager
Bonware Oy gsm +358 40 830 7561
Tekniikantie 12 tel +358 9 2517 5570
02150 Espoo fax +358 9 2517 5571
Finland www.bonware.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2001-12-19 11:00:23 Re: Thoughts on the location of configuration files, how about this:
Previous Message Daniel Kalchev 2001-12-19 10:53:54 Re: Thoughts on the location of configuration files, how