FreeBSD 10 and PostgreSQL 9.3 scalability issues

Adrian Chadd adrian at freebsd.org
Tue Mar 18 12:16:46 UTC 2014


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 <matthew at 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
>
>


More information about the freebsd-performance mailing list