Variable (degrading) perfomance

From: Vladimir Stankovic <V(dot)Stankovic(at)city(dot)ac(dot)uk>
To: PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Variable (degrading) perfomance
Date: 2007-06-11 13:04:49
Message-ID: 466D4871.2090707@city.ac.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi all,

It seems that I have an issue with the performance of a PostgreSQL server.

I'm running write-intensive, TPC-C like tests. The workload consist of
150 to 200 thousand transactions. The performance varies dramatically,
between 5 and more than 9 hours (I don't have the exact figure for the
longest experiment). Initially the server is relatively fast. It
finishes the first batch of 50k transactions in an hour. This is
probably due to the fact that the database is RAM-resident during this
interval. As soon as the database grows bigger than the RAM the
performance, not surprisingly, degrades, because of the slow disks.
My problem is that the performance is rather variable, and to me
non-deterministic. A 150k test can finish in approx. 3h30mins but
conversely it can take more than 5h to complete.
Preferably I would like to see *steady-state* performance (where my
interpretation of the steady-state is that the average
throughput/response time does not change over time). Is the steady-state
achievable despite the MVCC and the inherent non-determinism between
experiments? What could be the reasons for the variable performance?
- misconfiguration of the PG parameters (e.g. autovacuum does not cope
with the dead tuples on the MVCC architecture)
- file fragmentation
- index bloat
- ???
The initial size of the database (actually the output of the 'du -h'
command) is ~ 400 MB. The size increases dramatically, somewhere between
600MB and 1.1GB

I have doubted the client application at some point too. However, other
server combinations using different DBMS exhibit steady state
performance.As a matter of fact when PG is paired with Firebird, through
statement-based replication middleware, the performance of the pair is
steady too.

The hardware configuration:
Client machine
- 1.5 GHz CPU Pentium 4
- 1GB Rambus RAM
- Seagate st340810a IDE disk (40GB), 5400 rpms

Server machine
- 1.5 GHz CPU Pentium 4
- 640 MB Rambus RAM
- Seagate Barracuda 7200.9 rpms
- Seagate st340810a IDE disk (40GB) - the WAL is stored on an ext2 partition

The Software configuration:
The client application is a multi-threaded Java client running on Win
2000 Pro sp4
The database server version is 8.1.5 running on Fedora Core 6.
Please find attached:
1 - the output of vmstat taken after the first 60k transactions were
executed
2 - the postgresql.conf file

Any help would be appreciated.

Best regards,
Vladimir
--

Vladimir Stankovic T: +44 20 7040 0273
Research Student/Research Assistant F: +44 20 7040 8585
Centre for Software Reliability E: V(dot)Stankovic(at)city(dot)ac(dot)uk
City University
Northampton Square, London EC1V 0HB

Attachment Content-Type Size
postgresql.conf text/plain 13.8 KB
vmstat_output.txt text/plain 4.8 KB

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Fuhr 2007-06-11 13:29:53 Re: pg_statistic doesnt contain details for specific table
Previous Message Dave Cramer 2007-06-11 10:55:36 Re: How much ram is too much