> I don't mind contributing the script and schema that I used, but one thing
I
> failed to mention in my first post is that the first thing the script does
> is open connections to 256 databases (all on this same machine), and the
> transactions are relatively evenly dispersed among the 256 connections.
The
> test was originally written to try out an idea to allow scalability by
> partitioning the data into seperate databases (which could eventually each
> live on its own server). If you are interested I can modify the test to
use
> only one database and rerun the same tests this weekend.
>
I modified my test script to use just one (instead of 256) databases to be
more representative of a common installation. Then I ran more tests under
both ext2 and reiserfs. The summary follows. Short answer is that the
differences are much smaller than under the first test, but ext2 is still
faster.
-- Joe
case rfs_fdatasync ext_fdatasync rfs_fdatasync
ext_fdatasync rfs_fdatasync ext_fdatasync
fstab sync,noatime sync,noatime noatime noatime
defaults defaults
starting # tup 70k 70k 70k 70k
70k 70k
total time (min) 12.10 11.77 11.83 11.43
11.88 11.42
cpu util % 90-94% 95-98% 90-95% 95-99%
90-95% 95-99%
ram - stable cpu 42M 42M 42M 42M
42M 42M
ram - final 52M 52M 52M 52M
52M 52M
avg trans/sec
10000 tup 13.77 14.16 14.08 14.58
14.03 14.60
5000 tup 13.70 14.08 13.97 14.71
13.93 14.75
1000 tup 11.36 11.63 11.63 13.33
11.63 13.51
Notes:
1. rfs_fdatasync: data and wal on rieserfs with wal_sync_method = fdatasync
2. ext_fdatasync: data and wal on ext2 with wal_sync_method = fdatasync
3. starting # tup: the database was pre-seeded with 70k tuples. I made a
tarball of the starting database and refreshed the pgsql/data filestructure
before each test to ensure a good comparison.
4. cpu utilization + ram - stable cpu + ram - final: I eyeballed top while
the test was running. In general cpu % increased steadily through the first
1500 or so transactions, along with ram usage. At the point when cpu
utilization stabilized, ram was pretty consistently at 42M. From there, cpu
util % varied in the ranges noted, while ram usage slowly increased to 52M.
It seemed pretty linear in that I could estimate the number of transactions
already processes based on ram usage.
5. avg trans/sec: These represent the total transactions/total elapsed time
at the given number of transactions (as opposed to some instantaneous value
at that point in time).
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
