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 retrieve data 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 against the 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 that disk 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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
