We have a PostgreSQL 8.2.7 database (~230 GB) running on a machine with 8 Intel Xeon Cores and 32 GB RAM (64-bit Linux
2.6.18).Data is stored on an EMC² CLARiiON on RAID 1/0 (8 x 146 GB 15k rpm).
When we do random I/O with a small test tool (reading random 8k blocks from big files in 200 threads) on the disk we
retrievedata with about 25 MB/s.
For testing purpose a test set of about 700.000 queries (those were logged during a problem situation) are executed
againstthe database in 180 concurrent threads.
Some of the queries are very small and fast - other ones read more than 50000 blocks. All queries are selects (using
cursors)- there is only read activity on the database.
By setting tuple_fraction for cursors to 0.0 instead of 0.1
(http://archives.postgresql.org/pgsql-performance/2008-04/msg00018.php)we reduced reads during the test
(pg_statio_all_tables):
- 8.2.7
reads from disk: 4.395.276, reads from cache: 471.575.925
- 8.2.7 cursor_tuple_fraction=0.0
Reads from disk: 3.406.164, reads from cache: 37.924.625
But the duration of the test was only reduced by 18 % (from 110 minutes to 90 minutes).
When running the test with tuple_fraction=0.0 we observe the following on the server:
- avg read from disk is at 7 MB/s
- when we start the random I/O tool during the test we again read data with about 25 MB/s from disk (for me it seems
thatdisk isn't the bottleneck)
- cpu time is divided between idle and iowait - user and system cpu are practically zero
- there are from 5000 to 10000 context switches per second
I can't see a bottleneck here. Does anyone has an explanation for that behavior?
Regards,
Robert
