Subject: Re: lseek/read/write overhead becomes visible at scale ..
To: Andres Freund <andres@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>
Cc: pgsql-hackers@postgresql.org
From: Tobias Oberstein <tobias.oberstein@gmail.com>
Message-ID: <bc5e13d1-88e4-5394-dfb7-a23a0b8c3f2d@gmail.com>
Date: Wed, 25 Jan 2017 10:16:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20170124190705.2ioaocx6wuhvvegn@alap3.anarazel.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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