Skip site navigation (1) Skip section navigation (2)

8.3 write performance

From: Enrico Sirola <enrico(dot)sirola(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: 8.3 write performance
Date: 2008-03-12 15:25:29
Message-ID: 2226A814-87D8-4531-AC26-D1E7B44227C0@gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Hello,

(you could receive this message twice - I have some email issues sorry)

I'm setting up a new DB with Centos 5 (amd64) + postgresql 8.3
installed from the pgsql yum repository. This is a host dedicated to
postgresql. From the benchmarks I found here and there on the web, and
having digged a bit on the ML, it seems that I could expect something
similar to 4000 tps with pgbench.
The host is a HP DL580 G5, 8GB of RAM with 8x146G 10k SAS disks and
2x2.4GHz quad-code intel xeons, with a battery-backed P400/512MB
controller.

I tried two disk layout configurations:

- raid 1 system
- raid 1 for WAL
- raid 10 (4 disks) for data

and

- raid 1 system
- raid 10 (6 disks) WAL+data

the FS is ext3 (without lvm) for all the db-related partitions,
created with the following options

-b 4096 -E stride=32 -j -m 10 -T largefile

(the array stripe size is 128k) and mounted with
noatime,data=writeback

pgbench reports circa 2000 tps with a number of clients ranging from 2
to 12 and starts decreasing afterwards with the number of clients, for
example I get 1200 tps with 50 clients.

The relevant configuration items of the DB is like in the following
(default values are not shown)

------------------------------------
max_connections = 100
shared_buffers = 2GB
temp_buffers = 128MB
work_mem = 8MB
maintenance_work_mem = 128MB
max_fsm_pages = 1000000
bgwriter_delay = 200ms
fsync = on
synchronous_commit = on
wal_sync_method = fdatasync
wal_buffers = 1024kB
commit_delay = 100
checkpoint_segments = 128
effective_cache_size = 5GB
constraint_exclusion = on
--------------------------------------

I'm a bit worried about this 2k tps limit I hit regardless of the disk
layout, and also by the fact that it seems someone else reported to
have much better figures (4ktps) with similar hardware. Does anyone
have hints/suggestions/advices about what could be further optimized?
Thanks a lot for your help,
Enrico



Responses

pgsql-performance by date

Next:From: Pavan DeolaseeDate: 2008-03-12 15:47:20
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Previous:From: Vivek KheraDate: 2008-03-12 14:46:25
Subject: Re: migration of 7.4 to 8.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group