Date: Sun, 24 Mar 2013 08:43:48 -0700 (PDT) From: Paul Pathiakis <pathiaki2@yahoo.com> To: Bill Totman <bill.totman@gmail.com>, "davide.damico@contactlab.com" <davide.damico@contactlab.com> Cc: "freebsd-performance@freebsd.org" <freebsd-performance@freebsd.org> Subject: Re: FreeBSD 9.1 vs CentOS 6.3 Message-ID: <1364139828.17881.YahooMailNeo@web141405.mail.bf1.yahoo.com> In-Reply-To: <514F099D.9040005@gmail.com> References: <CAF3xD3nDDUYB94TS9AUUQ=CPztB1S8mU4fRwNB5GupmK8MgwXg@mail.gmail.com> <ebfc033f-d8db-4162-86be-db013e3d7eb2@email.android.com> <1363998883.22604.YahooMailNeo@web141401.mail.bf1.yahoo.com> <5d10e2a0b0f6477293459a26df1fc272@sys.tomatointeractive.it> <514F099D.9040005@gmail.com>
index | next in thread | previous in thread | raw e-mail
I haven't worked with CentOS since 6.0. I work on many other variants at this time. I'm more than happy to take a look after I get my company off the ground.... (A couple more months or land my next contracting gig) Anyhow, unlike with jails, it seems no matter what type of VM I use, there's always 'overhead' in using virtual machine software. Performance is 99.99% there with a 'real' installation. Whether it's VMware, VirtualBox, or Zen, there's the issues of things that have always seemed to cause a minor 'hurt'. It's also annoying when I have to dictate how much memory, how many cores, disk space and everything else with regards to each virtual machine. Running the virtual software takes resources, from the OS, and each VM under control has to be 'given' bounds as to how many resources it can use. (I'm told that an ESX server is better at this, however, that server must have a core OS that uses resources as well.) So, lately, I started working with jails.... for everything. There seems to be no measurable issues with their use. Does anyone have any comparison on jails versus various VM software? I'm not just talking the VM software running an OS in real-time and no negligible loss of performance. I'm talking about the what's being taken from the core machine running the software. That's overhead. The software consumes resources (memory, cpu cycles, etc) and creates a certain amount of overhead for each VM created. Jails seem to be highly maintainable, easy to use, the resource management of CPU, memory and other types are handled by the OS and not an additional layer of software running on the host that becomes responsible for all this juggling. So, from my perspective, it seems jails remove a layer of indirection over VM software. (Of course, arguably, jails are lightweight VMs.) I'm just starting to become knowledgeable and a 'fan' of jails. I'm also a little 'aged' and I never understood the need for VM software as UNIX has always been capable of juggling (time slicing) task courtesy of the job scheduler and the like. I can see that a mainframe, mini, and Windows OS that were not designed to be capable of time sharing would need them, but not UNIX. If I wanted a 'rough' analogy, I can equate VM software is to jails as UFS is to a ZFS pool. I think of it this way: with VM software I have to understand the resources I will need and I will create boundaries according to a 'best guess' scenario with jails I create the environment and all the jails get access to all the available resources to the machine and allow a robust UNIX-like (I really hate writing that given FBSD's roots :-) ) to handle something it's always been capable of handling from it's design. This is akin to having to setup UFS versus ZFS. UFS you have to have an idea of how big the partitions are and choose bounds (and it's "not fun" when you have to re-partition), however, with ZFS every partition grows within the bounds of the pool until it is exhausted, at that point, add storage to the pool. (With a jail, at that point, if it's anything but CPU cores, just add resources to the machine - if it is CPU, it's time for a new CPU or maybe a second machine.) I hate to say this but I'm finding jails 'highly superior' to VM software and now that I hear that we can run Linux in a jail, I'd be very curious to do that, too. <rant> One last thing, I see VMs almost as a 'development tool' that people just recklessly took to the next level. It's a lot of fun to create VMs on a desktop machine that you are doing development on to see what changes occur before putting software into production, but, like most things of the last 25 years (high capacity disk drives, plummeting memory prices, and the ongoing speed increases of CPUs), people have become lazy in doing things the right way. When things were tight, people thought at the 'assembler' level to program lean, mean and fast, C was a boon as it's kind of a level 2.5 Von Neuman language, you can access low-level but it's structured like a level 3 language. Now, people don't really think of machine resources. They just hack together things and hope the compiler catches their mistakes. *shrug* </rant> P. PS - (I'd post my credentials, but, basically, I'm a Systems Architect that has a past with employment or consulting with many major corporations. My job is creating systems of systems that are highly scalable and modular and can be nimble in moving from one tech to another. I've been exposed to almost every *NIX type of OS, Windows and other OS variants.... I'm still impressed with FBSD as I'm a CS and I have watched it always try to be cutting edge and always implement the correct technologies and refuses to compromise by releasing a<Version>.0 that 'kinda works'That's how I've lived my career. Kudos to all the people working on it!) PPS - I have to make my living using all variants of *nix including Debian, CentOS, RH, SuSe, etc. Also, Ibelieve I was the first one to create a SAN in 1993 while at EMC. I've worked with many Linux variants. However, when I look at who is really using BSD.... Cisco, Juniper, NetApp, and many major manufacturers base their *NIX products on it and kind of give away Linux for free but they are really happy to get consulting hours at $200-$400/hr to work it.... So, I'm not a 'fan boy' , I'm somebody who respects the mindset of the 'best tech to solve the problem'. ________________________________ From: Bill Totman <bill.totman@gmail.com> To: davide.damico@contactlab.com Cc: freebsd-performance@freebsd.org Sent: Sunday, March 24, 2013 10:11 AM Subject: Re: FreeBSD 9.1 vs CentOS 6.3 On 3/23/13 3:44 AM, Davide D'Amico wrote: > Il 23.03.2013 01:34 Paul Pathiakis ha scritto: >> Hi, >> >> There are several things about this that are highly suspect. >> >> First, wipe out the hardware RAID. The processor doing RAID >> computation is, probably, MUCH slower than a core on the CPU. Even if >> it's RAID-1 (Simple Mirror) this RAID card is performing tasks that is >> does not need to do including replicating writes to two targets from >> the controller or checking it's cache, battery, etc. If it's possible >> to disable the onboard cache, do it. > > Hi Paul, > thanks for your suggestions (some of them I've applied before starting any consideration, like disabling all on-disk caches or controller buffers) I'll try next monday. > > Anyway, the fact is that using the same hardware configuration (raid1+raid10) I saw that a centos 6.x outperformed freebsd 9.1. > Another test I made yesterday was: on the same hardware I installed vmware esx 5.x and created a vm with centos inside it. The result was really impressive: the centos vm outperformed the 'real' freebsd 9.1 too and checking vmware performances graphs I didn't see any huge need for a massive throughput (I saw values from KBps to 10MBps), instead I saw a big use of CPU (using OLTP tests with a concurrency of 32 threads it's performaces began to slow down). > So, what happened when you installed FreeBSD 9.1 in the VM? How did the 'fake' FreeBSD 9.1 compare 1) to the 'real', and 2) to either of the CentOS installations? -bt > I don't know is using some magic value for HZ or setting some trick with scheduler, I could gain something: I hope so, because I don't want to "pinguinate" my farm :) > > Thanks, > d. > > _______________________________________________ > 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" _______________________________________________ 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" From owner-freebsd-performance@FreeBSD.ORG Sun Mar 24 16:01:06 2013 Return-Path: <owner-freebsd-performance@FreeBSD.ORG> 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 B959263B for <freebsd-performance@freebsd.org>; Sun, 24 Mar 2013 16:01:06 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1921DF for <freebsd-performance@freebsd.org>; Sun, 24 Mar 2013 16:01:06 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hn17so3193223wib.6 for <freebsd-performance@freebsd.org>; Sun, 24 Mar 2013 09:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5nZ8bn0UzjEUPZt1R5v/7a7mnUO9IeDU7UsyRFs9Q3U=; b=sd1th+4cmbjP8mmdNOX+LHG9jmMaL0f/G1ZnZ1PmRfv0VudDsaGwDbxrZf+vw5AfZ5 kMVCaLiQ6WWOUujai0eJsW4T512gbe9VJvTZ5XzMLwAWTA/ewRDfoM4Pur7FXp/TzHR6 ggTxJL/yAwd1cPl218L3z8qxhg1AZ9Fb455ewESotRGpwCM//X1EUPxGZWGNfgGJeb6c 1ByOUxhsdki/n+xCwkp0PKtiYo7pgjzyb75UdAjOIX5uxtoDPrO9tijDkkrXKmcbm4f2 mSmf5dNuRuhMaNtGhtE94RDZeF6J72wl/6zZpeLH3/Q7S2jBb1shootzE/jsWWdFkVZy 5AKw=MIME-Version: 1.0 X-Received: by 10.180.109.82 with SMTP id hq18mr12856083wib.0.1364140865477; Sun, 24 Mar 2013 09:01:05 -0700 (PDT) Received: by 10.194.140.20 with HTTP; Sun, 24 Mar 2013 09:01:05 -0700 (PDT) In-Reply-To: <20130323213406.93cc3baddf69d5d71f10365e@neosystem.cz> References: <514C1E5F.8040504@contactlab.com> <20130323213406.93cc3baddf69d5d71f10365e@neosystem.cz> Date: Sun, 24 Mar 2013 11:01:05 -0500 Message-ID: <CA+tpaK2JK3xhEc_RrOCAdEB1vvapEHE=VqvY5=kSM-Bkhy07PA@mail.gmail.com> Subject: Re: FreeBSD 9.1 vs CentOS 6.3 From: Adam Vande More <amvandemore@gmail.com> To: Daniel Bilik <daniel.bilik@neosystem.cz> Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-performance@freebsd.org X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Performance/tuning <freebsd-performance.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-performance>, <mailto:freebsd-performance-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-performance>; List-Post: <mailto:freebsd-performance@freebsd.org> List-Help: <mailto:freebsd-performance-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-performance>, <mailto:freebsd-performance-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 24 Mar 2013 16:01:06 -0000 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 <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" > -- Adam Vande Morehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1364139828.17881.YahooMailNeo>