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.pdf
https://github.com/oberstet/scratchbox/tree/master/cruncher/adr_stats
Cheers,
/Tobias
>
>
> Greetings,
>
> Andres Freund
>