FreeBSD 9.1 vs CentOS 6.3

[Adrian Chadd]

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"