Re: New Linux xfs/reiser file systems

> 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).