FreeBSD 9.1 vs CentOS 6.3

[Adam Vande More]

jemalloc also has concurrency issues when threads > areas:

http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf

On Sun, Mar 24, 2013 at 12:51 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> The contention is due to memory allocations being page aligned and
> those pools all hitting the same cache line mappings.
>
>
>
>
> Adrian
>
> On 24 March 2013 09:09, Adam Vande More <amvandemore at gmail.com> wrote:
> > I think increasing the number of arenas may help the contention, eg "ln
> -s
> > 3N /etc/malloc.conf"
> >
> > On Sun, Mar 24, 2013 at 11:01 AM, Adam Vande More <amvandemore at gmail.com
> >wrote:
> >
> >> These are interesting results.  Did you try tuning any of the jemalloc
> >> options in /etc/malloc.conf?
> >>
> >>
> >> On Sat, Mar 23, 2013 at 3:34 PM, Daniel Bilik <
> daniel.bilik at neosystem.cz>wrote:
> >>
> >>> On Fri, 22 Mar 2013 10:03:27 +0100
> >>> Davide D'Amico <davide.damico at contactlab.com> wrote:
> >>>
> >>> > Hi, I'm doing performance tests on a DELL R720, follows dmesg:
> >>> > ...
> >>> > I will use this server as a mysql-5.6 dbserver so I have a root
> >>> > partition using a hw raid1 and a /DATAZFS partition, follows
> >>> > configuration:
> >>> > ...
> >>>
> >>> Well, it seems to be interesting coincidence... We've just finished
> >>> benchmarking MySQL with various (m)allocators. The goal was to test
> >>> tcmalloc, but when the system was up and running, we've taken the
> >>> opportunity to benchmark also other alternatives... including jemalloc.
> >>> All tests were performed on default MySQL 5.5.28 running on Debian
> Wheezy.
> >>> Between the tests nothing was touched on the machine or the system,
> just
> >>> allocators were changed (ie. mysqld restarted).
> >>>
> >>> Results for different test modes are available here...
> >>>
> >>> http://neosystem.cz/benchmark/mysql/
> >>>
> >>> It seems there is notable performance penalty for read-only
> transactions
> >>> when MySQL is using jemalloc. The more concurrent threads are running,
> the
> >>> more is jemalloc losing to other allocators. The penalty is also there
> for
> >>> read-write transactions, but not that significant (error bars in the
> >>> histograms also show that results for read-write tests tend to be very
> >>> unstable). OTOH in non-transactional tests, jemalloc seems to be in par
> >>> with others, and under specific load can even outperform some of them.
> >>>
> >>> In your original post, there is not mentioned in what mode you've
> >>> performed
> >>> OLTP test, but according to numbers I suspect it was "complex", ie.
> >>> transactional. Can you repeat tests (both on CentOS and FreeBSD) with
> >>> --oltp-test-mode=nontrx and/or simple?
> >>>
> >>> --
> >>>                                                 Daniel Bilik
> >>>                                                 neosystem.cz
> >>> _______________________________________________
> >>> freebsd-performance at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> >>> To unsubscribe, send any mail to "
> >>> freebsd-performance-unsubscribe at freebsd.org"
> >>>
> >>
> >>
> >>
> >> --
> >> Adam Vande More
> >
> >
> >
> >
> > --
> > Adam Vande More
> > _______________________________________________
> > freebsd-performance at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> > To unsubscribe, send any mail to "
> freebsd-performance-unsubscribe at freebsd.org"
>



-- 
Adam Vande More