On 2016-03-01 16:06:47 +0100, Tomas Vondra wrote:
> 1) HP DL380 G5 (old rack server)
> - 2x Xeon E5450, 16GB RAM (8 cores)
> - 4x 10k SAS drives in RAID-10 on H400 controller (with BBWC)
> - RedHat 6
> - shared_buffers = 4GB
> - min_wal_size = 2GB
> - max_wal_size = 6GB
>
> 2) workstation with i5 CPU
> - 1x i5-2500k, 8GB RAM
> - 6x Intel S3700 100GB (in RAID0 for this benchmark)
> - Gentoo
> - shared_buffers = 2GB
> - min_wal_size = 1GB
> - max_wal_size = 8GB
Thinking about with that hardware I'm not suprised if you're only seing
small benefits. The amount of ram limits the amount of dirty data; and
you have plenty have on-storage buffering in comparison to that.
> Both machines were using the same kernel version 4.4.2 and default io
> scheduler (cfq). The
>
> The test procedure was quite simple - pgbench with three different scales,
> for each scale three runs, 1h per run (and 30 minutes of warmup before each
> run).
>
> Due to the difference in amount of RAM, each machine used different scales -
> the goal is to have small, ~50% RAM, >200% RAM sizes:
>
> 1) Xeon: 100, 400, 6000
> 2) i5: 50, 200, 3000
>
> The commits actually tested are
>
> cfafd8be (right before the first patch)
> 7975c5e0 Allow the WAL writer to flush WAL at a reduced rate.
> db76b1ef Allow SetHintBits() to succeed if the buffer's LSN ...
Huh, now I'm a bit confused. These are the commits you tested? Those
aren't the ones doing sorting and flushing?
> Also, I really wonder what will happen with non-default io schedulers. I
> believe all the testing so far was done with cfq, so what happens on
> machines that use e.g. "deadline" (as many DB machines actually do)?
deadline and noop showed slightly bigger benefits in my testing.
Greetings,
Andres Freund