From: Tobias Oberstein <tobias.oberstein@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: lseek/read/write overhead becomes visible at scale ..
Date: Wed, 25 Jan 2017 10:16:32 +0100
Message-ID: <bc5e13d1-88e4-5394-dfb7-a23a0b8c3f2d@gmail.com> (raw)
In-Reply-To: <20170124190705.2ioaocx6wuhvvegn@alap3.anarazel.de>
References: <b8748d39-0b19-0514-a1b9-4e5a28e6a208@gmail.com>
<20170124171841.2n2nzqkuetbivzta@alap3.anarazel.de>
<f94252f1-c860-573e-332a-b367e6f64ba1@gmail.com>
<20170124174158.nk6htg7jjmqia7hr@alap3.anarazel.de>
<422b4e6c-b7f0-90e0-6f70-389b2d50a848@gmail.com>
<20170124181121.pgk7kqfkq4dd3hpo@alap3.anarazel.de>
<a55b21d1-7c99-2c66-d661-ef5288f29e30@gmail.com>
<20170124190705.2ioaocx6wuhvvegn@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi Andres,
>> 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.
I can follow that.
So real prove cannot be done with FIO, but "actual PG workload".
Synthetic PG workload or real world production workload?
Also: rgd the perf profiles from production that show lseek as #1 syscall.
You said it wouldn't be prove either, because it only shows number of
syscalls, and though it is clear that millions of syscalls/sec do come
with overhead, it is still not showing "above noise" level relevance
(because PG is such a CPU hog in itself anyways;)
So how would I do a perf profile that would be acceptable as prove?
Maybe I can expand our
https://gist.github.com/oberstet/ca03d7ab49be4c8edb70ffa1a9fe160c
profiling function.
Cheers,
/Tobias
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tobias.oberstein@gmail.com, andres@anarazel.de
Subject: Re: lseek/read/write overhead becomes visible at scale ..
In-Reply-To: <bc5e13d1-88e4-5394-dfb7-a23a0b8c3f2d@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox