Date: Sat, 23 Mar 2013 17:08:33 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Daniel Bilik <daniel.bilik@neosystem.cz> Cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 9.1 vs CentOS 6.3 Message-ID: <CAJ-Vmon%2BYfLbqBd_qu6bQpLkndX0865gTvtoYSxH_RNpfj%2Ba%2Bw@mail.gmail.com> In-Reply-To: <20130323213406.93cc3baddf69d5d71f10365e@neosystem.cz> References: <514C1E5F.8040504@contactlab.com> <20130323213406.93cc3baddf69d5d71f10365e@neosystem.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I recall that there were significant issues with jemalloc on computational loads, primarily because of the alignment jemalloc ends up giving to various allocation sizes and the cache-busting behaviour of that. Does anyone remember the thread in which that happened? Maybe someone posted a patch that lets people quickly tweak jemalloc to try and avoid this? Adrian On 23 March 2013 13:34, Daniel Bilik <daniel.bilik@neosystem.cz> wrote: > On Fri, 22 Mar 2013 10:03:27 +0100 > Davide D'Amico <davide.damico@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon%2BYfLbqBd_qu6bQpLkndX0865gTvtoYSxH_RNpfj%2Ba%2Bw>