Re: FreeBSD UFS & fsync

From: Luca Ferrari <fluca1978(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: FreeBSD UFS & fsync
Date: 2021-03-15 13:35:49
Message-ID: CAKoxK+712a-h3NQcQJxc4FGV4J7d6=r_MRLcE1+wR=iJjcwUpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Mar 12, 2021 at 10:34 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> It looks like your system is performing very badly for some other
> reason, so that synchronous I/O waits are only a small proportion of
> the time, and thus fsync=off doesn't speed things up very much. I'd
> look into profiling the system to try to figure out what it's doing...
> maybe it's suffering from super slow hypercalls for gettimeofday(), or
> something like that?

Let me get this straight to see if I understand it correctly:
pg_test_fsync reports 278000 tps in non sync-ed mode, and that is what
I should expect (nearly) from turning off fsyc.
However, something else is eating my resources, so I'm not getting the
correct results.
Now, what do you mean by profiling the system? Since I'm on FreeBSD I
could use dtrace to see if there's any clue where the time is spent,
even if I'm not so expert in dtrace.
Please also note that pg_test_timing seems fine to me (I've tried
several times with pretty much the same results):

% pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 37.68 ns
Histogram of timing durations:
< us % of total count
1 96.46399 76796834
2 3.52417 2805657
4 0.00400 3183
8 0.00320 2546
16 0.00235 1871
32 0.00124 988
64 0.00065 517
128 0.00024 189
256 0.00007 58
512 0.00003 26
1024 0.00002 18
2048 0.00002 19
4096 0.00001 9
8192 0.00000 1

So apparently gettimeofday should not be the problem right here.

Luca

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message S Bob 2021-03-15 16:53:06 wide table, many many partitions, poor query performance
Previous Message Pavel Stehule 2021-03-13 06:01:13 Re: proposal: schema variables