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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
