Re: lseek/read/write overhead becomes visible at scale ..

On 2017-01-24 19:25:52 +0100, Tobias Oberstein wrote:
> Hi,
>
> > > pid | syscall | cnt | cnt_per_sec
> > > -----+---------------------------------------+---------+-------------
> > > | syscalls:sys_enter_lseek | 4091584 | 136386
> > > | syscalls:sys_enter_newfstat | 2054988 | 68500
> > > | syscalls:sys_enter_read | 767990 | 25600
> > > | syscalls:sys_enter_close | 503803 | 16793
> > > | syscalls:sys_enter_newstat | 434080 | 14469
> > > | syscalls:sys_enter_open | 380382 | 12679
> > >
> > > Note: there isn't a lot of load currently (this is from production).
> >
> > That doesn't really mean that much - sure it shows that lseek is
> > frequent, but it doesn't tell you how much impact this has to the
>
> Above is on a mostly idle system ("idle" for our loads) .. when things get
> hot, lseek calls can reach into the millions/sec.
>
> Doing 5 million syscalls per sec comes with overhead no matter how
> lightweight the syscall is, doesn't it?

> Using pread instead of lseek+read halfes the syscalls.
>
> I really don't understand what you are fighting here ..

Sure, there's some overhead. And as I said upthread, I'm much less
against this change than Tom. What I'm saying is that your benchmarks
haven't shown a benefit in a meaningful way, so I don't think I can
agree with

> "Well, my point remains that I see little value in messing with
> long-established code if you can't demonstrate a benefit that's clearly
> above the noise level."
>
> I have done lots of benchmarking over the last days on a massive box, and I
> can provide numbers that I think show that the impact can be significant.

since you've not actually shown that the impact is above the noise level
when measured with an actual postgres workload.

Greetings,

Andres Freund