Re: [HACKERS] UPDATE performance degradation (6.5.1)

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To:
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] UPDATE performance degradation (6.5.1)
Date: 1999-07-27 13:58:20
Message-ID: Pine.GSO.3.96.SK.990727175308.29708I-100000@ra
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Probably I found the problem. After running my test, whiich became
very slow I looked at /usr/local/pgsql/data/base/discovery

-rw------- 1 postgres users 5070848 Jul 27 16:14 hits
-rw------- 1 postgres users 1409024 Jul 27 16:14 hits_pkey

This is for table with one row after a lot of updates.
Too much. vacuum analyze this table was a good medicine !
Is this a design problem ?

Regards,
Oleg

On Tue, 27 Jul 1999, Oleg Bartunov wrote:

> Date: Tue, 27 Jul 1999 12:51:07 +0400 (MSD)
> From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
> To: pgsql-hackers(at)postgreSQL(dot)org
> Subject: [HACKERS] UPDATE performance degradation (6.5.1)
>
> Hi,
>
> after I got DBIlogging work, I run several tests and noticed performance
> degradation when doing sequential updating of *one* row.
>
> I have 5 processes updated the same row. I use
> LOCK TABLE hits IN SHARE ROW EXCLUSIVE MODE
>
> When I run 200 requests I got about 16 req/sec, which is quite enough
> for my purposes. I expected the same speed if I just increase a number of
> requests, but it decreases. for 2000 requests I got about 10 req/sec
> and for 20,000 - about 2.5 req/sec !
> I see no reason for such performance degradation - no way to use
> postgres for logging in 24*7*365 Web-site. Probably this is very
> specific case when several processes updates only one row,
> but again, I see no reason for such big degradation.
> Table hits itself contains only 1 row !
> I'll try to elimanate httpd, perl in my test bench to test only
> postgres, I dont' have right now such a tool, probable someone
> already did this ? What tool I can use for testing concurrent update
>
> Regards,
> Oleg
>
>
> This is my home machine, Linux 2.2.10. postgres 6.5.1
> Load is about 2-2.5
>
> Typical output of ps:
>
> 11:21[om]:/usr/local/apache/logs>psg disc
> 1036 ? S 24:17 /usr/local/pgsql/bin/postgres localhost httpd discovery LOCK
> 1040 ? R 24:09 /usr/local/pgsql/bin/postgres localhost httpd discovery idle
> 1042 ? S 24:02 /usr/local/pgsql/bin/postgres localhost httpd discovery LOCK
> 1044 ? R 23:51 /usr/local/pgsql/bin/postgres localhost httpd discovery idle
> 1046 ? S 23:49 /usr/local/pgsql/bin/postgres localhost httpd discovery LOCK
> 1048 ? S 23:47 /usr/local/pgsql/bin/postgres localhost httpd discovery LOCK
>
> I see only one process with SELECT, this is what I expected when use
> IN SHARE ROW EXCLUSIVE MODE. Right ?
>
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
>
>

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-07-27 14:33:32 Re: [HACKERS] More on shared objects problem
Previous Message Ansley, Michael 1999-07-27 13:56:57 Late mail