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: Tue, 24 Jan 2017 18:37:14 +0100
Message-ID: <f94252f1-c860-573e-332a-b367e6f64ba1@gmail.com> (raw)
In-Reply-To: <20170124171841.2n2nzqkuetbivzta@alap3.anarazel.de>
References: <b8748d39-0b19-0514-a1b9-4e5a28e6a208@gmail.com>
<20170124171841.2n2nzqkuetbivzta@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi,
>> Switching to sync engine, it drops to 9.1 mio - but the system load then is
>> also much higher!
>
> I doubt those have very much to do with postgres - I'd quite strongly
In the machine in production, we see 8kB reads in the 300k-650k/s range.
In spikes, because, yes, due to the 3TB RAM, we have high buffer hit
ratios as well.
> assume that it'd get more than swamped with doing actualy work, and with
> buffering the frequently accessed stuff in memory.
>
>
>> What I am trying to say is: the syscall overhead of doing lseek/read/write
>> instead of pread/pwrite do become visible and hurt at a certain point.
>
> Sure - but the question is whether it's measurable when you do actual
> work.
The syscall overhead is visible in production too .. I watched PG using
perf live, and lseeks regularily appear at the top of the list.
> I'm much less against this change than Tom, but doing artificial syscall
> microbenchmark seems unlikely to make a big case for using it in
This isn't a syscall benchmark, but FIO.
> postgres, where it's part of vastly more expensive operations (like
> actually reading data afterwards, exclusive locks, ...).
PG is very CPU hungry, yes. But there are quite some system related
effects too .. eg we've managed to get down the system load with huge
pages (big improvement).
>> This isn't academic, as we have experience (in prod) with a similarily
>> designed box and PostgreSQL used as a data-warehouse.
>>
>> We are using an internal tool to parallelize via sessions and this box is
>> completely CPU bound (same NVMes, 3TB RAM as the new one, but only 48 cores
>> and no HT).
>
> I'd welcome seeing profiles of that - I'm working quite heavily on
> speeding up analytics workloads for pg.
Here:
https://github.com/oberstet/scratchbox/raw/master/cruncher/adr_stats/ADR-PostgreSQL-READ-Statistics....https://github.com/oberstet/scratchbox/tree/master/cruncher/adr_stats
Cheers,
/Tobias
>
>
> Greetings,
>
> Andres Freund
>
--
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: <f94252f1-c860-573e-332a-b367e6f64ba1@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