From owner-freebsd-performance@FreeBSD.ORG Sat Mar 23 20:35:20 2013 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6090FAEA for ; Sat, 23 Mar 2013 20:35:20 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) by mx1.freebsd.org (Postfix) with ESMTP id 28D086A3 for ; Sat, 23 Mar 2013 20:35:19 +0000 (UTC) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 0A8F0C9F7 for ; Sat, 23 Mar 2013 21:35:11 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from neon.sn.neosystem.cz (unknown [172.19.9.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id 26DB0C9EF for ; Sat, 23 Mar 2013 21:35:02 +0100 (CET) Date: Sat, 23 Mar 2013 21:34:06 +0100 From: Daniel Bilik To: freebsd-performance@freebsd.org Subject: Re: FreeBSD 9.1 vs CentOS 6.3 Message-Id: <20130323213406.93cc3baddf69d5d71f10365e@neosystem.cz> In-Reply-To: <514C1E5F.8040504@contactlab.com> References: <514C1E5F.8040504@contactlab.com> Organization: neosystem.cz X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Mar 2013 21:28:26 +0000 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 20:35:20 -0000 On Fri, 22 Mar 2013 10:03:27 +0100 Davide D'Amico 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