Re: New Linux xfs/reiser file systems

From: "Joe Conway" <joe(at)conway-family(dot)com>
To: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New Linux xfs/reiser file systems
Date: 2001-05-08 06:03:35
Message-ID: 00af01c0d784$9e905d50$0205a8c0@jecw2k1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2001-05-08 07:06:42 Posted 7.1 RPMs for Mandrake 7.2
Previous Message Christopher Kings-Lynne 2001-05-08 05:23:16 RE: Duplicate constraint names in 7.0.3