From owner-freebsd-performance@FreeBSD.ORG Sun Mar 24 18:46:00 2013 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51F64B8F; Sun, 24 Mar 2013 18:46:00 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id C0B73E69; Sun, 24 Mar 2013 18:45:59 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id s43so250141wey.7 for ; Sun, 24 Mar 2013 11:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sbduJW9wfmaPhLzH1BHAFJ35gW9HK85f38Pkxh/hggc=; b=IjT56W3zcaRDlNH3D0cGa6mHlS9lHwBdL3j70aGfPnEg7ol7Ql8L34yiOyPt2lLljy E7z0huS0kIYNAugKUegw/tqDiOTWX7pqSa3VlloY2UVhwBEcOAP8VSNl3UGxeQM4ckkB fOTCw/adUHOS296d6hDshzTG3111dpz3dSNN8ANv4U12gMRoK3sUHdDzDpV9ooUKwOf8 qhoDD5WQhD5cTFbxTqBWUUnRBVXVVIqbHk3P0rvsjcxg4M/eZLL67JO+tzSZg8p65QI6 bI0BLvAU7fwVU9OlPJ66SO+5oZqiqgqXymcP96jCnb+0dOAbbemmdaCrzGtZx112w8gE FcHQ== MIME-Version: 1.0 X-Received: by 10.180.109.82 with SMTP id hq18mr13361314wib.0.1364150758963; Sun, 24 Mar 2013 11:45:58 -0700 (PDT) Received: by 10.194.140.20 with HTTP; Sun, 24 Mar 2013 11:45:58 -0700 (PDT) In-Reply-To: References: <514C1E5F.8040504@contactlab.com> <20130323213406.93cc3baddf69d5d71f10365e@neosystem.cz> Date: Sun, 24 Mar 2013 13:45:58 -0500 Message-ID: Subject: Re: FreeBSD 9.1 vs CentOS 6.3 From: Adam Vande More To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Daniel Bilik , freebsd-performance@freebsd.org 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: Sun, 24 Mar 2013 18:46:00 -0000 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 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 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 >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@neosystem.cz>wrote: > >> > >>> 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 > >>> _______________________________________________ > >>> 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" > >>> > >> > >> > >> > >> -- > >> Adam Vande More > > > > > > > > > > -- > > Adam Vande More > > _______________________________________________ > > 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" > -- Adam Vande More