Hi, the pgsql testing done has been analysed by a few developers. The TL;DR version is that there's significant lock contention in the VM / mmap path and it sticks out like a sore thumb when one does lock profiling.
-a On 18 March 2014 05:00, Matthew Seaman <matt...@freebsd.org> wrote: > On 03/18/14 03:12, Petr Janda wrote: >> ust want to share these pgbench results done by DragonFlyBSD, and would >> like some input on why these numbers look so bad and what can be done to >> improve (ie. kernel tunables etc) the performance. >> >> http://lists.dragonflybsd.org/pipermail/users/attachments/20140310/4250b961/attachment-0001.pdf > > Using ZFS as the backing for a RDBMS without: > > * Separate (fast) L2ARC devices > * Tuning the ZFS block size to match the postgres IO block size > * Setting primarycache to metadata > * Tuning the ARC max so ZFS doesn't eat all the RAM > * probably other things I can remember off-hand. > > That's what is wrong. ZFS is known to work particularly badly at the > sort of small random IOs that RDBMSes generate (mostly because of the > copy-on-write thing) without special tuning and extra hardware for > caches. ie. You can't construct a fair test of database performance > against other OSes/filesystems if you restrict yourself to using exactly > the same hardware. > > Basically, install the FreeBSD box on UFS2 and try again. > > Cheers, > > Matthew > > _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
