From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | vmikheev(at)SECTORBASE(dot)COM |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.0.3(nofsync) vs 7.1 |
Date: | 2000-12-09 07:27:11 |
Message-ID: | 20001209162711N.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I've run tests (with 50 .. 250 simult users) for some PG project
> of my company. 7.1 was 3 times faster than 7.0.3 (fsync) but near
> 3 times slower than 7.0.3 (nofsync). It was not the best day in
> my life - WAL looked like big bottleneck -:(
>
> But finally I've realized that this test makes ~3 FK insertions
> ... and FK insert means SELECT FOR UPDATE ... and this could
> reduce # of commits per fsync.
>
> So, I've run simple test (below) to check this. Seems that 7.1
> is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> triggers is quite bad for performance.
>
> Please take this into account when comparing 7.1 with 7.0.3.
> Also, we should add new TODO item: implement dirty reads
> and use them in RI triggers.
>
> Vadim
I did some testings using contrib/pgbench (100k tuples, 32 concurrent
users) with 7.1 and 7.0.3. It seems 7.1 is 5 times faster than 7.0.3
with fsync, but 1.5 times slower than 7.0.3 without fsync.
So I modified access/transam/xlog.c to disable fsync() call at
all. Now I get nearly equal performance as 7.0.3 without fsync. It
seems the bottle neck is logging with fsync(). It might be interesting
moving data/pg_xlog to a separate disk drive and see how it performs
better.
BTW pgbench does PK insertions and updates, but does no FK things.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2000-12-09 07:47:21 | Re: Japan pictures |
Previous Message | Thomas Lockhart | 2000-12-09 07:13:22 | Re: European Datestyle |