Hi, On 2015-10-28 15:18:52 +0100, Jan Kara wrote: > On Wed 28-10-15 10:30:40, Andres Freund wrote: > > On 2015-10-24 21:28:17 +0200, Jan Kara wrote: > > Thanks. Would scheduling a comparative benchmark of this be helpful > > pushing htis forward ? Would probably only be early next week, I'm at > > the european postgresql conference right now. > > If you could run it, it would be nice. Thanks! Sorry that it took longer. Had some $work deadline making a surprise attack (sneaky bastard) and then difficulity getting time on a bigger box. Hence I only have numbers from a single SSD drive (840 EVO 1TB) laptop (16GB RAM, i7-4800MQ), with nothing else running. I've compared 4.3.0-andres-07965-gd1e41ff, with/without the patch applied. Best of three results: Before: transaction type: TPC-B (sort of) scaling factor: 300 query mode: prepared number of clients: 48 number of threads: 48 duration: 1000 s number of transactions actually processed: 7873859 latency average: 6.094 ms latency stddev: 35.376 ms tps = 7871.887045 (including connections establishing) tps = 7872.135871 (excluding connections establishing) After: transaction type: TPC-B (sort of) scaling factor: 300 query mode: prepared number of clients: 48 number of threads: 48 duration: 1000 s number of transactions actually processed: 9370637 latency average: 5.119 ms latency stddev: 24.423 ms tps = 9369.212486 (including connections establishing) tps = 9369.725595 (excluding connections establishing) Pretty tidy improvement I'd say. Feel free to add a Tested-By: Andres Freund <andres@xxxxxxxxxxx> There's still quite some further room of improvement. E.g. some quite massive peaks in latency, which don't coincide with background work in postgres: progress: 869.0 s, 9971.2 tps, lat 4.828 ms stddev 6.201 progress: 870.0 s, 8196.4 tps, lat 4.632 ms stddev 6.774 progress: 871.0 s, 497.0 tps, lat 89.598 ms stddev 308.398 progress: 872.0 s, 10360.6 tps, lat 5.917 ms stddev 40.041 progress: 873.0 s, 7005.5 tps, lat 6.743 ms stddev 21.985 Without controlling writeout via sync_file_range(), we frequently can see stalls in the tens of seconds on busy machines though... So this is still much better ;) Greetings, Andres Freund -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
