Hi, On 2021-07-24 12:12:36 -0700, Andres Freund wrote: > On Sat, Jul 24, 2021, at 12:01, Matthew Wilcox wrote: > > On Sat, Jul 24, 2021 at 11:45:26AM -0700, Andres Freund wrote: > > It's always possible I just broke something. The xfstests aren't > > exhaustive, and no regressions doesn't mean no problems. > > > > Can you guide Michael towards parameters for pgbench that might give > > an indication of performance on a more realistic workload that doesn't > > entirely fit in memory? > > Fitting in memory isn't bad - that's a large post of real workloads. It just makes it hard to believe the performance improvement, given that we expect to be bound by disk sync speed... I just tried to compare folio-14 vs its baseline, testing commit 8096acd7442e against 480552d0322d. In a VM however (but at least with its memory being backed by huge pages and storage being passed through). I got about 7% improvement with just some baseline tuning of postgres applied. I think a 1-2% of that is potentially runtime variance (I saw slightly different timings leading around checkpointing that lead to a bit "unfair" advantage to the folio run). That's a *nice* win! WRT the ~70% improvement: > Michael, where do I find more details about the codification used during the > run? After some digging I found https://github.com/phoronix-test-suite/phoronix-test-suite/blob/94562dd4a808637be526b639d220c7cd937e2aa1/ob-cache/test-profiles/pts/pgbench-1.10.1/install.sh For one the test says its done on ext4, while I used xfs. But I think the bigger thing is the following: The phoronix test uses postgres with only one relevant setting adjusted (increasing the max connection count). That will end up using a buffer pool of 128MB, no huge pages, and importantly is configured to aim for not more than 1GB for postgres' journal, which will lead to constant checkpointing. The test also only runs for 15 seconds, which likely isn't even enough to "warm up" (the creation of the data set here will take longer than the run). Given that the dataset phoronix is using is about ~16GB of data (excluding WAL), and uses 256 concurrent clients running full tilt, using that limited postgres settings doesn't end up measuring something particularly interesting in my opinion. Without changing the filesystem, using a configuration more similar to phoronix', I do get a bigger win. But the run-to-run variance is so high (largely due to the short test duration) that I don't trust those results much. It does look like there's a less slowdown due to checkpoints (i.e. fsyncing all data files postgres modified since the last checkpoints) on the folio branch, which does make some sense to me and would be a welcome improvement. Greetings, Andres Freund
