From owner-freebsd-performance@FreeBSD.ORG Sun Jan 30 12:04:39 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBDDB16A4CE for ; Sun, 30 Jan 2005 12:04:39 +0000 (GMT) Received: from web26810.mail.ukl.yahoo.com (web26810.mail.ukl.yahoo.com [217.146.176.86]) by mx1.FreeBSD.org (Postfix) with SMTP id C240843D4C for ; Sun, 30 Jan 2005 12:04:38 +0000 (GMT) (envelope-from cguttesen@yahoo.dk) Received: (qmail 93216 invoked by uid 60001); 30 Jan 2005 12:04:37 -0000 Message-ID: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> Received: from [217.149.113.94] by web26810.mail.ukl.yahoo.com via HTTP; Sun, 30 Jan 2005 13:04:37 CET Date: Sun, 30 Jan 2005 13:04:37 +0100 (CET) From: Claus Guttesen To: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 12:04:39 -0000 Hi. I'm about to replace our internal nfs- and samba-server with a newer Dell 2850 dual nocona @ 3.2 GHz and 4 GB RAM and 5 SCSI-disks in RAID 5. Inspirred by the recent performance-discussions I'd like to do my own testing regarding nfs and samba, and would like to add some tests like bonnie to aid the dissussion on this list and to have some valid points in a why-FreeBSD-and-not-Linux discussion at work (which is healthy from time to time). I haven't installed linux for some years now, and do not have a good feeling how the 2.6 kernel does regarding smp, disk-io, network etc. compared to FreeBSD. I want to know, how FreeBSD stacks up regarding performance, ease of installation/updating /upgrading compared to primarily Linux and to some degree NetBSD. My plan is to start with FreeBSD 4.11, reinstall 5.3 (release), upgrade to 5.3 stable, then move to 6.0 current, install a linux-distro, and possibly install NetBSD 2.0. I will apply the following optimizations in /etc/make.conf (when applicable): march=nocona CFLAGS= -O2 -pipe -funroll-loops COPTFLAGS= -O2 -pipe -funroll-loops HTT will be disabled in BIOS. 4.11 will be the i386-port (choosing is not difficult here ;-) and UFS1, 5.3 and 6.0 will be the amd64-port and UFS2. The amd64-port will also apply to Linux/NetBSD. I want to limit my testing to nfs- and samba-networking, some web-benchmarking, disk-io and network-io. I haven't spent much time on the last two items so any small howto, what ports to install, pre-written scripts etc. would be appreciated. What Linux-distro is most BSD-like? Fumbled with Gentoo where portage seems to be a pretty strong tool. I'm planning to use ReiserFS. regards Claus From owner-freebsd-performance@FreeBSD.ORG Sun Jan 30 23:05:30 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABD5616A4CE for ; Sun, 30 Jan 2005 23:05:30 +0000 (GMT) Received: from flake.decibel.org (flake.decibel.org [66.143.173.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C8B43D31 for ; Sun, 30 Jan 2005 23:05:28 +0000 (GMT) (envelope-from decibel@decibel.org) Received: by flake.decibel.org (Postfix, from userid 1001) id B40BE1C910; Sun, 30 Jan 2005 17:05:27 -0600 (CST) Date: Sun, 30 Jan 2005 17:05:27 -0600 From: "Jim C. Nasby" To: freebsd-performance@freebsd.org Message-ID: <20050130230527.GR64304@decibel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 4.10-RELEASE-p3 i386 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Mon, 31 Jan 2005 02:11:12 +0000 Subject: Automated performance testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2005 23:05:30 -0000 With all the discussion of performance testing between 4.11, 5.3, and Linux, would it be useful to make performance testing part of the automated testing that already occurs (via tinderbox, iirc). Doing so might make it easier to detect performance impacting changes, as well as making performance testing easier in general. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" From owner-freebsd-performance@FreeBSD.ORG Mon Jan 31 15:25:19 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B96C316A4CE for ; Mon, 31 Jan 2005 15:25:19 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 673DD43D31 for ; Mon, 31 Jan 2005 15:25:19 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id B72A746B0D; Mon, 31 Jan 2005 10:25:18 -0500 (EST) Date: Mon, 31 Jan 2005 15:24:39 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Jim C. Nasby" In-Reply-To: <20050130230527.GR64304@decibel.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-performance@freebsd.org Subject: Re: Automated performance testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 15:25:19 -0000 On Sun, 30 Jan 2005, Jim C. Nasby wrote: > With all the discussion of performance testing between 4.11, 5.3, and > Linux, would it be useful to make performance testing part of the > automated testing that already occurs (via tinderbox, iirc). Doing so > might make it easier to detect performance impacting changes, as well as > making performance testing easier in general. Yes, it would be quite valuable. I've been hoping to set up something like this for a while, but have never found the opportunity. I have been tracking the long term behavior of MySQL performance as part of the netperf work, but because testing is fairly hardware and time consuming, the polling intervals are uneven, and not quite close enough to nail down culprits. I'd really like to see a small and fairly well-defined set of tests run every couple of days so we can show long term graphs, and catch regressions quickly. Unfortunately, this is a bit harder than tinder-boxing, because it involves swapping out whole system configurations, recovering from the inevitable failure modes, etc, which proves to be the usual sticking point in implementing this. However, I'd love to see someone work on it :-). Robert N M Watson From owner-freebsd-performance@FreeBSD.ORG Mon Jan 31 15:45:39 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE7B116A4CF; Mon, 31 Jan 2005 15:45:39 +0000 (GMT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D650743D31; Mon, 31 Jan 2005 15:45:38 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id j0VFjaOJ016927; Mon, 31 Jan 2005 09:45:36 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <41FE529E.7080601@centtech.com> Date: Mon, 31 Jan 2005 09:45:34 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-performance@freebsd.org cc: "Jim C. Nasby" Subject: Re: Automated performance testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 15:45:40 -0000 Robert Watson wrote: > On Sun, 30 Jan 2005, Jim C. Nasby wrote: > > >>With all the discussion of performance testing between 4.11, 5.3, and >>Linux, would it be useful to make performance testing part of the >>automated testing that already occurs (via tinderbox, iirc). Doing so >>might make it easier to detect performance impacting changes, as well as >>making performance testing easier in general. > > > Yes, it would be quite valuable. I've been hoping to set up something > like this for a while, but have never found the opportunity. I have been > tracking the long term behavior of MySQL performance as part of the > netperf work, but because testing is fairly hardware and time consuming, > the polling intervals are uneven, and not quite close enough to nail down > culprits. I'd really like to see a small and fairly well-defined set of > tests run every couple of days so we can show long term graphs, and catch > regressions quickly. Unfortunately, this is a bit harder than > tinder-boxing, because it involves swapping out whole system > configurations, recovering from the inevitable failure modes, etc, which > proves to be the usual sticking point in implementing this. However, I'd > love to see someone work on it :-). Maybe it would help to come up with a list of tests, or even just things to be tested initially. Then one could get a sense of what tests need to be run, and how to do it.. I wonder if it's worth building a little app that runs a suite of other included apps (found in the ports collection), grabs system hardware and configuration information, runs the tests, and sends them to a central location. Then we can have OS, hardware, software config, etc information, and compare system vs system, OS ver, etc, and people just build the fbsdperftest port (which installs a slew of other ports, like iozone, bonnie, apache (HTTP testing), mysql (DB testing?), etc), then they run the program, it gathers the data, asks a couple of questions, and sends the data off to a central spot for analyzing later. Then, one could set up a machine that just does the cvsup, buildworld, ..., fbsdperftest, repeat.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-performance@FreeBSD.ORG Mon Jan 31 15:54:05 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F194016A4CE for ; Mon, 31 Jan 2005 15:54:04 +0000 (GMT) Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 8400243D5C for ; Mon, 31 Jan 2005 15:54:04 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 51809 invoked by uid 60001); 31 Jan 2005 15:54:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=G++HD2OCkVyie/fSdiLlkhFjYsAxFzQaaVCaowatGwtMWOJhYSWmhWX/5an65ATaypLxJEuil09cMqicsvCrw9NNWm9QgS3HyRpRF5vlRfVzsdiAos3aALj2urJM86uzLFz/ZBsH08JkFVJowmslgm3tR5dbMWuRyuxP4Q/EVF0= ; Message-ID: <20050131155404.51807.qmail@web41207.mail.yahoo.com> Received: from [83.129.209.68] by web41207.mail.yahoo.com via HTTP; Mon, 31 Jan 2005 07:54:04 PST Date: Mon, 31 Jan 2005 07:54:04 -0800 (PST) From: Arne "Wörner" To: Robert Watson , "Jim C. Nasby" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-performance@freebsd.org Subject: Re: Automated performance testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 15:54:05 -0000 --- Robert Watson wrote: > On Sun, 30 Jan 2005, Jim C. Nasby wrote: > > With all the discussion of performance testing between 4.11, > > 5.3, and Linux, would it be useful to make performance > > testing part of the automated testing that already occurs > > (via tinderbox, iirc). Doing so might make it easier to > > detect performance impacting changes, as well as > > making performance testing easier in general. > > Yes, it would be quite valuable. > [...] > I'd really like to see a small and fairly well-defined set of > tests run every couple of days so we can show long term graphs, > and catch regressions quickly. > Me, too. > Unfortunately, this is a bit harder than tinder-boxing, > because it involves swapping out whole system > configurations, recovering from the inevitable failure modes, > etc, which proves to be the usual sticking point in > implementing this. > Hmm... I believe, that a "dd bs=128k count=1000 of=/dev/null" (maybe with several iseek values) would be sufficient to detect the worst disadvantages. That test should be done on at least one box (always the same if possible), whenever a hard disc is changed (then the box has changed a little bit), and whenever there is a new release or some development progress. > However, I'd love to see someone work on it :-). > Me, too. May I try, please? Maybe I should admit, that I damaged my slices and partitions some days ago, but now everything works fine again... :-)) -Arne __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From owner-freebsd-performance@FreeBSD.ORG Mon Jan 31 16:42:32 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2F8D16A4CE; Mon, 31 Jan 2005 16:42:32 +0000 (GMT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C2143D5D; Mon, 31 Jan 2005 16:42:31 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd11.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1CvedB-0007NX-02; Mon, 31 Jan 2005 17:42:29 +0100 Received: from Andro-Beta.Leidinger.net (rxUMYvZBreOCwgv1zlUUskoMBy7Q6QZ-9PRRzPb+-3SOJHT+wGuuZe@[217.83.22.143]) by fmrl11.sul.t-online.com with esmtp id 1CvecX-0LiaUy0; Mon, 31 Jan 2005 17:41:49 +0100 Received: from Andro-Beta.Leidinger.net (localhost [127.0.0.1]) j0VGfX2Q084389; Mon, 31 Jan 2005 17:41:33 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: (from www@localhost) by Andro-Beta.Leidinger.net (8.13.1/8.13.1/Submit) id j0VGfWN3084388; Mon, 31 Jan 2005 17:41:32 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: Andro-Beta.Leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde) with HTTP for ; Mon, 31 Jan 2005 17:41:31 +0100 Message-ID: <20050131174131.9strohzlcsk40404@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 31 Jan 2005 17:41:31 +0100 From: Alexander Leidinger To: Robert Watson References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) / FreeBSD-4.11 X-ID: rxUMYvZBreOCwgv1zlUUskoMBy7Q6QZ-9PRRzPb+-3SOJHT+wGuuZe@t-dialin.net X-TOI-MSGID: baef2871-317f-4348-91b4-90735d79fe56 cc: freebsd-performance@freebsd.org cc: "Jim C. Nasby" Subject: Re: Automated performance testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 16:42:33 -0000 Robert Watson wrote: > culprits. I'd really like to see a small and fairly well-defined set of > tests run every couple of days so we can show long term graphs, and catch > regressions quickly. In the old wiki I had some automated performance testing thoughts on the QA page (mainly about what kind of tests we could automate). Unfortunately the content didn't made it to the new one and I can't find the old one... Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Many pages make a thick book. From owner-freebsd-performance@FreeBSD.ORG Mon Jan 31 16:59:16 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA6ED16A4CE; Mon, 31 Jan 2005 16:59:16 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1426643D39; Mon, 31 Jan 2005 16:59:16 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j0VGxFb9042942; Mon, 31 Jan 2005 11:59:15 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42340-08; Mon, 31 Jan 2005 11:59:15 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id j0VGxFDZ042928; Mon, 31 Jan 2005 11:59:15 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id j0VGx8iW086983; Mon, 31 Jan 2005 11:59:08 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050131101913.045736f8@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 31 Jan 2005 12:00:39 -0500 To: Robert Watson , jeff@freebsd.org From: Mike Tancsa In-Reply-To: <6.2.0.14.0.20050128145435.098e3d48@64.7.153.2> References: <6.2.0.14.0.20050127213817.02f19220@64.7.153.2> <6.2.0.14.0.20050128145435.098e3d48@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 16:59:17 -0000 OK, I re-ran the tests on the same box using CURRENT as of this morning. There does not seem to be any large difference speed wise between RELENG_5 and HEAD, at least as it relates to the 3ware driver. Both RELENG_5 and HEAD are behind RELENG_4 and Linux 2.6.10 which are pretty equal in the tests that I did. I could not run the full NFS tests, and async nfs mounts are broken in RELENG_5 and HEAD. F=RELENG_5 L=Linux 2.6.10 H=FreeBSD Current Jan 31/2005 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU F 2000 33789 25.8 34065 8.3 14038 3.8 47484 44.6 67316 9.5 2873.7 5.7 L 2000 28073 62.0 22391 4.3 12189 2.0 17577 35.5 102132 5.5 1853.7 2.5 H 2000 33301 27.9 34832 8.3 12872 3.4 49762 46.8 67274 9.2 8078.1 15.1 HEAD PostMark v1.5 : 3/27/01 pm>set location /mnt pm>set size 300 100000 pm>set transactions 400000 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 2435 seconds total 2432 seconds of transactions (164 per second) Files: 200107 created (82 per second) Creation alone: 500 files (250 per second) Mixed with transactions: 199607 files (82 per second) 199905 read (82 per second) 199384 appended (81 per second) 200107 deleted (82 per second) Deletion alone: 889 files (889 per second) Mixed with transactions: 199218 files (81 per second) Data: 12715.55 megabytes read (5.22 megabytes per second) 12728.92 megabytes written (5.23 megabytes per second) pm> LINUX 2.6.10 (EXT3 filesystem) pm>set size 300 100000 pm>set location /mnt pm>set transactions 400000 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 1504 seconds total 1503 seconds of transactions (266 per second) Files: 200107 created (133 per second) Creation alone: 500 files (500 per second) Mixed with transactions: 199607 files (132 per second) 199905 read (133 per second) 199384 appended (132 per second) 200107 deleted (133 per second) Deletion alone: 889 files (889 per second) Mixed with transactions: 199218 files (132 per second) Data: 12715.55 megabytes read (8.45 megabytes per second) 12728.92 megabytes written (8.46 megabytes per second) pm> RELENG_5. PostMark v1.5 : 3/27/01 pm>set location /mnt pm>size 300 100000 Eh? pm>set size 300 100000 pm>set location /mnt pm>set transactions 400000 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 2490 seconds total 2487 seconds of transactions (160 per second) Files: 200107 created (80 per second) Creation alone: 500 files (500 per second) Mixed with transactions: 199607 files (80 per second) 199905 read (80 per second) 199384 appended (80 per second) 200107 deleted (80 per second) Deletion alone: 889 files (444 per second) Mixed with transactions: 199218 files (80 per second) Data: 12715.55 megabytes read (5.11 megabytes per second) 12728.92 megabytes written (5.11 megabytes per second) pm> HEAD [nfs]# time dd if=/dev/zero of=/mnt/test bs=16k count=2000 2000+0 records in 2000+0 records out 32768000 bytes transferred in 0.761311 secs (43041540 bytes/sec) 0.008u 0.048s 0:00.84 4.7% 35+291k 0+258io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=32k count=2000 2000+0 records in 2000+0 records out 65536000 bytes transferred in 2.080178 secs (31504996 bytes/sec) 0.000u 0.116s 0:02.08 5.2% 29+285k 1+500io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=64k count=2000 2000+0 records in 2000+0 records out 131072000 bytes transferred in 3.381287 secs (38763940 bytes/sec) 0.000u 0.232s 0:03.39 6.7% 20+262k 2+1000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=128k count=2000 time dd if=/dev/zero of=/mnt/test bs=256k count=2000 2000+0 records in 2000+0 records out 262144000 bytes transferred in 6.768166 secs (38731910 bytes/sec) 0.007u 0.477s 0:06.80 6.9% 26+495k 7+2000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=256k count=2000 time dd if=/dev/zero of=/mnt/test bs=512k count=2000 2000+0 records in 2000+0 records out 524288000 bytes transferred in 14.230285 secs (36843113 bytes/sec) 0.000u 0.988s 0:14.29 6.8% 26+833k 6+4000io 0pf+0w [nfs]# [nfs]# time dd if=/dev/zero of=/mnt/test bs=512k count=2000 2000+0 records in 2000+0 records out 1048576000 bytes transferred in 28.617657 secs (36640875 bytes/sec) 0.000u 2.113s 0:28.72 7.3% 25+1430k 29+8000io 0pf+0w [nfs]# RELENG_5 [nfs]# time dd if=/dev/zero of=/mnt/test bs=16k count=2000 32768000 bytes transferred in 0.724865 secs (45205661 bytes/sec) 0.000u 0.066s 0:00.73 8.2% 33+281k 0+250io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=32k count=2000 65536000 bytes transferred in 1.731888 secs (37840788 bytes/sec) 0.000u 0.122s 0:01.74 6.8% 28+283k 0+500io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=64k count=2000 131072000 bytes transferred in 3.131403 secs (41857273 bytes/sec) 0.000u 0.245s 0:03.14 7.6% 25+335k 0+1000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=128k count=2000 262144000 bytes transferred in 6.973014 secs (37594073 bytes/sec) 0.000u 0.509s 0:07.00 7.1% 26+510k 0+2000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=256k count=2000 524288000 bytes transferred in 14.253915 secs (36782035 bytes/sec) 0.000u 1.003s 0:14.30 6.9% 25+784k 0+4000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=512k count=2000 1048576000 bytes transferred in 28.135716 secs (37268502 bytes/sec) 0.008u 2.165s 0:28.21 7.6% 24+1386k 0+8000io 0pf+0w [nfs]# NFS tests done from a RELENG_5 client with testfile.new in the servers cache [ns4-new]# time dd if=/dev/zero of=/mnt/testfile bs=16k count=16384 16384+0 records in 16384+0 records out 268435456 bytes transferred in 80.830089 secs (3320984 bytes/sec) 0.020u 0.442s 1:20.90 0.5% 29+254k 0+32768io 0pf+0w [ns4-new]# time dd if=/mnt/testfile.new of=/dev/null bs=16k 16384+0 records in 16384+0 records out 268435456 bytes transferred in 0.290720 secs (923347100 bytes/sec) 0.007u 0.283s 0:00.29 96.5% 26+227k 0+0io 0pf+0w postmark on nfs PostMark v1.5 : 3/27/01 pm>set size 300 100000 pm>set location /mnt pm>set transactions 400 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 68 seconds total 64 seconds of transactions (6 per second) Files: 697 created (10 per second) Creation alone: 500 files (125 per second) Mixed with transactions: 197 files (3 per second) 194 read (3 per second) 206 appended (3 per second) 697 deleted (10 per second) Deletion alone: 494 files (494 per second) Mixed with transactions: 203 files (3 per second) Data: 10.26 megabytes read (154.52 kilobytes per second) 36.87 megabytes written (555.26 kilobytes per second) NFS on HEAD [ns4-new]# time dd if=/dev/zero of=/mnt/testfile bs=16k count=16384 16384+0 records in 16384+0 records out 268435456 bytes transferred in 52.172368 secs (5145165 bytes/sec) 0.016u 0.465s 0:52.23 0.8% 24+208k 0+32768io 0pf+0w [ns4-new]# time dd if=/mnt/testfile.new of=/dev/null bs=16k 16384+1 records in 16384+1 records out 268435774 bytes transferred in 6.328295 secs (42418341 bytes/sec) 0.023u 0.363s 0:06.36 5.9% 35+298k 0+0io 0pf+0w [ns4-new]# PostMark v1.5 : 3/27/01 pm>set location /mnt pm>set size 300 100000 pm>set transactions 400 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 68 seconds total 63 seconds of transactions (6 per second) Files: 697 created (10 per second) Creation alone: 500 files (125 per second) Mixed with transactions: 197 files (3 per second) 194 read (3 per second) 206 appended (3 per second) 697 deleted (10 per second) Deletion alone: 494 files (494 per second) Mixed with transactions: 203 files (3 per second) Data: 10.26 megabytes read (154.52 kilobytes per second) 36.87 megabytes written (555.26 kilobytes per second) pm> NFS on head with vfs.nfsrv.async=1 [ns4-new]# time dd if=/dev/zero of=/mnt/testfile.async bs=16k count=16384 16384+0 records in 16384+0 records out 268435456 bytes transferred in 500.301252 secs (536548 bytes/sec) 0.018u 0.453s 8:20.53 0.0% 22+194k 0+32768io 0pf+0w [ns4-new]# From owner-freebsd-performance@FreeBSD.ORG Mon Jan 31 18:06:10 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B9FB16A4CE for ; Mon, 31 Jan 2005 18:06:10 +0000 (GMT) Received: from smtp817.mail.sc5.yahoo.com (smtp817.mail.sc5.yahoo.com [66.163.170.3]) by mx1.FreeBSD.org (Postfix) with SMTP id D303543D39 for ; Mon, 31 Jan 2005 18:06:08 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.249.100 with login) by smtp817.mail.sc5.yahoo.com with SMTP; 31 Jan 2005 18:06:00 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id A5D73619D; Mon, 31 Jan 2005 12:05:56 -0600 (CST) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 54149-09-2; Mon, 31 Jan 2005 12:05:53 -0600 (CST) Received: from www.noacks.org (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 7AC716160; Mon, 31 Jan 2005 12:05:53 -0600 (CST) Received: from 69.53.57.66 (SquirrelMail authenticated user noackjr); by www.noacks.org with HTTP; Mon, 31 Jan 2005 12:05:53 -0600 (CST) Message-ID: <57938.69.53.57.66.1107194753.squirrel@69.53.57.66> In-Reply-To: <6.2.1.2.0.20050131101913.045736f8@64.7.153.2> References: <6.2.0.14.0.20050127213817.02f19220@64.7.153.2> <6.2.0.14.0.20050128145435.098e3d48@64.7.153.2> <6.2.1.2.0.20050131101913.045736f8@64.7.153.2> Date: Mon, 31 Jan 2005 12:05:53 -0600 (CST) From: "Jon Noack" To: "Mike Tancsa" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at noacks.org cc: jeff@freebsd.org cc: Robert Watson cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 18:06:10 -0000 Mike Tancsa wrote: > > OK, I re-ran the tests on the same box using CURRENT as of this > morning. There does not seem to be any large difference speed wise > between > RELENG_5 and HEAD, at least as it relates to the 3ware driver. Both > RELENG_5 and HEAD are behind RELENG_4 and Linux 2.6.10 which are pretty > equal in the tests that I did. Did you enable mpsafevfs on HEAD (as rwatson@ mentioned earlier in this thread)? If not, I would be very curious to see how it impacts performance. To enable it, set debug.mpsafevfs="1" in /boot/loader.conf and reboot (mpsafevm is required, but it is enabled by default). Jon > I could not run the full NFS tests, and async nfs mounts are broken in > RELENG_5 and HEAD. > > F=RELENG_5 > L=Linux 2.6.10 > H=FreeBSD Current Jan 31/2005 > > -------Sequential Output-------- ---Sequential > Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- > --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec > %CPU > F 2000 33789 25.8 34065 8.3 14038 3.8 47484 > 44.6 67316 9.5 2873.7 5.7 > L 2000 28073 62.0 22391 4.3 12189 2.0 17577 35.5 > 102132 5.5 1853.7 2.5 > H 2000 33301 27.9 34832 8.3 12872 3.4 49762 > 46.8 67274 9.2 8078.1 15.1 > > > HEAD > > PostMark v1.5 : 3/27/01 > pm>set location /mnt > pm>set size 300 100000 > pm>set transactions 400000 > pm>run > Creating files...Done > Performing transactions..........Done > Deleting files...Done > Time: > 2435 seconds total > 2432 seconds of transactions (164 per second) > > Files: > 200107 created (82 per second) > Creation alone: 500 files (250 per second) > Mixed with transactions: 199607 files (82 per second) > 199905 read (82 per second) > 199384 appended (81 per second) > 200107 deleted (82 per second) > Deletion alone: 889 files (889 per second) > Mixed with transactions: 199218 files (81 per second) > > Data: > 12715.55 megabytes read (5.22 megabytes per second) > 12728.92 megabytes written (5.23 megabytes per second) > pm> > > > LINUX 2.6.10 (EXT3 filesystem) > > pm>set size 300 100000 > pm>set location /mnt > pm>set transactions 400000 > pm>run > Creating files...Done > Performing transactions..........Done > Deleting files...Done > Time: > 1504 seconds total > 1503 seconds of transactions (266 per second) > > Files: > 200107 created (133 per second) > Creation alone: 500 files (500 per second) > Mixed with transactions: 199607 files (132 per second) > 199905 read (133 per second) > 199384 appended (132 per second) > 200107 deleted (133 per second) > Deletion alone: 889 files (889 per second) > Mixed with transactions: 199218 files (132 per second) > > Data: > 12715.55 megabytes read (8.45 megabytes per second) > 12728.92 megabytes written (8.46 megabytes per second) > pm> > > > RELENG_5. > PostMark v1.5 : 3/27/01 > pm>set location /mnt > pm>size 300 100000 > Eh? > pm>set size 300 100000 > pm>set location /mnt > pm>set transactions 400000 > pm>run > Creating files...Done > Performing transactions..........Done > Deleting files...Done > Time: > 2490 seconds total > 2487 seconds of transactions (160 per second) > > Files: > 200107 created (80 per second) > Creation alone: 500 files (500 per second) > Mixed with transactions: 199607 files (80 per second) > 199905 read (80 per second) > 199384 appended (80 per second) > 200107 deleted (80 per second) > Deletion alone: 889 files (444 per second) > Mixed with transactions: 199218 files (80 per second) > > Data: > 12715.55 megabytes read (5.11 megabytes per second) > 12728.92 megabytes written (5.11 megabytes per second) > pm> > > > HEAD > > [nfs]# time dd if=/dev/zero of=/mnt/test bs=16k count=2000 > 2000+0 records in > 2000+0 records out > 32768000 bytes transferred in 0.761311 secs (43041540 bytes/sec) > 0.008u 0.048s 0:00.84 4.7% 35+291k 0+258io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=32k count=2000 > 2000+0 records in > 2000+0 records out > 65536000 bytes transferred in 2.080178 secs (31504996 bytes/sec) > 0.000u 0.116s 0:02.08 5.2% 29+285k 1+500io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=64k count=2000 > 2000+0 records in > 2000+0 records out > 131072000 bytes transferred in 3.381287 secs (38763940 bytes/sec) > 0.000u 0.232s 0:03.39 6.7% 20+262k 2+1000io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=128k count=2000 > time dd if=/dev/zero of=/mnt/test bs=256k count=2000 > 2000+0 records in > 2000+0 records out > 262144000 bytes transferred in 6.768166 secs (38731910 bytes/sec) > 0.007u 0.477s 0:06.80 6.9% 26+495k 7+2000io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=256k count=2000 > time dd if=/dev/zero of=/mnt/test bs=512k count=2000 > 2000+0 records in > 2000+0 records out > 524288000 bytes transferred in 14.230285 secs (36843113 bytes/sec) > 0.000u 0.988s 0:14.29 6.8% 26+833k 6+4000io 0pf+0w > [nfs]# > [nfs]# time dd if=/dev/zero of=/mnt/test bs=512k count=2000 > 2000+0 records in > 2000+0 records out > 1048576000 bytes transferred in 28.617657 secs (36640875 bytes/sec) > 0.000u 2.113s 0:28.72 7.3% 25+1430k 29+8000io 0pf+0w > [nfs]# > > RELENG_5 > > [nfs]# time dd if=/dev/zero of=/mnt/test bs=16k count=2000 > 32768000 bytes transferred in 0.724865 secs (45205661 bytes/sec) > 0.000u 0.066s 0:00.73 8.2% 33+281k 0+250io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=32k count=2000 > 65536000 bytes transferred in 1.731888 secs (37840788 bytes/sec) > 0.000u 0.122s 0:01.74 6.8% 28+283k 0+500io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=64k count=2000 > 131072000 bytes transferred in 3.131403 secs (41857273 bytes/sec) > 0.000u 0.245s 0:03.14 7.6% 25+335k 0+1000io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=128k count=2000 > 262144000 bytes transferred in 6.973014 secs (37594073 bytes/sec) > 0.000u 0.509s 0:07.00 7.1% 26+510k 0+2000io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=256k count=2000 > 524288000 bytes transferred in 14.253915 secs (36782035 bytes/sec) > 0.000u 1.003s 0:14.30 6.9% 25+784k 0+4000io 0pf+0w > [nfs]# time dd if=/dev/zero of=/mnt/test bs=512k count=2000 > 1048576000 bytes transferred in 28.135716 secs (37268502 bytes/sec) > 0.008u 2.165s 0:28.21 7.6% 24+1386k 0+8000io 0pf+0w > [nfs]# > > > > NFS tests done from a RELENG_5 client with testfile.new in the servers > cache > > > [ns4-new]# time dd if=/dev/zero of=/mnt/testfile bs=16k count=16384 > 16384+0 records in > 16384+0 records out > 268435456 bytes transferred in 80.830089 secs (3320984 bytes/sec) > 0.020u 0.442s 1:20.90 0.5% 29+254k 0+32768io 0pf+0w > [ns4-new]# time dd if=/mnt/testfile.new of=/dev/null bs=16k > 16384+0 records in > 16384+0 records out > 268435456 bytes transferred in 0.290720 secs (923347100 bytes/sec) > 0.007u 0.283s 0:00.29 96.5% 26+227k 0+0io 0pf+0w > > postmark on nfs > > PostMark v1.5 : 3/27/01 > pm>set size 300 100000 > pm>set location /mnt > pm>set transactions 400 > pm>run > Creating files...Done > Performing transactions..........Done > Deleting files...Done > Time: > 68 seconds total > 64 seconds of transactions (6 per second) > > Files: > 697 created (10 per second) > Creation alone: 500 files (125 per second) > Mixed with transactions: 197 files (3 per second) > 194 read (3 per second) > 206 appended (3 per second) > 697 deleted (10 per second) > Deletion alone: 494 files (494 per second) > Mixed with transactions: 203 files (3 per second) > > Data: > 10.26 megabytes read (154.52 kilobytes per second) > 36.87 megabytes written (555.26 kilobytes per second) > > > > NFS on HEAD > > [ns4-new]# time dd if=/dev/zero of=/mnt/testfile bs=16k count=16384 > 16384+0 records in > 16384+0 records out > 268435456 bytes transferred in 52.172368 secs (5145165 bytes/sec) > 0.016u 0.465s 0:52.23 0.8% 24+208k 0+32768io 0pf+0w > [ns4-new]# time dd if=/mnt/testfile.new of=/dev/null bs=16k > 16384+1 records in > 16384+1 records out > 268435774 bytes transferred in 6.328295 secs (42418341 bytes/sec) > 0.023u 0.363s 0:06.36 5.9% 35+298k 0+0io 0pf+0w > [ns4-new]# > > PostMark v1.5 : 3/27/01 > pm>set location /mnt > pm>set size 300 100000 > pm>set transactions 400 > pm>run > Creating files...Done > Performing transactions..........Done > Deleting files...Done > Time: > 68 seconds total > 63 seconds of transactions (6 per second) > > Files: > 697 created (10 per second) > Creation alone: 500 files (125 per second) > Mixed with transactions: 197 files (3 per second) > 194 read (3 per second) > 206 appended (3 per second) > 697 deleted (10 per second) > Deletion alone: 494 files (494 per second) > Mixed with transactions: 203 files (3 per second) > > Data: > 10.26 megabytes read (154.52 kilobytes per second) > 36.87 megabytes written (555.26 kilobytes per second) > pm> > > NFS on head with vfs.nfsrv.async=1 > > [ns4-new]# time dd if=/dev/zero of=/mnt/testfile.async bs=16k count=16384 > 16384+0 records in > 16384+0 records out > 268435456 bytes transferred in 500.301252 secs (536548 bytes/sec) > 0.018u 0.453s 8:20.53 0.0% 22+194k 0+32768io 0pf+0w > [ns4-new]# > > _______________________________________________ > 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 Mon Jan 31 19:31:02 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A83916A4CE; Mon, 31 Jan 2005 19:31:02 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D8AB43D53; Mon, 31 Jan 2005 19:30:57 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j0VJUqLe016326; Mon, 31 Jan 2005 14:30:52 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15816-02; Mon, 31 Jan 2005 14:30:51 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j0VJUpd5016301; Mon, 31 Jan 2005 14:30:51 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id j0VJUjnC087447; Mon, 31 Jan 2005 14:30:45 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050131131350.0465d010@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 31 Jan 2005 14:31:37 -0500 To: noackjr@alumni.rice.edu From: Mike Tancsa In-Reply-To: <57938.69.53.57.66.1107194753.squirrel@69.53.57.66> References: <6.2.0.14.0.20050127213817.02f19220@64.7.153.2> <6.2.0.14.0.20050128145435.098e3d48@64.7.153.2> <6.2.1.2.0.20050131101913.045736f8@64.7.153.2> <57938.69.53.57.66.1107194753.squirrel@69.53.57.66> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: jeff@freebsd.org cc: Robert Watson cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 19:31:02 -0000 At 01:05 PM 31/01/2005, Jon Noack wrote: >Did you enable mpsafevfs on HEAD (as rwatson@ mentioned earlier in this >thread)? If not, I would be very curious to see how it impacts >performance. To enable it, set debug.mpsafevfs="1" in /boot/loader.conf >and reboot (mpsafevm is required, but it is enabled by default). Just re-ran them now. The seek value is kinda bogus as the machine has 2G of RAM. I could not run larger files as LINUX does not allow for greater than 2GB per file on ext3. If anything, postmark shows it to be slower, bonnie about the same. Just running iozone and will try and get all those together and post. [nfs]# sysctl -a | grep mps debug.mpsafevfs: 1 debug.mpsafenet: 1 debug.mpsafevm: 1 [nfs]# Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 2000 35166 28.7 35349 8.3 13192 3.3 49662 46.5 67611 9.1 12250.0 22.8 [nfs]# time dd if=/dev/zero of=/mnt/test bs=16k count=2000 2000+0 records in 2000+0 records out 32768000 bytes transferred in 0.784260 secs (41782060 bytes/sec) 0.000u 0.056s 0:00.78 6.4% 24+206k 0+250io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=32k count=2000 2000+0 records in 2000+0 records out 65536000 bytes transferred in 1.664780 secs (39366159 bytes/sec) 0.000u 0.114s 0:01.67 6.5% 20+198k 1+500io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=64k count=2000 2000+0 records in 2000+0 records out 131072000 bytes transferred in 3.415590 secs (38374629 bytes/sec) 0.000u 0.232s 0:03.43 6.7% 25+332k 6+1000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=128k count=2000 2000+0 records in 2000+0 records out 262144000 bytes transferred in 6.875836 secs (38125401 bytes/sec) 0.000u 0.486s 0:06.90 6.9% 24+465k 5+2000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=256k count=2000 2000+0 records in 2000+0 records out 524288000 bytes transferred in 14.336948 secs (36569010 bytes/sec) 0.000u 0.958s 0:14.38 6.6% 27+858k 5+4000io 0pf+0w [nfs]# time dd if=/dev/zero of=/mnt/test bs=512k count=2000 2000+0 records in 2000+0 records out 1048576000 bytes transferred in 28.392467 secs (36931486 bytes/sec) 0.008u 2.079s 0:28.47 7.2% 25+1412k 2+8000io 0pf+0w [nfs]# pm>set location /mnt pm>set size 300 100000 pm>set transactions 400000 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 2846 seconds total 2846 seconds of transactions (140 per second) Files: 200107 created (70 per second) Creation alone: 500 files (500 per second) Mixed with transactions: 199607 files (70 per second) 199905 read (70 per second) 199384 appended (70 per second) 200107 deleted (70 per second) Deletion alone: 889 files (889 per second) Mixed with transactions: 199218 files (69 per second) Data: 12715.55 megabytes read (4.47 megabytes per second) 12728.92 megabytes written (4.47 megabytes per second) pm> From owner-freebsd-performance@FreeBSD.ORG Tue Feb 1 04:59:59 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3913C16A4CE; Tue, 1 Feb 2005 04:59:59 +0000 (GMT) Received: from flake.decibel.org (flake.decibel.org [66.143.173.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E995843D3F; Tue, 1 Feb 2005 04:59:58 +0000 (GMT) (envelope-from decibel@decibel.org) Received: by flake.decibel.org (Postfix, from userid 1001) id 5E8D21C916; Mon, 31 Jan 2005 22:59:58 -0600 (CST) Date: Mon, 31 Jan 2005 22:59:58 -0600 From: "Jim C. Nasby" To: Robert Watson Message-ID: <20050201045958.GD32356@decibel.org> References: <20050130230527.GR64304@decibel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 4.10-RELEASE-p3 i386 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.6i cc: freebsd-performance@freebsd.org Subject: Re: Automated performance testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 04:59:59 -0000 On Mon, Jan 31, 2005 at 03:24:39PM +0000, Robert Watson wrote: > > On Sun, 30 Jan 2005, Jim C. Nasby wrote: > > > With all the discussion of performance testing between 4.11, 5.3, and > > Linux, would it be useful to make performance testing part of the > > automated testing that already occurs (via tinderbox, iirc). Doing so > > might make it easier to detect performance impacting changes, as well as > > making performance testing easier in general. > > Yes, it would be quite valuable. I've been hoping to set up something > like this for a while, but have never found the opportunity. I have been > tracking the long term behavior of MySQL performance as part of the > netperf work, but because testing is fairly hardware and time consuming, > the polling intervals are uneven, and not quite close enough to nail down > culprits. I'd really like to see a small and fairly well-defined set of > tests run every couple of days so we can show long term graphs, and catch > regressions quickly. Unfortunately, this is a bit harder than > tinder-boxing, because it involves swapping out whole system > configurations, recovering from the inevitable failure modes, etc, which > proves to be the usual sticking point in implementing this. However, I'd > love to see someone work on it :-). FWIW, I'd suggest something less complicated than a database for performance testing. For starters, there's no way to isolate what part of the OS (if any) is responsible for a performance change. Databases also continually improve their own performance, so it's very much a moving standard. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" From owner-freebsd-performance@FreeBSD.ORG Tue Feb 1 16:41:33 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C57016A4CF; Tue, 1 Feb 2005 16:41:33 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F03343D31; Tue, 1 Feb 2005 16:41:32 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j11GfVPR097771; Tue, 1 Feb 2005 11:41:31 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 97288-06; Tue, 1 Feb 2005 11:41:31 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j11GfVve097742; Tue, 1 Feb 2005 11:41:31 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id j11GfPTc091007; Tue, 1 Feb 2005 11:41:25 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050201113451.0313ee20@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 01 Feb 2005 11:42:18 -0500 To: freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> References: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1792450577==_" X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 16:41:33 -0000 --=====================_1792450577==_ Content-Type: text/plain; charset="us-ascii"; format=flowed I posted up an excel workbook at http://www.tancsa.com/iozone-tests.xls.bz2 This has the results of iozone on RELENG_5, HEAD, HEAD with debug.mpsafevfs=1 and LINUX 2.6.10 on ext3 as well as some quick NFS tests against RELENG_5 and LINUX as servers with FreeBSD RELENG-5 clients. Once again, the hardware is the same. The boot OS drives have changed, but the tests were all done against one large RAID5 partition. HTT disabled in the BIOS, using SCHED_4BSD on a 3ware 8xxx controller in RAID5 with 4 drives. dmesg attached. ---Mike --=====================_1792450577==_ Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMC1DVVJSRU5UICMxOiBNb24gSmFuIDMxIDA5OjA3OjMz IEVTVCAyMDA1CiAgICBtZHRhbmNzYUBuZnMuc2VudGV4LmNhOi91c3Ivb2JqL3Vzci9zcmMvc3lz L25mcwpBQ1BJIEFQSUMgVGFibGU6IDxBT3BlbiAgQVdSREFDUEk+ClRpbWVjb3VudGVyICJpODI1 NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogSW50ZWwoUikgUGVudGl1bShS KSA0IENQVSAzLjAwR0h6ICgyOTkyLjUxLU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJH ZW51aW5lSW50ZWwiICBJZCA9IDB4ZjQxICBTdGVwcGluZyA9IDEKICBGZWF0dXJlcz0weGJmZWJm YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1Ms SFRULFRNLFBCRT4KcmVhbCBtZW1vcnkgID0gMjE0NzQxODExMiAoMjA0NyBNQikKYXZhaWwgbWVt b3J5ID0gMjA5Njg1NzA4OCAoMTk5OSBNQikKaW9hcGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0y MyBvbiBtb3RoZXJib2FyZApucHgwOiBbRkFTVF0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBvbiBt b3RoZXJib2FyZApucHgwOiBJTlQgMTYgaW50ZXJmYWNlCmFjcGkwOiA8QU9wZW4gQVdSREFDUEk+ IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpUaW1lY291bnRlciAi QUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6 IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0MDA4LTB4NDAwYiBvbiBhY3Bp MApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4g b24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBv biBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAphZ3AwOiA8SW50ZWwgODI4NjUg aG9zdCB0byBBR1AgYnJpZGdlPiBtZW0gMHhmZDAwMDAwMC0weGZkM2ZmZmZmIGF0IGRldmljZSAw LjAgb24gcGNpMApwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAK cGNpMTogPFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAw LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMy4wIG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKZW0wOiA8SW50 ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9uIC0gMS43LjM1PiBwb3J0 IDB4YzAwMC0weGMwMWYgbWVtIDB4ZmQ0MDAwMDAtMHhmZDQxZmZmZiBpcnEgMTcgYXQgZGV2aWNl IDEuMCBvbiBwY2kyCmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDE6ODA6NTM6ZmY6MDQKZW0w OiAgU3BlZWQ6Ti9BICBEdXBsZXg6Ti9BCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDMwLjAgb24gcGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwplbTE6IDxJ bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24sIFZlcnNpb24gLSAxLjcuMzU+IHBv cnQgMHhkMDAwLTB4ZDAzZiBtZW0gMHhmYzgwMDAwMC0weGZjODFmZmZmLDB4ZmM4MjAwMDAtMHhm YzgzZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDQuMCBvbiBwY2kzCmVtMTogRXRoZXJuZXQgYWRkcmVz czogMDA6MGU6MGM6NWQ6Zjc6YzAKZW0xOiAgU3BlZWQ6Ti9BICBEdXBsZXg6Ti9BCnR3ZTA6IDwz d2FyZSBTdG9yYWdlIENvbnRyb2xsZXIuIERyaXZlciB2ZXJzaW9uIDEuNTAuMDEuMDAyPiBwb3J0 IDB4ZDEwMC0weGQxMGYgbWVtIDB4ZmMwMDAwMDAtMHhmYzdmZmZmZiBpcnEgMTcgYXQgZGV2aWNl IDUuMCBvbiBwY2kzCnR3ZTA6IFtHSUFOVC1MT0NLRURdCnR3ZTA6IDQgcG9ydHMsIEZpcm13YXJl IEZFN1MgMS4wNS4wMC4wNTYsIEJJT1MgQkU3WCAxLjA4LjAwLjA0Ngpmd29oY2kwOiA8THVjZW50 IEZXMzIyLzMyMz4gbWVtIDB4ZmM4NjAwMDAtMHhmYzg2MGZmZiBpcnEgMjIgYXQgZGV2aWNlIDEz LjAgb24gcGNpMwpmd29oY2kwOiBPSENJIHZlcnNpb24gMS4wIChST009MSkKZndvaGNpMDogTm8u IG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDguCmZ3b2hjaTA6IEVVSTY0IDAwOjAxOjgwOjEz Ojk0OjUzOmZmOjA1CmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMyBwb3J0cy4K ZndvaGNpMDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUx Mzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJl V2lyZT4gb24gZmlyZXdpcmUwCmZ3b2hjaTA6IEluaXRpYXRlIGJ1cyByZXNldApmd29oY2kwOiBu b2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2RlCmZpcmV3aXJlMDogMSBu b2RlcywgbWF4aG9wIDw9IDAsIGNhYmxlIElSTSA9IDAgKG1lKQpmaXJld2lyZTA6IGJ1cyBtYW5h Z2VyIDAgKG1lKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kw CmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgSUNINSBVRE1BMTAwIGNv bnRyb2xsZXI+IHBvcnQgMHhmMDAwLTB4ZjAwZiwweDM3NiwweDE3MC0weDE3NywweDNmNiwweDFm MC0weDFmNyBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6IGNoYW5uZWwgIzAgb24gYXRhcGNp MAphdGExOiBjaGFubmVsICMxIG9uIGF0YXBjaTAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBh dCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX3R6MDogPFRoZXJtYWwgWm9u ZT4gb24gYWNwaTAKcGNpX2xpbmswOiA8QUNQSSBQQ0kgTGluayBMTktBPiBpcnEgMTAgb24gYWNw aTAKcGNpX2xpbmsxOiA8QUNQSSBQQ0kgTGluayBMTktCPiBpcnEgMTEgb24gYWNwaTAKcGNpX2xp bmsyOiA8QUNQSSBQQ0kgTGluayBMTktDPiBpcnEgMCBvbiBhY3BpMApwY2lfbGluazM6IDxBQ1BJ IFBDSSBMaW5rIExOS0Q+IGlycSAwIG9uIGFjcGkwCnBjaV9saW5rNDogPEFDUEkgUENJIExpbmsg TE5LRT4gaXJxIDAgb24gYWNwaTAKcGNpX2xpbms1OiA8QUNQSSBQQ0kgTGluayBMTktGPiBpcnEg MCBvbiBhY3BpMApwY2lfbGluazY6IDxBQ1BJIFBDSSBMaW5rIExOSzA+IGlycSA1IG9uIGFjcGkw CnBjaV9saW5rNzogPEFDUEkgUENJIExpbmsgTE5LMT4gaXJxIDAgb24gYWNwaTAKc2lvMDogPDE2 NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4 MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEsIGNvbnNvbGUKc2lvMTogPDE2NTUwQS1jb21w YXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwCnNpbzE6IHR5 cGUgMTY1NTBBCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2 NCwweDYwIGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGti ZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogPFBTLzIgTW91 c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIElu dGVsbGlNb3VzZSBFeHBsb3JlciwgZGV2aWNlIElEIDQKcG10aW1lcjAgb24gaXNhMApvcm0wOiA8 SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGNkMDAwLTB4Y2RmZmYsMHhjYzAwMC0weGNjZmZm LDB4YzAwMDAtMHhjYTdmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAw eDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDEwMD4K dmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4KVGltZWNvdW50 ZXIgIlRTQyIgZnJlcXVlbmN5IDI5OTI1MTI1NDAgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJz IHRpY2sgZXZlcnkgMS4wMDAgbXNlYwppcGZ3MiBpbml0aWFsaXplZCwgZGl2ZXJ0IGxvYWRhYmxl LCBydWxlLWJhc2VkIGZvcndhcmRpbmcgZW5hYmxlZCwgZGVmYXVsdCB0byBhY2NlcHQsIGxvZ2dp bmcgbGltaXRlZCB0byAzMTAwIHBhY2tldHMvZW50cnkgYnkgZGVmYXVsdAphZDA6IDM4MTY2TUIg PFNUMzQwMDE0QS8zLjA2PiBbNzc1NDUvMTYvNjNdIGF0IGF0YTAtbWFzdGVyIFVETUExMDAKYWNk MDogRFZEUk9NIDxITC1EVC1TVERWRC1ST00gR0RSODE2M0IvMEwxNT4gYXQgYXRhMS1tYXN0ZXIg VURNQTMzCnR3ZWQwOiA8VW5pdCAwLCBSQUlENSwgTm9ybWFsPiBvbiB0d2UwCnR3ZWQwOiA3MTU0 MjJNQiAoMTQ2NTE4NTAyNCBzZWN0b3JzKQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczov ZGV2L2FkMHMxYQo= --=====================_1792450577==_-- From owner-freebsd-performance@FreeBSD.ORG Tue Feb 1 23:50:06 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1BCC16A4D6 for ; Tue, 1 Feb 2005 23:50:06 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE64643D53 for ; Tue, 1 Feb 2005 23:50:05 +0000 (GMT) (envelope-from linicks@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so92727rnz for ; Tue, 01 Feb 2005 15:50:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XPPXkN7F3don/g3JNCTBMW89cOtyIVx5jja1ydkrAnBaqu/8ZiSBrhqCWJq5B9UvEolvGBU9HqF/jwP0dCfDualaB5Br0d29rXAd56cluG8PGqfIWJwIIm1DI77e/BoM0Phdp+pWO/dCGpLIKGbdN/+m0MC6JJ6W4ffgxnq29Uo= Received: by 10.38.179.61 with SMTP id b61mr41737rnf; Tue, 01 Feb 2005 15:50:01 -0800 (PST) Received: by 10.38.8.20 with HTTP; Tue, 1 Feb 2005 15:50:01 -0800 (PST) Message-ID: Date: Tue, 1 Feb 2005 16:50:01 -0700 From: Nick Pavlica To: Robert Watson In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6.2.0.14.0.20050127213817.02f19220@64.7.153.2> cc: freebsd-performance@freebsd.org cc: freebsd-questions@freebsd.org cc: Mike Tancsa Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nick Pavlica List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 23:50:07 -0000 All, I was wondering if any progress has been made in determining the cause of the poor disk I/O performance illustrated by the testing in this thread? Now that 5.3 is labeled as the production stable version, and 4.x is labeled as legacy, improving the performance of the 5.4+ distributions is clearly important. I know that everyone is working hard to do this, and wanted to help by testing(retest, etc) the disk I/O performance on 5.4 devel/final and post the results as soon as possible. I would also like others to join me in this testing effort so that we have as much feedback as possible. My hope is that we will start bridging the large disk I/O performance gap demonstrated in the 4.11 & 5.3 testing. - When would be best time to start this testing? - What is the preferred method for keeping in sync with the current devel branch? I'm assuming cvs-up is the best method. Thanks! --Nick Pavlica On Fri, 28 Jan 2005 09:52:38 +0000 (GMT), Robert Watson wrote: > > On Thu, 27 Jan 2005, Mike Tancsa wrote: > > > >I/O (reads, writes at fairly large multiples of the sector size -- 512k is > > >a good number) and small I/O size (512 bytes is good). This will help > > >identify the source along two dimmensions: are we looking at a basic > > >storage I/O problem that's present even without the file system, or can we > > >conclude that some of the additional extra cost is in the file system code > > >or the hand off to it. Also, with the large and small I/O size, we can > > >perhaps draw some conclusions about to what extent the source is a > > >per-transaction overhead. > > > > Apart from postmark and iozone (directly to disk and over nfs), are > > there any particular tests you would like to see done ? > > Just to get started, using dd to read and write at various block sizes is > probably a decent start. Take a few samples, make sure there's a decent > sample size, etc, and don't count the first couple of runs. > > Robert N M Watson > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-performance@FreeBSD.ORG Wed Feb 2 03:50:23 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE1616A4D5 for ; Wed, 2 Feb 2005 03:50:23 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id D881743D4C for ; Wed, 2 Feb 2005 03:50:22 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j123oKwB068782; Tue, 1 Feb 2005 22:50:20 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68225-05; Tue, 1 Feb 2005 22:50:20 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j123oK00068775; Tue, 1 Feb 2005 22:50:20 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id j123oDcG002053; Tue, 1 Feb 2005 22:50:14 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050201193210.0489e6f8@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 01 Feb 2005 22:51:15 -0500 To: freebsd-performance@freebsd.org From: Mike Tancsa In-Reply-To: <6.2.1.2.0.20050201113451.0313ee20@64.7.153.2> References: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> <6.2.1.2.0.20050201113451.0313ee20@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 and dragonfly X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 03:50:23 -0000 OK, I updated the xls file to include tests on DragonFly 1.1-Stable DragonFly 1.1-Stable #0: Wed Jan 26 13:15:16 GMT 2005 File is at http://www.tancsa.com/iozone-tests-2.xls.bz2 It seems to do quite well. Unfortunately without ACL support I cant use it for this app. -------Sequential Output-------- ---Sequential Input-- --Random--* -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU F 2000 33789 25.8 34065 8.3 14038 3.8 47484 44.6 67316 9.5 2873.7 5.7 L 2000 28073 62.0 22391 4.3 12189 2.0 17577 35.5 102132 5.5 1853.7 2.5 H 2000 33301 27.9 34832 8.3 12872 3.4 49762 46.8 67274 9.2 8078.1 15.1 D 2000 38532 26.2 38204 6.4 19689 4.6 82366 90.5 92569 10.0 5071.9 8.9 * I would throw this value out as the box has 2G of RAM... ...via nfs mount - client is RELENG_5, server Dragonfly (default options on both sides) [ns4-new]# time dd if=/dev/zero of=/mnt/testfile2 bs=16k count=16384 16384+0 records in 16384+0 records out 268435456 bytes transferred in 45.605148 secs (5886078 bytes/sec) 0.008u 0.492s 0:45.62 1.0% 23+200k 0+32768io 0pf+0w [ns4-new]# postmark is pretty well the same as linux. # gcc postmark-1_5.c # ./a.out PostMark v1.5 : 3/27/01 pm>set location /mnt pm>set size 300 100000 pm>set transactions 400000 pm>run Creating files...Done Performing transactions..........Done Deleting files...Done Time: 1794 seconds total 1794 seconds of transactions (222 per second) Files: 200107 created (111 per second) Creation alone: 500 files (500 per second) Mixed with transactions: 199607 files (111 per second) 199905 read (111 per second) 199384 appended (111 per second) 200107 deleted (111 per second) Deletion alone: 889 files (889 per second) Mixed with transactions: 199218 files (111 per second) Data: 12715.55 megabytes read (7.09 megabytes per second) 12728.92 megabytes written (7.10 megabytes per second) pm> At 11:42 AM 01/02/2005, Mike Tancsa wrote: >I posted up an excel workbook at >http://www.tancsa.com/iozone-tests.xls.bz2 > > >This has the results of iozone on RELENG_5, HEAD, HEAD with >debug.mpsafevfs=1 and LINUX 2.6.10 on ext3 as well as some quick NFS tests >against RELENG_5 and LINUX as servers with FreeBSD RELENG-5 clients. > >Once again, the hardware is the same. The boot OS drives have changed, but >the tests were all done against one large RAID5 partition. > >HTT disabled in the BIOS, using SCHED_4BSD on a 3ware 8xxx controller in >RAID5 with 4 drives. dmesg attached. > > ---Mike > > >_______________________________________________ >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 Wed Feb 2 22:19:25 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B571016A4CE for ; Wed, 2 Feb 2005 22:19:25 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0311B43D1F for ; Wed, 2 Feb 2005 22:19:25 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j12MJNmQ033040; Wed, 2 Feb 2005 17:19:23 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32132-10; Wed, 2 Feb 2005 17:19:22 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j12MJMFh033020; Wed, 2 Feb 2005 17:19:22 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id j12MJGjP005848; Wed, 2 Feb 2005 17:19:17 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050202170217.02d509e0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 02 Feb 2005 17:21:11 -0500 To: Matthew Dillon From: Mike Tancsa In-Reply-To: <200502022158.j12LwxGn002992@apollo.backplane.com> References: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> <6.2.1.2.0.20050201113451.0313ee20@64.7.153.2> <6.2.1.2.0.20050201193210.0489e6f8@64.7.153.2> <200502022158.j12LwxGn002992@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 and dragonfly X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 22:19:26 -0000 At 04:58 PM 02/02/2005, Matthew Dillon wrote: > Urmmm. how about a bit more information... what are the machine > configurations? Sorry, it was a few postings ago in the same thread. Its Pentium(R) 4 CPU 3.00GHz 2GB RAM Intel Gig NICs (em) One big RAID5 partition on a 8xxx 3ware with 4 SATA drives, default options on the 3ware. full dmesg at http://lists.freebsd.org/pipermail/freebsd-performance/2005-February/001077.html Apart from the dragonfly boot CD, I had a separate IDE disk for the OSes that I would boot from so that the partition info for the 3ware would remain the same. [nfs]# diskinfo -tv twed0s1d twed0s1d 512 # sectorsize 750170179584 # mediasize in bytes (699G) 1465176132 # mediasize in sectors 91202 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 4.393885 sec = 17.576 msec Half stroke: 250 iter in 4.386907 sec = 17.548 msec Quarter stroke: 500 iter in 6.939157 sec = 13.878 msec Short forward: 400 iter in 2.234404 sec = 5.586 msec Short backward: 400 iter in 2.124618 sec = 5.312 msec Seq outer: 2048 iter in 0.360554 sec = 0.176 msec Seq inner: 2048 iter in 0.386926 sec = 0.189 msec Transfer rates: outside: 102400 kbytes in 1.443528 sec = 70937 kbytes/sec middle: 102400 kbytes in 1.399967 sec = 73145 kbytes/sec inside: 102400 kbytes in 1.428718 sec = 71673 kbytes/sec [nfs]# > I can figure some things out. Clearly the BSD write numbers are dropping > at a block size of 2048 due to vfs.write_behind being set to 1. Interesting, I didnt know of this. I really should re-read tuning(8). What are the dangers of setting it to zero? > Just as > clearly, Linux is not bothering to write out ANY data, and then able to > take advantage of the fact that the test file is being destroyed by > iozone (so it can throw away the data rather then write it out). This > skews the numbers to the point where the benchmark doesn't even come > close > to reflecting reality, though I do believe it points to an issue with > the BSDs ... the write_behind heuristic is completely out of date now > and needs to be reworked. http://www.iozone.org is what I was using to test with. Although right now, the box I am trying to put together is a Samba and NFS server for mostly static web content. In the not too distant future, a file server for IMAP/POP3 front ends. I think postmark does a good job at simulating that. Are there better benchmarks / methods of testing that would give a more fair comparison that you know of? I know all benchmarks have many caveats, but I am trying to approach this somewhat methodically. I am just about to start another round of testing with nfs using multiple machines pounding the one server. I was just going to run postmark on the 3 clients machines (starting out at the same time). Ultimately I dont give a toss if one is 10% or even 20% better than the other. For that money, a few hundred dollars in RAM and CPU would change that. We are mostly a BSD shop so I dont want to deploy a LINUX box for 25% faster disk I/O. But if the differences are far more acute, I need to perhaps take a bit more notice. > The read tests are less clear. iozone runs its read tests just after > it runs its write tests. so filesystem syncing and write flushing is > going to have a huge effect on the read numbers. I suspect that this > is skewing the results across the spectrum. In particular, I don't > see anywhere near the difference in cache-read performance between > FreeBSD-5 and DragonFly. But I guess I'll have to load up a few test > boxes myself and do my own comparisons to figure out what is going on. > > -Matt From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 05:39:11 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9980516A4CE for ; Thu, 3 Feb 2005 05:39:11 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15AF843D49 for ; Thu, 3 Feb 2005 05:39:11 +0000 (GMT) (envelope-from linicks@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so143131rns for ; Wed, 02 Feb 2005 21:39:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=p78Bf2t+l9ohNKq18ssOWtMKWEQUnkdcqgapyXmwofaLg55/MQ8rrQy9Y7M0gGdyUcooLXSgxhChxzbVTUO+Y/ouEy26a+ofx8Y9CLvM3JfoNkqKj+JqIseTxMYXvBjJ6USoWRNzCJwDb8WnUYPHUPBe3JJ3KPf/Uz+YPG4kPqI= Received: by 10.38.206.45 with SMTP id d45mr411525rng; Wed, 02 Feb 2005 21:39:10 -0800 (PST) Received: by 10.38.8.20 with HTTP; Wed, 2 Feb 2005 21:39:10 -0800 (PST) Message-ID: Date: Wed, 2 Feb 2005 22:39:10 -0700 From: Nick Pavlica To: freebsd-performance@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Joining The Performance List - I/O Testing X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nick Pavlica List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 05:39:11 -0000 All, I decided to join this list so that I could do a better job of staying on top of the I/O performance testing. I have moved my 5.3 test server from RELENG_5_3 to RELENG_5 (2/2/05) and did some testing. I had almost identical results to my previous testing. Iostat indicates that I'm getting approximately 15Mb/sec on 5.x, and 58Mb/sec when I use 4.11. These figure are consistent on my current test boxes. 1) Dell SC400, 256Mb Ram, 40Gb EIDE. 2) Dell 4600, 512Mb Ram, 80GB EIDE. I also tested with NetBSD 2.0 and OpenBSD 3.6 and had similar performance to FreeBSD 4.11 (approx. 58Mb/Sec.) --Nick Pavlica Note: EXT3 allows file sizes greater than 2Gb. I have created hundreds, if not thousands of them. From owner-freebsd-performance@FreeBSD.ORG Wed Feb 2 21:59:00 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 482CA16A4CE for ; Wed, 2 Feb 2005 21:59:00 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1651C43D1F for ; Wed, 2 Feb 2005 21:59:00 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j12Lwx0e002993; Wed, 2 Feb 2005 13:58:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j12LwxGn002992; Wed, 2 Feb 2005 13:58:59 -0800 (PST) (envelope-from dillon) Date: Wed, 2 Feb 2005 13:58:59 -0800 (PST) From: Matthew Dillon Message-Id: <200502022158.j12LwxGn002992@apollo.backplane.com> To: Mike Tancsa References: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> <6.2.1.2.0.20050201193210.0489e6f8@64.7.153.2> X-Mailman-Approved-At: Thu, 03 Feb 2005 13:17:28 +0000 cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 and dragonfly X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 21:59:00 -0000 Urmmm. how about a bit more information... what are the machine configurations? The disk topology? The networking? The graphs are almost completely unannotated, it's hard to figure out what the numbers actually mean. I can figure some things out. Clearly the BSD write numbers are dropping at a block size of 2048 due to vfs.write_behind being set to 1. Just as clearly, Linux is not bothering to write out ANY data, and then able to take advantage of the fact that the test file is being destroyed by iozone (so it can throw away the data rather then write it out). This skews the numbers to the point where the benchmark doesn't even come close to reflecting reality, though I do believe it points to an issue with the BSDs ... the write_behind heuristic is completely out of date now and needs to be reworked. The read tests are less clear. iozone runs its read tests just after it runs its write tests. so filesystem syncing and write flushing is going to have a huge effect on the read numbers. I suspect that this is skewing the results across the spectrum. In particular, I don't see anywhere near the difference in cache-read performance between FreeBSD-5 and DragonFly. But I guess I'll have to load up a few test boxes myself and do my own comparisons to figure out what is going on. -Matt From owner-freebsd-performance@FreeBSD.ORG Wed Feb 2 23:04:46 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A439016A4CE for ; Wed, 2 Feb 2005 23:04:46 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18F5E43D31 for ; Wed, 2 Feb 2005 23:04:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) j12N4j0e003212; Wed, 2 Feb 2005 15:04:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j12N4jNu003211; Wed, 2 Feb 2005 15:04:45 -0800 (PST) (envelope-from dillon) Date: Wed, 2 Feb 2005 15:04:45 -0800 (PST) From: Matthew Dillon Message-Id: <200502022304.j12N4jNu003211@apollo.backplane.com> To: Mike Tancsa References: <20050130120437.93214.qmail@web26810.mail.ukl.yahoo.com> <6.2.1.2.0.20050201113451.0313ee20@64.7.153.2> <6.2.1.2.0.20050201193210.0489e6f8@64.7.153.2> <6.2.1.2.0.20050202170217.02d509e0@64.7.153.2> X-Mailman-Approved-At: Thu, 03 Feb 2005 13:17:28 +0000 cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 and dragonfly X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 23:04:46 -0000 :> I can figure some things out. Clearly the BSD write numbers are dropping :> at a block size of 2048 due to vfs.write_behind being set to 1. : :Interesting, I didnt know of this. I really should re-read tuning(8). What :are the dangers of setting it to zero? There are three issues here. First is how much of the buffer cache you want to allow a single application to monopolize. Second is our historically terrible filesystem syncer and buffer cache dirty page management. Third is the fact that we even *HAVE* a buffer cache for reads that the system should be extracting directly out of the VM object. If you turn off write_behind a single application (the benchmark) can monopolize the buffer cache and greatly reduce the cache performance of other applications. So e.g. on a large system doing lots of things you would want to leave this on (in its current incarnation). The idea behind the write-behind code is to flush out data blocks when enough data is present to be reasonably efficient to the disk. Right now that is approximately 64KB of data but 'small writes' do not trigger the clustering code, hence the 2K transition you are seeing. The write-behind code also depresses the priority of the underlying VM pages allowing them to be reused more quickly relative to other applications running in the system, the idea being that data written in large blocks is unlikely to be read again any time soon. The second issue is our historically terrible filesystem syncer. The write_behind greatly reduces the burden on the buffer cache and makes it work better. If you turn it off, applications other then the benchmark trying to use the system will probably get pretty sludgy due to blockages in the buffer cache created by the benchmark. In FreeBSD-5 the vnode dirty/clean buffer list is now a splay tree, which is an improvement over what we had before but the real issue with the filesystem syncer is the fact that it tries to write out every single dirty buffer associated with a file all at once. What it really needs to do (and OpenBSD or NetBSD does this) is only write out up to X (1) megabytes of data, remember where it left off, and then proceed to the next dirty file. The write_behind code really needs to be replaced with something integrated into a filesystem syncer (as described above). That is, it should detect the existance of a large amount of sequential dirty data and it should kick another thread to flush it out synchronously, but it should not try to do it itself asynchronously. The big problem with trying to buffer that much data asynchronously is that you wind up blocking on the disk device when the file is removed because so much I/O is marked 'in progress'. The data set size should be increased from 64KB to 1MB as well. If the flushing can be done correctly it should be possible to have a good implementation of write_behind WITHOUT impacting cache performance. The third issue is the fact that we even have a buffer cache for things like read() that would be better served going directly to the VM object. I suspect that cache performance could be increased by a huge amount by having the file->read go directly to the VM object instead of recursing through 8 subroutine levels, instantiating, and garbage collecting the buffer cache. :> clearly, Linux is not bothering to write out ANY data, and then able to :> take advantage of the fact that the test file is being destroyed by :> iozone (so it can throw away the data rather then write it out). This :> skews the numbers to the point where the benchmark doesn't even come :> close :> to reflecting reality, though I do believe it points to an issue with :> the BSDs ... the write_behind heuristic is completely out of date now :> and needs to be reworked. : :http://www.iozone.org is what I was using to test with. Although right :now, the box I am trying to put together is a Samba and NFS server for :mostly static web content. : :In the not too distant future, a file server for IMAP/POP3 front ends. I :think postmark does a good job at simulating that. : :Are there better benchmarks / methods of testing that would give a more :fair comparison that you know of? I know all benchmarks have many caveats, :but I am trying to approach this somewhat methodically. I am just about to :start another round of testing with nfs using multiple machines pounding :the one server. I was just going to run postmark on the 3 clients machines :(starting out at the same time). Boy, I just don't know. Benchmarks have their uses, but the ones that simulate more then one processs accessing the disk are almost certainly more realistic the ones like iozone which just run a single process and do best when they are allowed to monopolizing the entire system. Bonnie is probably more accurate then iozone, it at least tries a lot harder to avoid side effects from prior tests. :Ultimately I dont give a toss if one is 10% or even 20% better than the :other. For that money, a few hundred dollars in RAM and CPU would change :that. We are mostly a BSD shop so I dont want to deploy a LINUX box for :25% faster disk I/O. But if the differences are far more acute, I need to :perhaps take a bit more notice. : :> The read tests are less clear. iozone runs its read tests just after :> it runs its write tests. so filesystem syncing and write flushing is :> going to have a huge effect on the read numbers. I suspect that this :> is skewing the results across the spectrum. In particular, I don't :> see anywhere near the difference in cache-read performance between :> FreeBSD-5 and DragonFly. But I guess I'll have to load up a few test :> boxes myself and do my own comparisons to figure out what is going on. :> Well, the 4-way explains the cache performance on the read tests at least. What you are seeing is the BGL removal in FreeBSD-5 verses DFly. Try it on a UP machine, though, and I'll bet the numbers will be reversed. In anycase, the #1 issue that should be on both our plates is fixing up the filesystem syncer and modernizing the write_behind code. -Matt Matthew Dillon From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 14:45:14 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEAAE16A524; Thu, 3 Feb 2005 14:45:13 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5096A43D64; Thu, 3 Feb 2005 14:45:13 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 79DD646B85; Thu, 3 Feb 2005 09:45:12 -0500 (EST) Date: Thu, 3 Feb 2005 14:44:24 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nick Pavlica In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-performance@freebsd.org cc: freebsd-questions@freebsd.org cc: Mike Tancsa Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 14:45:14 -0000 On Tue, 1 Feb 2005, Nick Pavlica wrote: > I was wondering if any progress has been made in determining the cause > of the poor disk I/O performance illustrated by the testing in this > thread? Now that 5.3 is labeled as the production stable version, and > 4.x is labeled as legacy, improving the performance of the 5.4+ > distributions is clearly important. I know that everyone is working > hard to do this, and wanted to help by testing(retest, etc) the disk > I/O performance on 5.4 devel/final and post the results as soon as > possible. I would also like others to join me in this testing effort so > that we have as much feedback as possible. My hope is that we will > start bridging the large disk I/O performance gap demonstrated in the > 4.11 & 5.3 testing. Per my out of band e-mail a bit earlier, I was wondering if I could get you to produce a concise write-up of the various benchmarks you're running, and the specific configurations and results so far. I'd like to reproduce the scenario in a test cluster, but want to make sure I'm looking at the same issue syou're looking at :-). > - When would be best time to start this testing? - What is the > preferred method for keeping in sync with the current devel branch? I'm > assuming cvs-up is the best method. I've found the best way to track branches is to mirror the CVS repository using cvsup and no tag, then to locally check out specific work trees. This allows you to easily slide files across revisions, helping to track down specific changes that may have been the source of regression or improvement. It also makes it easier to answer the question "What are you running" :-). Regarding when to start running -- now is as good a time as any. The VFS SMP work seems to have settled some, so it's now a variable that can be frobbed fairly safely as part of testing. Robert N M Watson > > Thanks! > --Nick Pavlica > > > > > > > On Fri, 28 Jan 2005 09:52:38 +0000 (GMT), Robert Watson > wrote: > > > > On Thu, 27 Jan 2005, Mike Tancsa wrote: > > > > > >I/O (reads, writes at fairly large multiples of the sector size -- 512k is > > > >a good number) and small I/O size (512 bytes is good). This will help > > > >identify the source along two dimmensions: are we looking at a basic > > > >storage I/O problem that's present even without the file system, or can we > > > >conclude that some of the additional extra cost is in the file system code > > > >or the hand off to it. Also, with the large and small I/O size, we can > > > >perhaps draw some conclusions about to what extent the source is a > > > >per-transaction overhead. > > > > > > Apart from postmark and iozone (directly to disk and over nfs), are > > > there any particular tests you would like to see done ? > > > > Just to get started, using dd to read and write at various block sizes is > > probably a decent start. Take a few samples, make sure there's a decent > > sample size, etc, and don't count the first couple of runs. > > > > Robert N M Watson > > > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > > > From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 16:42:11 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD6616A4CE for ; Thu, 3 Feb 2005 16:42:11 +0000 (GMT) Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EC5F43D49 for ; Thu, 3 Feb 2005 16:42:11 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 96118 invoked by uid 60001); 3 Feb 2005 16:42:10 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=fGBaAHkrKnRGHihuvpQFEcsu2Ge5No56urRAdlfn137qMT/XTZSvPri0OHMgTjlnQAQyrVplyEplMB/hLytIWyuXkxreTVzX5qwQlwjFHyGtgaTlwOLsmk7+WfwC0O37/auz0iXU8Hi0h5S7HvmUciTE7frMm4JGdyQBBCNWjnk= ; Message-ID: <20050203164210.96116.qmail@web41205.mail.yahoo.com> Received: from [83.129.195.144] by web41205.mail.yahoo.com via HTTP; Thu, 03 Feb 2005 08:42:09 PST Date: Thu, 3 Feb 2005 08:42:09 -0800 (PST) From: Arne "Wörner" To: freebsd-performance@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 16:42:12 -0000 I just tested R5.1 with a time -c "dd if=/dev/zero of=a bs=64k count=1000 ; fsync a" and it was 4 or about 4 times fast than with R5.3. Is it smart to start looking for regressive changes in sys/dev/ata or in /sys/kern? I mean: Did somebody see this phaenomenon on a SCSI disc, too? -Arne __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 16:51:30 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 810D916A4CE for ; Thu, 3 Feb 2005 16:51:30 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46F9C43D2F for ; Thu, 3 Feb 2005 16:51:30 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 97D0546B7E; Thu, 3 Feb 2005 11:51:29 -0500 (EST) Date: Thu, 3 Feb 2005 16:50:41 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Arne WXrner In-Reply-To: <20050203164210.96116.qmail@web41205.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 16:51:30 -0000 On Thu, 3 Feb 2005, Arne WXrner wrote: > I just tested R5.1 with a > time -c "dd if=/dev/zero of=a bs=64k count=1000 ; fsync a" and it was > 4 or about 4 times fast than with R5.3. > > Is it smart to start looking for regressive changes in sys/dev/ata or in > /sys/kern? > > I mean: Did somebody see this phaenomenon on a SCSI disc, too? I'd start by checking to see if the driver/hardware have negotiated the same ATA DMA paramaters or not. Specifically, what UDMA level (etc) was negotiated). Robert N M Watson From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 18:09:38 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5E2216A4CE for ; Thu, 3 Feb 2005 18:09:38 +0000 (GMT) Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by mx1.FreeBSD.org (Postfix) with SMTP id 809B043D45 for ; Thu, 3 Feb 2005 18:09:38 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 48104 invoked by uid 60001); 3 Feb 2005 18:09:38 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=mRuTkfiIpBKkYLzty5qbIoJduaGGLk321lsNfS9xbXou3HVWaAPxHZKMgt7U2kkKwA8MpWHFeqhkf1yZEoFtrOanN6rwmX58550XmvNREQDc4MiYlRlKda4Gv5s5tNb9mlX5zu2QLzxJt4N+Ty66llh1bm2bI83SNwvwR946fNo= ; Message-ID: <20050203180938.48102.qmail@web41215.mail.yahoo.com> Received: from [83.129.195.144] by web41215.mail.yahoo.com via HTTP; Thu, 03 Feb 2005 10:09:38 PST Date: Thu, 3 Feb 2005 10:09:38 -0800 (PST) From: Arne "Wörner" To: Robert Watson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-performance@freebsd.org Subject: Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 18:09:39 -0000 --- Robert Watson wrote: > On Thu, 3 Feb 2005, Arne WXrner wrote: > > I just tested R5.1 with a > > time -c "dd if=/dev/zero of=a bs=64k count=1000 ; fsync a" > > and it was 4 or about 4 times fast than with R5.3. > > > > Is it smart to start looking for regressive changes in > > sys/dev/ata or in /sys/kern? > > > > I mean: Did somebody see this phaenomenon on a SCSI disc, too? > > I'd start by checking to see if the driver/hardware have > negotiated the same ATA DMA paramaters or not. > Specifically, what UDMA level (etc) was negotiated). > Hmm. I just know, how to find out the UDMA level: They are for both devices at that ATA channel: UDMA100 ad0: 38166MB [77545/16/63] at ata0-master UDMA100 ad1: 152627MB [310101/16/63] at ata0-slave UDMA100 R5.3 behaves not worse, when I drop ad0 to UDMA66 with atacontrol. -Arne __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 22:36:39 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C732B16A4CE for ; Thu, 3 Feb 2005 22:36:39 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD86943D2F for ; Thu, 3 Feb 2005 22:36:38 +0000 (GMT) (envelope-from linicks@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so255027rnz for ; Thu, 03 Feb 2005 14:36:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=FQxjg6yhlfemM+uqDkUjrEcinjr+USOtg/KWQuXUfUSE7kOhmUVzar8zzeupjNoUpnMYOluvT2NRT3J6gBzos9/LQEgZKsy7ZTnH1N2tz1Rv2yQwtUbyqG3vPugM9NjCTppge5n+U9prGGcsGfz13jBcnVAHzmTHn6on2NG/58o= Received: by 10.38.19.34 with SMTP id 34mr29012rns; Thu, 03 Feb 2005 14:36:37 -0800 (PST) Received: by 10.38.8.20 with HTTP; Thu, 3 Feb 2005 14:36:37 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2005 15:36:37 -0700 From: Nick Pavlica To: freebsd-performance@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nick Pavlica List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 22:36:39 -0000 All, I would like to share the methods that I have been using in my disk I/O testing. The detailed results of these tests have been posted to the performance and questions mailing lists under the title " FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion". I originally started this testing as due diligence in an up coming project. As a result of this testing I discovered an elegant operating system that I enjoy working with. Intent Of This Testing: 1)To measure the disk I/O performance of various operating systems for use as a production database server. 2)Help improve the disk I/O performance of FreeBSD 5.x and greater by assisting the FreeBSD development team in identifying possible performance issues, and provide them with data to measure the success of various changes to the operating system. Operating Systems tested: Fedora Core 3 with EXT3, and XFS. I tested with and with out patches. SUSE Enterprise Server 9 with Riser FS. FreeBSD 4.11R FreeBSD 5.3R, RELENG_5_3, RELENG_5 NetBSD 2.0R OpenBSD 3.6R Test Hardware: Compaq DeskPro, PIII 800, 384Mb Ram, 10Gb IDE HD. Dell PE 2400, Dual PIII 550, 512Mb Ram, (2)10K,LVD SCSI, RAID 1, PERC 2SI controller with 64Mb ram. Dell PE SC400, 2.4Ghz P4, 256MB Ram, 40Gb IDE HD. Dell 4600, 2.8 Ghz P4 with HT, 512MB Ram, 80GB IDE HD. Installation Notes: It's my intention to test these Operating Systems using as many of the default installation options as possible with no special tuning. The only deviations in my previous testing were as follows: The #linux xfs option was used when installing Fedora so that I could use XFS, and a special test where I installed 5.3R with UFS instead of UFS2 (I didn't see any improvement when using UFS). I installed FreeBSD using the standard install option, and used the auto allocate features for partitioning and slicing. I installed Fedora with the stock server packages and created a 100Mb /boot, 512Mb swap, and allocated the remaining space to /. I tested FreeBSD5.3R and FC3R with and without updates. I used cvsup to update FreeBSD and yum update to update Fedora. I didn't do any updating to FreeBSD4.11R, NetBSD2.0, and OpenBSD3.6. I used the following utilities/tools in my testing: DD CP IOSTAT (iostat -d 2) Bonnie++ TOP SQL,PL, PSQL Postgresql 8.0 DD Example Tests: - #time dd bs=1024 if=/dev/zero of=tstfile count=1M - #time dd bs=1024 if=/dev/zero of=tstfile count=2M - #time dd bs=1024 if=/dev/zero of=tstfile count=3M Bonnie++ Example Tests: #bonnie++ -u root -s 1024 -r 512 -n 5 #bonnie++ -u root -s 2048 -r 512 -n 5 #bonnie++ -u root -s 3072 -r 512 -n 5 CP Example Tests: #time cp tstfile tstfile2 SQL, PL, PSQL Example Tests: CREATE TABLE test1 ( thedate TIMESTAMP, astring VARCHAR(200), anumber INTEGER ); CREATE FUNCTION build_data() RETURNS integer AS ' DECLARE i INTEGER DEFAULT 0; curtime TIMESTAMP; BEGIN FOR i IN 1..1000000 LOOP curtime := ''now''; INSERT INTO test1 VALUES (curtime, ''test string'', i); END LOOP; RETURN 1; END; ' LANGUAGE 'plpgsql'; SELECT build_data(); Then the following script is run under the time program to ascertain how long it takes to run: CREATE TABLE test2 ( thedate TIMESTAMP, astring VARCHAR(200), anumber INTEGER ); CREATE TABLE test3 AS SELECT * FROM test1; INSERT INTO test2 SELECT * FROM test1 WHERE ((anumber % 2) = 0); DELETE FROM test3 WHERE ((anumber % 2) = 0); DELETE FROM test3 WHERE ((anumber % 13) = 0); CREATE TABLE test4 AS SELECT test1.thedate AS t1date, test2.thedate AS t2date, test1.astring AS t1string, test2.astring AS t2string, test1.anumber AS t1number, test2.anumber AS t2number FROM test1 JOIN test2 ON test1.anumber=test2.anumber; UPDATE test3 SET thedate='now' WHERE ((anumber % 5) = 0); DROP TABLE test4; CREATE TABLE test4 AS SELECT * FROM test1; DELETE FROM test4 WHERE ((anumber % 27) = 0); VACUUM ANALYZE; VACUUM FULL; DROP TABLE test4; DROP TABLE test3; DROP TABLE test2; VACUUM FULL; Example FS TAB: minime# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1e /tmp ufs rw 2 2 /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1d /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 Verification Of Test: I have been able to get consistent results in all of my testing. However, I think the best verification would be to have as many people as possible test the disk I/O performance on a range of hardware, testing methods, and configurations. Summary Of Results: The results of my testing have consistently demonstrated that FreeBSD5.3+ has dramatically slower disk I/O performance than all of the other operating systems that were tested. FreeBSD 4.11R was the performance leader followed by Fedora C3 with XFS. All of the BSD distributions, with the exception of 5.3+, were able to consistently demonstrate a throughput of 56-58Mb/s sustained throughput, while 5.3+ consistently demonstrated a throughput of 12-15Mb/s (58 -15 = 43 ?). Please let me know if you need any additional details. Thanks! --Nick Pavlica From owner-freebsd-performance@FreeBSD.ORG Thu Feb 3 22:59:33 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5740A16A4CE for ; Thu, 3 Feb 2005 22:59:33 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7608D43D2D for ; Thu, 3 Feb 2005 22:59:32 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j13MxVc5062819; Thu, 3 Feb 2005 17:59:31 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j13MxVBv062816; Thu, 3 Feb 2005 17:59:31 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Thu, 3 Feb 2005 17:59:30 -0500 (EST) From: Jeff Roberson To: Nick Pavlica In-Reply-To: Message-ID: <20050203175519.K18864@mail.chesapeake.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-performance@freebsd.org Subject: Re: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 22:59:33 -0000 On Thu, 3 Feb 2005, Nick Pavlica wrote: > All, > I would like to share the methods that I have been using in my disk > I/O testing. The detailed results of these tests have been posted to > the performance and questions mailing lists under the title " FreeBSD > 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion". I > originally started this testing as due diligence in an up coming > project. As a result of this testing I discovered an elegant > operating system that I enjoy working with. Nick, first, I'd like to thank you for your efforts so far. I think your tests have been very informative. I'd like to see what we can do to get to the bottom of the differences. Can you perform one test which varied greatly between 5.x and 4.x and collect some data for us? To start with, the output of vmstat 1 piped to a file would be informative. Do you have any indication that 5.x is actually cpu bound in a case where 4.x is not? I'm wondering if this is a latency issue or a cpu utilization issue. I intend to backport some code that lets me graph system activity into RELENG_5. Are you setup to cvsup to this tag? Would it be convenient for you to do so? Thanks, Jeff > > Intent Of This Testing: > 1)To measure the disk I/O performance of various operating systems for > use as a production database server. > 2)Help improve the disk I/O performance of FreeBSD 5.x and greater by > assisting the FreeBSD development team in identifying possible > performance issues, and provide them with data to measure the success > of various changes to the operating system. > > Operating Systems tested: > Fedora Core 3 with EXT3, and XFS. I tested with and with out patches. > SUSE Enterprise Server 9 with Riser FS. > FreeBSD 4.11R > FreeBSD 5.3R, RELENG_5_3, RELENG_5 > NetBSD 2.0R > OpenBSD 3.6R > > Test Hardware: > Compaq DeskPro, PIII 800, 384Mb Ram, 10Gb IDE HD. > Dell PE 2400, Dual PIII 550, 512Mb Ram, (2)10K,LVD SCSI, RAID 1, PERC > 2SI controller with 64Mb ram. > Dell PE SC400, 2.4Ghz P4, 256MB Ram, 40Gb IDE HD. > Dell 4600, 2.8 Ghz P4 with HT, 512MB Ram, 80GB IDE HD. > > Installation Notes: > It's my intention to test these Operating Systems using as many of > the default installation options as possible with no special tuning. > The only deviations in my previous testing were as follows: The #linux > xfs option was used when installing Fedora so that I could use XFS, > and a special test where I installed 5.3R with UFS instead of UFS2 (I > didn't see any improvement when using UFS). I installed FreeBSD using > the standard install option, and used the auto allocate features for > partitioning and slicing. I installed Fedora with the stock server > packages and created a 100Mb /boot, 512Mb swap, and allocated the > remaining space to /. I tested FreeBSD5.3R and FC3R with and without > updates. I used cvsup to update FreeBSD and yum update to update > Fedora. I didn't do any updating to FreeBSD4.11R, NetBSD2.0, and > OpenBSD3.6. > > I used the following utilities/tools in my testing: > DD > CP > IOSTAT (iostat -d 2) > Bonnie++ > TOP > SQL,PL, PSQL > Postgresql 8.0 > > DD Example Tests: > - #time dd bs=1024 if=/dev/zero of=tstfile count=1M > - #time dd bs=1024 if=/dev/zero of=tstfile count=2M > - #time dd bs=1024 if=/dev/zero of=tstfile count=3M > > Bonnie++ Example Tests: > #bonnie++ -u root -s 1024 -r 512 -n 5 > #bonnie++ -u root -s 2048 -r 512 -n 5 > #bonnie++ -u root -s 3072 -r 512 -n 5 > > CP Example Tests: > #time cp tstfile tstfile2 > > SQL, PL, PSQL Example Tests: > > CREATE TABLE test1 ( > thedate TIMESTAMP, > astring VARCHAR(200), > anumber INTEGER > ); > > CREATE FUNCTION build_data() RETURNS integer AS ' > DECLARE > i INTEGER DEFAULT 0; > curtime TIMESTAMP; > BEGIN > FOR i IN 1..1000000 LOOP > curtime := ''now''; > INSERT INTO test1 VALUES (curtime, ''test string'', i); > END LOOP; > RETURN 1; > END; > ' LANGUAGE 'plpgsql'; > > SELECT build_data(); > Then the following script is run under the time program to ascertain > how long it takes to run: > CREATE TABLE test2 ( > thedate TIMESTAMP, > astring VARCHAR(200), > anumber INTEGER > ); > CREATE TABLE test3 AS SELECT * FROM test1; > INSERT INTO test2 SELECT * FROM test1 WHERE ((anumber % 2) = 0); > DELETE FROM test3 WHERE ((anumber % 2) = 0); > DELETE FROM test3 WHERE ((anumber % 13) = 0); > CREATE TABLE test4 AS > SELECT test1.thedate AS t1date, > test2.thedate AS t2date, > test1.astring AS t1string, > test2.astring AS t2string, > test1.anumber AS t1number, > test2.anumber AS t2number > FROM test1 JOIN test2 ON test1.anumber=test2.anumber; > UPDATE test3 SET thedate='now' WHERE ((anumber % 5) = 0); > DROP TABLE test4; > CREATE TABLE test4 AS SELECT * FROM test1; > DELETE FROM test4 WHERE ((anumber % 27) = 0); > VACUUM ANALYZE; > VACUUM FULL; > DROP TABLE test4; > DROP TABLE test3; > DROP TABLE test2; > VACUUM FULL; > > Example FS TAB: > > minime# cat /etc/fstab > # Device Mountpoint FStype Options Dump Pass# > /dev/ad0s1b none swap sw 0 0 > /dev/ad0s1a / ufs rw 1 1 > /dev/ad0s1e /tmp ufs rw 2 2 > /dev/ad0s1f /usr ufs rw 2 2 > /dev/ad0s1d /var ufs rw 2 2 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > Verification Of Test: > I have been able to get consistent results in all of my testing. > However, I think the best verification would be to have as many people > as possible test the disk I/O performance on a range of hardware, > testing methods, and configurations. > > Summary Of Results: > The results of my testing have consistently demonstrated that > FreeBSD5.3+ has dramatically slower disk I/O performance than all of > the other operating systems that were tested. FreeBSD 4.11R was the > performance leader followed by Fedora C3 with XFS. All of the BSD > distributions, with the exception of 5.3+, were able to consistently > demonstrate a throughput of 56-58Mb/s sustained throughput, while 5.3+ > consistently demonstrated a throughput of 12-15Mb/s (58 -15 = 43 ?). > > Please let me know if you need any additional details. > > Thanks! > --Nick Pavlica > _______________________________________________ > 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 Thu Feb 3 23:48:26 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B20B16A4CE for ; Thu, 3 Feb 2005 23:48:26 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB36343D1D for ; Thu, 3 Feb 2005 23:48:20 +0000 (GMT) (envelope-from linicks@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so259318rnz for ; Thu, 03 Feb 2005 15:48:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Oc98zG/lKzaLXVzPlOZeAmxSYZPVFsdiTDhFrimW15aLGeBmsm1yZtaSB0U943YKqJgi8QwJKiavI8aqC/vXZgf7m9zt5Si4K4VSh7YmVqfHDsymJ+eC3duFw3SI6Z5CI2ViQuVn/Wd8LHxBCzWEjl9YXAG7m9J5VFke84Vz2dY= Received: by 10.38.19.34 with SMTP id 34mr32578rns; Thu, 03 Feb 2005 15:48:20 -0800 (PST) Received: by 10.38.8.20 with HTTP; Thu, 3 Feb 2005 15:48:20 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2005 16:48:20 -0700 From: Nick Pavlica To: Jeff Roberson In-Reply-To: <20050203175519.K18864@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2051_5270362.1107474500093" References: <20050203175519.K18864@mail.chesapeake.net> cc: freebsd-performance@freebsd.org Subject: Re: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nick Pavlica List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2005 23:48:26 -0000 ------=_Part_2051_5270362.1107474500093 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Jeff, One of the tests where I saw a large difference was in DD. I did a quick test on a server that was brought up to RELENG_5 via cvsup on 2/2/05. The Test: -bash-2.05b$ time dd bs=1024 if=/dev/zero of=tstfile count=1M 1048576+0 records in 1048576+0 records out 1073741824 bytes transferred in 74.402757 secs (14431479 bytes/sec) real 1m14.498s user 0m0.550s sys 0m8.838s The vmstat -1 info is attached. Thanks! --Nick On Thu, 3 Feb 2005 17:59:30 -0500 (EST), Jeff Roberson wrote: > > On Thu, 3 Feb 2005, Nick Pavlica wrote: > > > All, > > I would like to share the methods that I have been using in my disk > > I/O testing. The detailed results of these tests have been posted to > > the performance and questions mailing lists under the title " FreeBSD > > 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion". I > > originally started this testing as due diligence in an up coming > > project. As a result of this testing I discovered an elegant > > operating system that I enjoy working with. > > Nick, first, I'd like to thank you for your efforts so far. I think your > tests have been very informative. I'd like to see what we can do to get > to the bottom of the differences. Can you perform one test which varied > greatly between 5.x and 4.x and collect some data for us? To start with, > the output of vmstat 1 piped to a file would be informative. Do you have > any indication that 5.x is actually cpu bound in a case where 4.x is not? > I'm wondering if this is a latency issue or a cpu utilization issue. > > I intend to backport some code that lets me graph system activity into > RELENG_5. Are you setup to cvsup to this tag? Would it be convenient for > you to do so? > > Thanks, > Jeff > > > > > Intent Of This Testing: > > 1)To measure the disk I/O performance of various operating systems for > > use as a production database server. > > 2)Help improve the disk I/O performance of FreeBSD 5.x and greater by > > assisting the FreeBSD development team in identifying possible > > performance issues, and provide them with data to measure the success > > of various changes to the operating system. > > > > Operating Systems tested: > > Fedora Core 3 with EXT3, and XFS. I tested with and with out patches. > > SUSE Enterprise Server 9 with Riser FS. > > FreeBSD 4.11R > > FreeBSD 5.3R, RELENG_5_3, RELENG_5 > > NetBSD 2.0R > > OpenBSD 3.6R > > > > Test Hardware: > > Compaq DeskPro, PIII 800, 384Mb Ram, 10Gb IDE HD. > > Dell PE 2400, Dual PIII 550, 512Mb Ram, (2)10K,LVD SCSI, RAID 1, PERC > > 2SI controller with 64Mb ram. > > Dell PE SC400, 2.4Ghz P4, 256MB Ram, 40Gb IDE HD. > > Dell 4600, 2.8 Ghz P4 with HT, 512MB Ram, 80GB IDE HD. > > > > Installation Notes: > > It's my intention to test these Operating Systems using as many of > > the default installation options as possible with no special tuning. > > The only deviations in my previous testing were as follows: The #linux > > xfs option was used when installing Fedora so that I could use XFS, > > and a special test where I installed 5.3R with UFS instead of UFS2 (I > > didn't see any improvement when using UFS). I installed FreeBSD using > > the standard install option, and used the auto allocate features for > > partitioning and slicing. I installed Fedora with the stock server > > packages and created a 100Mb /boot, 512Mb swap, and allocated the > > remaining space to /. I tested FreeBSD5.3R and FC3R with and without > > updates. I used cvsup to update FreeBSD and yum update to update > > Fedora. I didn't do any updating to FreeBSD4.11R, NetBSD2.0, and > > OpenBSD3.6. > > > > I used the following utilities/tools in my testing: > > DD > > CP > > IOSTAT (iostat -d 2) > > Bonnie++ > > TOP > > SQL,PL, PSQL > > Postgresql 8.0 > > > > DD Example Tests: > > - #time dd bs=1024 if=/dev/zero of=tstfile count=1M > > - #time dd bs=1024 if=/dev/zero of=tstfile count=2M > > - #time dd bs=1024 if=/dev/zero of=tstfile count=3M > > > > Bonnie++ Example Tests: > > #bonnie++ -u root -s 1024 -r 512 -n 5 > > #bonnie++ -u root -s 2048 -r 512 -n 5 > > #bonnie++ -u root -s 3072 -r 512 -n 5 > > > > CP Example Tests: > > #time cp tstfile tstfile2 > > > > SQL, PL, PSQL Example Tests: > > > > CREATE TABLE test1 ( > > thedate TIMESTAMP, > > astring VARCHAR(200), > > anumber INTEGER > > ); > > > > CREATE FUNCTION build_data() RETURNS integer AS ' > > DECLARE > > i INTEGER DEFAULT 0; > > curtime TIMESTAMP; > > BEGIN > > FOR i IN 1..1000000 LOOP > > curtime := ''now''; > > INSERT INTO test1 VALUES (curtime, ''test string'', i); > > END LOOP; > > RETURN 1; > > END; > > ' LANGUAGE 'plpgsql'; > > > > SELECT build_data(); > > Then the following script is run under the time program to ascertain > > how long it takes to run: > > CREATE TABLE test2 ( > > thedate TIMESTAMP, > > astring VARCHAR(200), > > anumber INTEGER > > ); > > CREATE TABLE test3 AS SELECT * FROM test1; > > INSERT INTO test2 SELECT * FROM test1 WHERE ((anumber % 2) = 0); > > DELETE FROM test3 WHERE ((anumber % 2) = 0); > > DELETE FROM test3 WHERE ((anumber % 13) = 0); > > CREATE TABLE test4 AS > > SELECT test1.thedate AS t1date, > > test2.thedate AS t2date, > > test1.astring AS t1string, > > test2.astring AS t2string, > > test1.anumber AS t1number, > > test2.anumber AS t2number > > FROM test1 JOIN test2 ON test1.anumber=test2.anumber; > > UPDATE test3 SET thedate='now' WHERE ((anumber % 5) = 0); > > DROP TABLE test4; > > CREATE TABLE test4 AS SELECT * FROM test1; > > DELETE FROM test4 WHERE ((anumber % 27) = 0); > > VACUUM ANALYZE; > > VACUUM FULL; > > DROP TABLE test4; > > DROP TABLE test3; > > DROP TABLE test2; > > VACUUM FULL; > > > > Example FS TAB: > > > > minime# cat /etc/fstab > > # Device Mountpoint FStype Options Dump Pass# > > /dev/ad0s1b none swap sw 0 0 > > /dev/ad0s1a / ufs rw 1 1 > > /dev/ad0s1e /tmp ufs rw 2 2 > > /dev/ad0s1f /usr ufs rw 2 2 > > /dev/ad0s1d /var ufs rw 2 2 > > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > Verification Of Test: > > I have been able to get consistent results in all of my testing. > > However, I think the best verification would be to have as many people > > as possible test the disk I/O performance on a range of hardware, > > testing methods, and configurations. > > > > Summary Of Results: > > The results of my testing have consistently demonstrated that > > FreeBSD5.3+ has dramatically slower disk I/O performance than all of > > the other operating systems that were tested. FreeBSD 4.11R was the > > performance leader followed by Fedora C3 with XFS. All of the BSD > > distributions, with the exception of 5.3+, were able to consistently > > demonstrate a throughput of 56-58Mb/s sustained throughput, while 5.3+ > > consistently demonstrated a throughput of 12-15Mb/s (58 -15 = 43 ?). > > > > Please let me know if you need any additional details. > > > > Thanks! > > --Nick Pavlica > > _______________________________________________ > > 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" > > > ------=_Part_2051_5270362.1107474500093 Content-Type: application/octet-stream; name="vmstat_1_info" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vmstat_1_info" IHByb2NzICAgICAgbWVtb3J5ICAgICAgcGFnZSAgICAgICAgICAgICAgICAgICBkaXNrICAgZmF1 bHRzICAgICAgY3B1CiByIGIgdyAgICAgYXZtICAgIGZyZSAgZmx0ICByZSAgcGkgIHBvICBmciAg c3IgYWQwICAgaW4gICBzeSAgY3MgdXMgc3kgaWQKIDAgMCAwICAgNjY0ODAgIDg1NDQwICAgMTMg ICAwICAgMCAgIDAgIDEyICAgOCAgIDAgIDMzMiAgMTA1IDI1OCAgMCAgMCAxMDAKIDAgMCAwICAg NjY0ODAgIDg1NDM2ICAgIDMgICAwICAgMCAgIDAgICAzICAgMCAgIDAgIDMzNiAgMTE5IDI1NyAg MCAgMSA5OQogMCAwIDAgICA2NjQ4MCAgODU0MzYgICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAg MCAgMzMzICAxMTkgMjU1ICAwICAwIDEwMAogMCAxIDAgICA2NzU3NiAgODE1NDggICA4MSAgIDAg ICAwICAgMCAgNDcgICAwICAyMCAgMzc2IDc2NDkgNDM4ICAxICAyIDk3CiAwIDEgMCAgIDY3NTc2 ICA2NTUyNCAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgMTI1ICA1ODYgMzIxMzAgMTIyOCAgMCAx NCA4NgogMCAxIDAgICA2NzU3NiAgNDk0NjQgICAgMCAgIDAgICAwICAgMCAgIDIgICAwIDEyNCAg NTgwIDMxOTgwIDEyMTYgIDIgMTIgODYKIDAgMSAwICAgNjc1NzYgIDMzNDA0ICAgIDAgICAwICAg MCAgIDAgICAwICAgMCAxMjQgIDU4MyAzMjExOSAxMjMxICAyIDEzIDg0CiAxIDAgMCAgIDY3NTc2 ICAxNzg5MiAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgMTIzICA1NzkgMzA4OTIgMTIxNCAgMSAx NCA4NQogMCAxIDAgICA2NzU3NiAgIDkyNzYgICAgMCAgIDAgICAwICAgMCAgMjcgMjAwNiAxMjQg IDU4NiAzMjMxNyAxMjQzICAyIDE0IDg1CiAwIDEgMCAgIDY3NTc2ICAgODg4OCAgICAwICAgMCAg IDAgICAwIDM1NTggMzc2MiAxMjQgIDU4MyAzMDgzNSAxMjI2ICAwIDE2IDg0CiAwIDEgMCAgIDY3 NTc2ICAxNDcyMCAgICAwICAgMCAgIDAgICAwIDQxODYgNTY0NCAxMjMgIDU4MCAzMzM5NyAxMjM5 ICAyIDE2IDgyCiAwIDEgMCAgIDY3NTc2ICAxMzcwNCAgICAwICAgMCAgIDAgICAwIDQwMTcgMzc2 MyAxMjQgIDU4NCAzMjEwNiAxMjM1ICAwIDE2IDg0CiAwIDEgMCAgIDY3NTc2ICAxMzE2OCAgICAw ICAgMCAgIDAgICAwIDM5MDEgMzc2NyAxMjIgIDU3OSAzMTEwMyAxMjE4ICAxIDE2IDg0CiAwIDEg MCAgIDY3NTc2ICAxMjE1NiAgICAwICAgMCAgIDAgICAwIDQwMTggMzc2NSAxMjQgIDU4MiAzMjEw OCAxMjM0ICAwIDE2IDg0CiAwIDEgMCAgIDY3NTc2ICAxMTYxMiAgICAwICAgMCAgIDAgICAwIDM5 MDEgMzk2NCAxMjIgIDU3OCAzMTEwMiAxMjE0ICAyIDE2IDgzCiAwIDEgMCAgIDY3NTc2ICAxMDYw MCAgICAwICAgMCAgIDAgICAwIDQwMTcgMzc5NCAxMjQgIDU4MyAzMjExOCAxMjM4ICAxIDE1IDg0 CiAxIDAgMCAgIDY3NTc2ICAgOTkyOCAgICAwICAgMCAgIDAgICAwIDM5MzMgMzc2NSAxMjEgIDU3 NSAzMTMyMSAxMjA0ICAyIDE0IDg0CiAwIDEgMCAgIDY3NTc2ICAgOTI4NCAgICAwICAgMCAgIDAg ICAwIDM5MjQgMzc2MyAxMjQgIDU4MCAzMTM3NyAxMjI2ICAwIDE5IDgxCiBwcm9jcyAgICAgIG1l bW9yeSAgICAgIHBhZ2UgICAgICAgICAgICAgICAgICAgZGlzayAgIGZhdWx0cyAgICAgIGNwdQog ciBiIHcgICAgIGF2bSAgICBmcmUgIGZsdCAgcmUgIHBpICBwbyAgZnIgIHNyIGFkMCAgIGluICAg c3kgIGNzIHVzIHN5IGlkCiAwIDQgMCAgIDY3OTYwICAxNTk1MiAgIDU0ICAgMCAgIDAgICAyIDM5 OTcgNTY1MiAxMjEgIDU3NyAzMTM5NiAxMjIzICAyIDEzIDg1CiAwIDQgMCAgIDY3OTYwICAxNDk0 NCAgICAwICAgMCAgIDAgICAwIDQwMTcgMzc2OSAxMjQgIDU4MCAzMjExMyAxMjI4ICAyIDE1IDg0 CiAwIDMgMCAgIDY3OTYwICAxNTAwOCAgICAzICAgMCAgIDAgICAwIDM3NTIgMzc2OCAxMjQgIDU3 NyAyOTgyMCAxMjA3ICAxIDE0IDg1CiAwIDIgMCAgIDY3OTY0ICAxNTg3MiAgICA1ICAgMCAgIDAg ICAwIDM4MzcgMzUwNCAxMDggIDg2MyAyODI3NCAxNTE3ICAwIDEwIDkwCiAwIDIgMCAgIDY3OTY0 ICAxMTY4MCAgICA1ICAgMCAgIDAgICAwIDI5MzIgMTg4NCAgOTQgIDUyMSAyMzQyOCA5ODggIDAg MTIgODgKIDAgMiAwICAgNjc5NjQgIDExMzQ0ICAgIDAgICAwICAgMCAgIDAgMzg1MCAzNzY2IDEx OCAgNTY5IDMwODMzIDExODYgIDAgMTUgODUKIDAgMiAwICAgNjc5NjQgIDExMzQ0ICAgIDAgICAw ICAgMCAgIDAgMzc2MyAzNzYzIDExOSAgNTcyIDMwMDc1IDExODcgIDEgMTUgODQKIDEgMiAwICAg Njc5NjggIDE2MzM2ICAgIDUgICAwICAgMCAgMTcgMzU5MiAxNTgzOSAxMjkgIDU3OSAyODI0NCAx MjIwICAwIDE4IDgyCiAwIDIgMCAgIDY3OTY4ICAxNTU2OCAgIDMyICAgMCAgIDAgICAwIDM5MzUg NjY1MCAxMjIgIDU3MyAzMTY2NiAxMjA2ICAxIDE1IDg0CiAwIDMgMCAgIDY4MjY4ICAxNTg5NiAg IDk1ICAgMSAgIDAgICAwIDM3MDggMzc2NiAxMTYgIDU2NCAyOTExNCAxMTYzICAwIDE1IDg1CiAw IDMgMCAgIDY4MjY4ICAxNDg5NiAgICAwICAgMCAgIDAgICAwIDQwMTUgMzc2NSAxMjMgIDU4MiAz MjEyNiAxMjMxICAxIDE2IDgzCiAwIDQgMCAgIDY4MzU2ICAxNTA5NiAgICAyICAgMCAgIDIgICAw IDM3MTQgMzc3NCAxMTkgIDU2OCAyOTU1MCAxMTc4ICAyIDE2IDgzCiAwIDQgMCAgIDY4MzU2ICAx NDg1NiAgICAwICAgMCAgIDAgICAwIDM4MjcgMzc2NyAxMjEgIDU3OCAzMDU4MyAxMjA4ICAyIDEy IDg2CiAwIDEyIDAgICA2ODM2MCAgMTAyNTYgICAgMSAgIDAgICAwICAgMCAzNjIxIDM3NjggMTIx ICA1NjcgMjg3OTcgMTE1NSAgMSAxNSA4NQogMCAxMiAwICAgNjgzNjAgIDExMTgwICAgIDAgICAw ICAgMSAgIDAgMTA0ODQgOTQxNiAxMTUgMTU4NyA4MzU4MyAzMjg0ICAxIDEzIDg2CiAwIDEyIDAg ICA2ODM2MCAgMTA4MDQgICAgMCAgIDAgICAwICAgMCAzODU3IDM3NjQgMTE3ICA1NzAgMzA4Mzkg MTE4MiAgMiAxNSA4MwogMCAxMiAwICAgNjgzOTIgIDExNjU2ICAgIDEgICAwICAgMSAgIDAgMzU0 OSAzODQ5IDExMyAgNTU3IDI4MjY4IDExMzMgIDEgMTMgODYKIDAgNCAwICAgNjkyODAgIDEyMjA0 ICAgIDIgICAwICAgMCAgIDAgMzIyMCAzNzY5IDEwOSAgNTQzIDI1NzMxIDEwNjggIDAgMTIgODgK IHByb2NzICAgICAgbWVtb3J5ICAgICAgcGFnZSAgICAgICAgICAgICAgICAgICBkaXNrICAgZmF1 bHRzICAgICAgY3B1CiByIGIgdyAgICAgYXZtICAgIGZyZSAgZmx0ICByZSAgcGkgIHBvICBmciAg c3IgYWQwICAgaW4gICBzeSAgY3MgdXMgc3kgaWQKIDAgNCAwICAgNjkyODAgIDEzMTEyICAgIDAg ICAwICAgMSAgIDAgNTg2MCA1NjQ0ICA5OSAgOTY4IDQ2NzE0IDE4NzUgIDAgMTQgODYKIDAgNCAw ICAgNjkyODAgIDEzMzU2ICAgIDAgICAwICAgMCAgIDQgMzY5OCAzNzY1IDExNyAgNTY5IDI5NTU5 IDExNzYgIDAgMTYgODQKIDAgNCAwICAgNjkyODggIDEzNTMyICAgMjAgICAwICAgMSAgIDAgMzcy NSAzNzY2IDEyMCAgNTY5IDI5NTU3IDExNzUgIDAgMTQgODYKIDAgNCAwICAgNjkyODggIDEyNTEy ICAgIDAgICAwICAgMCAgIDAgNDAxNyAzNzY1IDEyMCAgNTc3IDMyMTE5IDEyMTggIDIgMTQgODUK IDAgNCAwICAgNjkyNjQgIDEzMjA4ICAgMjcgICAwICAgMiAgIDAgMzYwNSAzNzYzIDExNiAgNTYy IDI4NTMzIDExNTEgIDEgMTMgODYKIDAgNCAwICAgNjkyNjQgIDEyODI4ICAgMTQgICAwICAgMCAg IDEgMzg2NiAzNzY2IDExOSAgNTcyIDMwODYwIDEyMDAgIDAgMTYgODQKIDEgMyAwICAgNjkyNzYg IDEzNDE2ICAgMjAgICAwICAgMSAgIDAgMzYyNCAzNzY3IDExNSAgNTYwIDI4NzQ5IDExNDQgIDAg MTcgODMKIDAgNCAwICAgNjkyNzYgIDEzMDI4ICAgIDAgICAwICAgMCAgIDAgMzg2MiAzNzY1IDEx OCAgNTczIDMwODgxIDExOTUgIDEgMTggODIKIDAgNCAwICAgNjkyNzYgICA3OTQ0ICAgIDMgICAw ICAgMSAgIDQgMzg3MiAyNjA1IDEyMiAgNTczIDMwODQzIDExOTcgIDEgMTcgODIKIDAgMyAwICAg Njk0ODggIDE2MTAwICAgNjAgIDEwICAgMyAgNDkgMzYzMCAxMDk3NSAxNjkgIDYxNSAyODU2MCAx NDIyICAxIDE0IDg1CiAwIDMgMCAgIDY5NDg4ICAxNTU2OCAgIDUwICAgMCAgIDAgICAwIDM5MTEg Mzc2NSAxMTkgIDU2OSAzMDU3OCAxMTg2ICAxIDE4IDgyCiAxIDMgMCAgIDcwMzYwICAxMzYxNiAg IDI3ICAgMCAgIDEgICAwIDI0MzIgMTQ4MyAgOTMgIDUwNiAxOTM5OSA5MDggIDEgMTAgODkKIDAg MyAwICAgNzAzNzYgIDEwNzEyICAgMTQgICAwICAgMCAgIDAgODI2NCA3NTM4ICA4MSAxNTY4IDY1 OTA4IDI4MDggIDAgIDkgOTEKIDEgMiAwICAgNzAzNzYgIDEyMzIwICAgMTAgICAwICAgMCAgIDAg OTAxNiA5NDE2ICA4NyAxNjI1IDcxNzQ4IDI5ODkgIDAgMTAgODkKIDAgMyAwICAgNzAzNzYgIDEz NjA4ICAgIDAgICAwICAgMCAgIDAgMzQ0MyAzNzY2IDEwOCAgNTUwIDI3NTcxIDExMDMgIDAgMTQg ODYKIDAgMSAxICAgNjc1NzYgIDE0ODcyICAgIDMgICAwICAgMSAgIDAgMzU4MSAzNzY0IDExMCAg NTU1IDI4NTQyIDExMjggIDEgMTQgODUKIDEgMCAxICAgNjc1NzYgIDE1MDYwICAgIDAgICAwICAg MCAgIDAgMzcxNiAzNzYzIDExOCAgNTczIDI5NzE3IDExODMgIDAgMTMgODcKIDAgMSAxICAgNjc1 NzYgIDE1MjMyICAgIDAgICAwICAgMSAgIDAgMzcyMCAzNzcwIDExNSAgNTYxIDI5NjQ0IDExNTUg IDAgMTQgODYKIHByb2NzICAgICAgbWVtb3J5ICAgICAgcGFnZSAgICAgICAgICAgICAgICAgICBk aXNrICAgZmF1bHRzICAgICAgY3B1CiByIGIgdyAgICAgYXZtICAgIGZyZSAgZmx0ICByZSAgcGkg IHBvICBmciAgc3IgYWQwICAgaW4gICBzeSAgY3MgdXMgc3kgaWQKIDAgMSAxICAgNjc1NzYgIDE0 ODU2ICAgIDAgICAwICAgMCAgIDAgMzg1NyAzNzYzIDExNyAgNTcyIDMwODM5IDExODkgIDIgMTMg ODUKIDAgMSAwICAgNjc1NzYgIDE0OTM2ICAgMTMgICAwICAgMSAgIDAgMzc0OSAzNzY3IDExOCAg NTY2IDI5ODA3IDExNzUgIDAgMTQgODYKIDAgMSAxICAgNjc1NzYgIDE0NTY0ICAgIDAgICAwICAg MSAgIDAgMzg1OSAzNzY2IDEyMiAgNTc5IDMwODU4IDEyMjEgIDAgMTYgODQKIDAgMSAxICAgNjc1 NzYgIDE0MDIwICAgIDAgICAwICAgMSAgIDAgMzkwMCAzNzY4IDEyMiAgNTczIDMxMDgyIDEyMDMg IDEgMTYgODMKIDEgMCAxICAgNjc1NzYgIDE0MTIwICAgIDAgICAwICAgMCAgIDAgMzczOSAzNzY0 IDExOCAgNTcxIDI5ODk1IDExNzggIDMgMTIgODUKIDAgMSAxICAgNjc1NzYgIDEzODAwICAgIDAg ICAwICAgMCAgIDAgMzg0NSAzNzY1IDExNyAgNTY3IDMwNzQ2IDExNzkgIDAgMTUgODUKIDAgMSAw ICAgNjc1NzYgIDE0MDIwICAgMTIgICAwICAgMSAgIDAgMzcxNyAzNzY3IDExOCAgNTY5IDI5NTYz IDExNzggIDIgMTIgODUKIDEgMCAwICAgNjc1NzYgIDE0MDU2ICAgIDAgICAwICAgMCAgIDAgMzc1 NSAzNzY0IDExNyAgNTY3IDMwMDIyIDExNzEgIDEgMTYgODMKIDAgMSAwICAgNjc1NzYgIDEzNzUy ICAgIDAgICAwICAgMCAgIDAgMzg0MSAzNzY1IDExNyAgNTcwIDMwNjM0IDExODggIDEgMTggODEK IDAgMSAwICAgNjc1NzYgIDE0MDI0ICAgIDAgICAwICAgMCAgIDAgMzY5NSAzNzYzIDExNyAgNTY5 IDI5NTQ2IDExNzAgIDEgMTQgODUKIDAgMSAwICAgNjc1NzYgIDE0NzQ0ICAgIDAgICAwICAgMCAg IDQgMzU3OSAzNzY1IDExMiAgNTU0IDI4NTM1IDExMjMgIDIgMTYgODIKIDAgMSAwICAgNjc1NzYg ICA5NDE2ICAgIDAgICAwICAgMCAgIDAgMzIxMyAxODgxIDEwMCAgNTM0IDI1NzA2IDEwMzcgIDAg MTIgODgKIDAgMSAwICAgNjc1NzYgIDExNjEyICAgIDAgICAwICAgMCAgIDAgMzIxNCAzNzYzIDEw MSAgNTM3IDI1NzM4IDEwNTIgIDIgMTEgODgKIDAgMSAxICAgNjc1NzYgIDEzNjEyICAgMTQgICAw ICAgNCAgIDAgMzI3MiAzNzY2IDEwMSAgNTMyIDI1OTY2IDEwNDkgIDEgMTIgODcKIDAgMSAxICAg Njc1NzYgICA5MTY0ICAgIDAgICAwICAgMCAgIDAgMzA4NSAxODgxIDEwMCAgNTM2IDI0Mjg5IDEw MzEgIDEgMTEgODgKIDAgMCAwICAgNjY0ODAgICA4OTUyICAxNDAgICAwICAgOCAgIDAgMTk5OCAx ODgyICA4NCAgNDgxIDE1ODEyIDgxOSAgMSAgNyA5MgogMCAwIDAgICA2NjQ4MCAgIDg5NTIgICAg NyAgIDAgICAwICAgMCAgIDIgICAwICAgMCAgMzMzICAxMjYgMjU2ICAwICAxIDk5CiAwIDAgMCAg IDY2NDgwICAgODk1MiAgICAyICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAzMzEgIDEyMiAyNTEg IDAgIDEgOTkKIHByb2NzICAgICAgbWVtb3J5ICAgICAgcGFnZSAgICAgICAgICAgICAgICAgICBk aXNrICAgZmF1bHRzICAgICAgY3B1CiByIGIgdyAgICAgYXZtICAgIGZyZSAgZmx0ICByZSAgcGkg IHBvICBmciAgc3IgYWQwICAgaW4gICBzeSAgY3MgdXMgc3kgaWQKIDAgMCAwICAgNjY0ODAgIDE2 NTI4ICAgIDAgICAwICAgMCAgIDAgIDc3IDE4OTYgIDE1ICAzNDkgIDExOSAzMDEgIDAgIDIgOTgK ------=_Part_2051_5270362.1107474500093-- From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 00:55:54 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EF4E16A4CF for ; Fri, 4 Feb 2005 00:55:54 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC01C43D48 for ; Fri, 4 Feb 2005 00:55:53 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 0210646B1A for ; Thu, 3 Feb 2005 19:55:53 -0500 (EST) Date: Fri, 4 Feb 2005 00:55:04 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: performance@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 00:55:54 -0000 I pulled down the postmark benchmark, and gave it a spin on a dual PIII 800mhz box w/256mb of RAM from the netperf cluster. I ran all tests against a UFS1 partition shared by the 4.x and 6.x install on the box, so that the file system would be on the same spot on the disk. I used the following postmark parameters: size 300 100000 transactions 10000 I have the numbers below, but here are the conclusions: on this hardware, using a single ATA disk, there was no real measurable performance difference between UP/SMP, and 4.x/6.x -- 6.x came out slightly ahead on t/s, but not hugely so. I take this to mean that the hardware was basically I/O bound on file system meta-data operations. One observation which is worthy of caution. When re-running the same measurement several times on the same configuration, I saw that Postmark is quite sensitive to short runs, in that it appears to use integer division by the measured number of seconds (in integer representation) of a test. This means that the transaction rates, typically associated with long runs of transactions, tend to reasonably reflect mean rates, but that the "alone" measurements, associated with the setup and tear-down of the benchmark, are very sensitive to minor timing differences. As such, I would recommend against using these figures in evaluating the performance of a configuration. I have included only full transaction run measurements below. Just as an example: I saw the "create alone" rate bounce between 166 and 250 per/sec depending on whether the creation of 500 objects took two or three seconds. Another thing to keep in mind when comparing this to some of the other numbers that have been posted: I compared specifically using UFS1 and soft updates. I didn't frob settings such as async. One final note -- because the system is I/O-bound, the effective CPU consumption appears to have little impact on the result. The 6.x performance appears marginally better here, but there is more CPU usage. While I didn't attempt to measure precise CPU usage as yet, my impression is that the 6.x system time was at least 1/3 again the CPU consumption on 4.x, so if this benchmark were running using this CPU/etc, but the I/O throughput were higher, presumably the increase CPU consumption would play a larger role. I'll attempt to measure a little better the CPU use over the weekend. On the other hand, this box is hardly a speed demon... Numbers below. Robert N M Watson UP=Uniprocessor SMP=Multiprocessor MV=MPSAFE VFS tran sec Length of transaction run in seconds tran/s Number of transactions/sec over total run creat/s Number of create transactions/sec ("mixed") read/s Number of read transactions/sec ("mixed") app/s Number of append transactions/sec ("mixed") del/s Number of delete transactions/sec ("mixed") rd/s Number of read transaction/sec ("mixed") wr/s Number of write transactions/sec ("mixed") tran sec tran/s creat/s read/s app/s del/s rd/s wr/s 4.x UP 76 131 66 65 66 65 4.00 4.45 75 133 67 66 67 66 4.00 4.45 4.x SMP 74 135 68 66 68 67 4.11 4.56 76 131 66 65 66 65 3.95 4.39 6.x UP 73 136 68 67 69 68 4.17 4.62 71 140 70 69 70 69 4.22 4.69 6.x UP MV 71 140 70 69 70 69 4.22 4.69 71 140 70 69 70 69 4.22 4.69 6.x SMP 72 138 69 68 70 68 4.17 4.62 72 138 69 68 70 68 4.22 4.69 6.x SMP MV 72 138 69 68 70 68 4.17 4.62 74 135 68 66 68 67 4.11 4.56 From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 01:17:42 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B00C16A4CE for ; Fri, 4 Feb 2005 01:17:42 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C626C43D48 for ; Fri, 4 Feb 2005 01:17:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 4579546B88 for ; Thu, 3 Feb 2005 20:17:41 -0500 (EST) Date: Fri, 4 Feb 2005 01:16:52 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: performance@FreeBSD.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 01:17:42 -0000 On Fri, 4 Feb 2005, Robert Watson wrote: > tran sec tran/s creat/s read/s app/s del/s rd/s wr/s > 4.x UP 76 131 66 65 66 65 4.00 4.45 > 75 133 67 66 67 66 4.00 4.45 In case it's not already clear here: this box has UDMA33 ATA drives. For raw transfer rates, I get about 19-20MB/sec to various points on the disk. I'll try to run the same set of tests on a dual-Xeon box with UDMA100 drives. Robert N M Watson From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 01:41:45 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D550716A52B for ; Fri, 4 Feb 2005 01:41:42 +0000 (GMT) Received: from web41212.mail.yahoo.com (web41212.mail.yahoo.com [66.218.93.45]) by mx1.FreeBSD.org (Postfix) with SMTP id 8FAD943D3F for ; Fri, 4 Feb 2005 01:41:42 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 34504 invoked by uid 60001); 4 Feb 2005 01:41:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=kzEDIQwFiDdQ0O7Nu4rnzt5vSYiv2jiEnDbWPY3+jhFw2h4/uCSFYMscWa9YZVHhoWQdJaZBZP0fUm0Z54bwx5ZiFCi1Zm9eZpNLAqHz0A5LsrwinHVrqDowV5uL3s693WMyo9BRf4tqugqZg3/771+Jp3X/8G4DuNFR3+9bVVE= ; Message-ID: <20050204014142.34502.qmail@web41212.mail.yahoo.com> Received: from [213.54.136.142] by web41212.mail.yahoo.com via HTTP; Thu, 03 Feb 2005 17:41:42 PST Date: Thu, 3 Feb 2005 17:41:42 -0800 (PST) From: Arne "Wörner" To: Robert Watson , performance@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 01:41:45 -0000 Ooops... I found a parameter in my comparison between time sh -c "dd if=/dev/zero of=a bs=64k count=1000; fsync a" on R5.1 and R5.3, that was not the same: hw.ata.wc :-)) But I still see 7.9e6bytes/sec on R5.1 and 5.0e6bytes/sec on R5.3, which is clearly differnt (R5.1 is 58% faster in this test than R5.3). Sorry for my bad test, I published here earlier (but the tendence was the same)... -Arne __________________________________ Do you Yahoo!? All your favorites on one personal page – Try My Yahoo! http://my.yahoo.com From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 02:52:56 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F48016A4CE for ; Fri, 4 Feb 2005 02:52:56 +0000 (GMT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 5CF5E43D2F for ; Fri, 4 Feb 2005 02:52:55 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 4 Feb 2005 02:52:54 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej); by 172.16.0.1 with HTTP; Thu, 3 Feb 2005 21:52:46 -0500 (EST) Message-ID: <1170.172.16.0.199.1107485566.squirrel@172.16.0.199> In-Reply-To: References: <20050203175519.K18864@mail.chesapeake.net> Date: Thu, 3 Feb 2005 21:52:46 -0500 (EST) From: "Mike Jakubik" To: "Nick Pavlica" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: Jeff Roberson cc: freebsd-performance@freebsd.org Subject: Re: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 02:52:56 -0000 Nick Pavlica said: > Jeff, > One of the tests where I saw a large difference was in DD. I did a > quick test on a server that was brought up to RELENG_5 via cvsup on > 2/2/05. > > The Test: > -bash-2.05b$ time dd bs=1024 if=/dev/zero of=tstfile count=1M > 1048576+0 records in > 1048576+0 records out > 1073741824 bytes transferred in 74.402757 secs (14431479 bytes/sec) > > real 1m14.498s > user 0m0.550s > sys 0m8.838s FYI. # time dd bs=1024 if=/dev/zero of=tstfile count=1M 1048576+0 records in 1048576+0 records out 1073741824 bytes transferred in 22.150709 secs (48474377 bytes/sec) real 0m22.173s user 0m0.501s sys 0m13.832s This is on an old ATA disk. FreeBSD 6.0-CURRENT #0: Wed Jan 19 21:11:16 EST 2005. CPU: AMD Athlon(tm) Processor (1410.21-MHz 686-class CPU) real memory = 536788992 (511 MB) acpi0: on motherboard ad0: 78167MB [158816/16/63] at ata0-master UDMA100 From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 04:04:01 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C12016A4CE for ; Fri, 4 Feb 2005 04:04:01 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CBF243D48 for ; Fri, 4 Feb 2005 04:04:00 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j1443wc5061250; Thu, 3 Feb 2005 23:03:58 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j1443vUN061237; Thu, 3 Feb 2005 23:03:57 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Thu, 3 Feb 2005 23:03:55 -0500 (EST) From: Jeff Roberson To: Nick Pavlica In-Reply-To: Message-ID: <20050203230343.M18864@mail.chesapeake.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-performance@freebsd.org Subject: Re: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 04:04:01 -0000 On Thu, 3 Feb 2005, Nick Pavlica wrote: > Jeff, > One of the tests where I saw a large difference was in DD. I did a > quick test on a server that was brought up to RELENG_5 via cvsup on > 2/2/05. Can you give me the same from RELENG_4? > > The Test: > -bash-2.05b$ time dd bs=1024 if=/dev/zero of=tstfile count=1M > 1048576+0 records in > 1048576+0 records out > 1073741824 bytes transferred in 74.402757 secs (14431479 bytes/sec) > > real 1m14.498s > user 0m0.550s > sys 0m8.838s > > > The vmstat -1 info is attached. > > > Thanks! > --Nick > > > > On Thu, 3 Feb 2005 17:59:30 -0500 (EST), Jeff Roberson > wrote: > > > > On Thu, 3 Feb 2005, Nick Pavlica wrote: > > > > > All, > > > I would like to share the methods that I have been using in my disk > > > I/O testing. The detailed results of these tests have been posted to > > > the performance and questions mailing lists under the title " FreeBSD > > > 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion". I > > > originally started this testing as due diligence in an up coming > > > project. As a result of this testing I discovered an elegant > > > operating system that I enjoy working with. > > > > Nick, first, I'd like to thank you for your efforts so far. I think your > > tests have been very informative. I'd like to see what we can do to get > > to the bottom of the differences. Can you perform one test which varied > > greatly between 5.x and 4.x and collect some data for us? To start with, > > the output of vmstat 1 piped to a file would be informative. Do you have > > any indication that 5.x is actually cpu bound in a case where 4.x is not? > > I'm wondering if this is a latency issue or a cpu utilization issue. > > > > I intend to backport some code that lets me graph system activity into > > RELENG_5. Are you setup to cvsup to this tag? Would it be convenient for > > you to do so? > > > > Thanks, > > Jeff > > > > > > > > Intent Of This Testing: > > > 1)To measure the disk I/O performance of various operating systems for > > > use as a production database server. > > > 2)Help improve the disk I/O performance of FreeBSD 5.x and greater by > > > assisting the FreeBSD development team in identifying possible > > > performance issues, and provide them with data to measure the success > > > of various changes to the operating system. > > > > > > Operating Systems tested: > > > Fedora Core 3 with EXT3, and XFS. I tested with and with out patches. > > > SUSE Enterprise Server 9 with Riser FS. > > > FreeBSD 4.11R > > > FreeBSD 5.3R, RELENG_5_3, RELENG_5 > > > NetBSD 2.0R > > > OpenBSD 3.6R > > > > > > Test Hardware: > > > Compaq DeskPro, PIII 800, 384Mb Ram, 10Gb IDE HD. > > > Dell PE 2400, Dual PIII 550, 512Mb Ram, (2)10K,LVD SCSI, RAID 1, PERC > > > 2SI controller with 64Mb ram. > > > Dell PE SC400, 2.4Ghz P4, 256MB Ram, 40Gb IDE HD. > > > Dell 4600, 2.8 Ghz P4 with HT, 512MB Ram, 80GB IDE HD. > > > > > > Installation Notes: > > > It's my intention to test these Operating Systems using as many of > > > the default installation options as possible with no special tuning. > > > The only deviations in my previous testing were as follows: The #linux > > > xfs option was used when installing Fedora so that I could use XFS, > > > and a special test where I installed 5.3R with UFS instead of UFS2 (I > > > didn't see any improvement when using UFS). I installed FreeBSD using > > > the standard install option, and used the auto allocate features for > > > partitioning and slicing. I installed Fedora with the stock server > > > packages and created a 100Mb /boot, 512Mb swap, and allocated the > > > remaining space to /. I tested FreeBSD5.3R and FC3R with and without > > > updates. I used cvsup to update FreeBSD and yum update to update > > > Fedora. I didn't do any updating to FreeBSD4.11R, NetBSD2.0, and > > > OpenBSD3.6. > > > > > > I used the following utilities/tools in my testing: > > > DD > > > CP > > > IOSTAT (iostat -d 2) > > > Bonnie++ > > > TOP > > > SQL,PL, PSQL > > > Postgresql 8.0 > > > > > > DD Example Tests: > > > - #time dd bs=1024 if=/dev/zero of=tstfile count=1M > > > - #time dd bs=1024 if=/dev/zero of=tstfile count=2M > > > - #time dd bs=1024 if=/dev/zero of=tstfile count=3M > > > > > > Bonnie++ Example Tests: > > > #bonnie++ -u root -s 1024 -r 512 -n 5 > > > #bonnie++ -u root -s 2048 -r 512 -n 5 > > > #bonnie++ -u root -s 3072 -r 512 -n 5 > > > > > > CP Example Tests: > > > #time cp tstfile tstfile2 > > > > > > SQL, PL, PSQL Example Tests: > > > > > > CREATE TABLE test1 ( > > > thedate TIMESTAMP, > > > astring VARCHAR(200), > > > anumber INTEGER > > > ); > > > > > > CREATE FUNCTION build_data() RETURNS integer AS ' > > > DECLARE > > > i INTEGER DEFAULT 0; > > > curtime TIMESTAMP; > > > BEGIN > > > FOR i IN 1..1000000 LOOP > > > curtime := ''now''; > > > INSERT INTO test1 VALUES (curtime, ''test string'', i); > > > END LOOP; > > > RETURN 1; > > > END; > > > ' LANGUAGE 'plpgsql'; > > > > > > SELECT build_data(); > > > Then the following script is run under the time program to ascertain > > > how long it takes to run: > > > CREATE TABLE test2 ( > > > thedate TIMESTAMP, > > > astring VARCHAR(200), > > > anumber INTEGER > > > ); > > > CREATE TABLE test3 AS SELECT * FROM test1; > > > INSERT INTO test2 SELECT * FROM test1 WHERE ((anumber % 2) = 0); > > > DELETE FROM test3 WHERE ((anumber % 2) = 0); > > > DELETE FROM test3 WHERE ((anumber % 13) = 0); > > > CREATE TABLE test4 AS > > > SELECT test1.thedate AS t1date, > > > test2.thedate AS t2date, > > > test1.astring AS t1string, > > > test2.astring AS t2string, > > > test1.anumber AS t1number, > > > test2.anumber AS t2number > > > FROM test1 JOIN test2 ON test1.anumber=test2.anumber; > > > UPDATE test3 SET thedate='now' WHERE ((anumber % 5) = 0); > > > DROP TABLE test4; > > > CREATE TABLE test4 AS SELECT * FROM test1; > > > DELETE FROM test4 WHERE ((anumber % 27) = 0); > > > VACUUM ANALYZE; > > > VACUUM FULL; > > > DROP TABLE test4; > > > DROP TABLE test3; > > > DROP TABLE test2; > > > VACUUM FULL; > > > > > > Example FS TAB: > > > > > > minime# cat /etc/fstab > > > # Device Mountpoint FStype Options Dump Pass# > > > /dev/ad0s1b none swap sw 0 0 > > > /dev/ad0s1a / ufs rw 1 1 > > > /dev/ad0s1e /tmp ufs rw 2 2 > > > /dev/ad0s1f /usr ufs rw 2 2 > > > /dev/ad0s1d /var ufs rw 2 2 > > > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > > > Verification Of Test: > > > I have been able to get consistent results in all of my testing. > > > However, I think the best verification would be to have as many people > > > as possible test the disk I/O performance on a range of hardware, > > > testing methods, and configurations. > > > > > > Summary Of Results: > > > The results of my testing have consistently demonstrated that > > > FreeBSD5.3+ has dramatically slower disk I/O performance than all of > > > the other operating systems that were tested. FreeBSD 4.11R was the > > > performance leader followed by Fedora C3 with XFS. All of the BSD > > > distributions, with the exception of 5.3+, were able to consistently > > > demonstrate a throughput of 56-58Mb/s sustained throughput, while 5.3+ > > > consistently demonstrated a throughput of 12-15Mb/s (58 -15 = 43 ?). > > > > > > Please let me know if you need any additional details. > > > > > > Thanks! > > > --Nick Pavlica > > > _______________________________________________ > > > 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 Fri Feb 4 09:56:33 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 157F816A4CF for ; Fri, 4 Feb 2005 09:56:33 +0000 (GMT) Received: from dekart.f.bg.ac.yu (dekart.f.bg.ac.yu [147.91.75.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 253BE43D45 for ; Fri, 4 Feb 2005 09:56:31 +0000 (GMT) (envelope-from random@beotel.yu) Received: from Dial-79.f.bg.ac.yu (Dial-79.f.bg.ac.yu [147.91.75.79]) by dekart.f.bg.ac.yu (8.11.6/8.11.6) with ESMTP id j149rLH01469 for ; Fri, 4 Feb 2005 10:53:22 +0100 From: Vladimir Vrzic To: freebsd-performance@freebsd.org Content-Type: text/plain Date: Fri, 04 Feb 2005 10:56:21 +0100 Message-Id: <1107510981.23035.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.1(snapshot 20020919) (dekart) Subject: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 09:56:33 -0000 On a FreeBSD 5.3 web server with a very high load, I recently switched from Apache 1.3 and PHP 4.3 to using 2.0 with the prefork MPM and PHP 5. I noticed a drop in perfomance. What is currently the best (in terms of performance) choice for Apache w/ PHP on FreeBSD? Which MPM should I use? Does worker MPM use KSE on FreeBSD 5 and does it perform better than prefork? What about perchild and threadpool? Or maybe I should go back to Apache 1.3? Are there any sysctl or kernel tunings that I should use? -- Vladimir Vrzic From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 10:32:12 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 891F016A4CE for ; Fri, 4 Feb 2005 10:32:12 +0000 (GMT) Received: from web26806.mail.ukl.yahoo.com (web26806.mail.ukl.yahoo.com [217.146.176.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 88BEE43D31 for ; Fri, 4 Feb 2005 10:32:11 +0000 (GMT) (envelope-from cguttesen@yahoo.dk) Received: (qmail 69848 invoked by uid 60001); 4 Feb 2005 10:32:10 -0000 Message-ID: <20050204103210.69846.qmail@web26806.mail.ukl.yahoo.com> Received: from [194.248.174.58] by web26806.mail.ukl.yahoo.com via HTTP; Fri, 04 Feb 2005 11:32:10 CET Date: Fri, 4 Feb 2005 11:32:10 +0100 (CET) From: Claus Guttesen To: Vladimir Vrzic , freebsd-performance@freebsd.org In-Reply-To: <1107510981.23035.17.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 10:32:12 -0000 > On a FreeBSD 5.3 web server with a very high load, I > recently switched > from Apache 1.3 and PHP 4.3 to using 2.0 with the > prefork MPM and PHP 5. > I noticed a drop in perfomance. What is currently > the best (in terms of > performance) choice for Apache w/ PHP on FreeBSD? > Which MPM should I > use? Does worker MPM use KSE on FreeBSD 5 and does > it perform better > than prefork? What about perchild and threadpool? Or > maybe I should go > back to Apache 1.3? Are there any sysctl or kernel > tunings that I should > use? It is not recommend to use apache 2 with PHP. That's at least what the folks at php says. We use 1.3 and are satisfied with the performance. Have you tried to set the following in /usr/local/etc/apache/httpd.conf? KeepAlive Off MaxClients (size of one process) / (avail. RAM) regards Claus From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 11:14:14 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2B716A4CE for ; Fri, 4 Feb 2005 11:14:14 +0000 (GMT) Received: from alfrad.uts.com.ua (uts-itl.itl.net.ua [217.12.193.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB1543D39 for ; Fri, 4 Feb 2005 11:14:00 +0000 (GMT) (envelope-from paix@uts.com.ua) Received: from vega.uts.com.ua (vega.uts.com.ua [217.12.196.130]) by alfrad.uts.com.ua (8.12.11/8.12.11) with ESMTP id j14BDpAs030045 for ; Fri, 4 Feb 2005 13:13:52 +0200 (EET) (envelope-from paix@uts.com.ua) Received: from [217.12.196.166] (vip.uts.com.ua [217.12.196.166] (may be forged)) by vega.uts.com.ua (8.12.9p2/8.12.9) with ESMTP id j14BDiZm099263 for ; Fri, 4 Feb 2005 13:13:46 +0200 (EET) (envelope-from paix@uts.com.ua) Message-ID: <4203750C.2010003@uts.com.ua> Date: Fri, 04 Feb 2005 13:13:48 +0000 From: Sergej Kandyla User-Agent: Mozilla Thunderbird 0.9 (X11/20050120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20050203175519.K18864@mail.chesapeake.net> <1170.172.16.0.199.1107485566.squirrel@172.16.0.199> In-Reply-To: <1170.172.16.0.199.1107485566.squirrel@172.16.0.199> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 11:14:15 -0000 My test. FreeBSD 4.10-RELEASE-p5 CPU: Intel Pentium III (1005.03-MHz 686-class CPU) real memory = 335458304 (327596K bytes) (PC100) ad0: 57241MB [116301/16/63] at ata0-master UDMA100 [13:04:13]paix@sk(~)$ time dd bs=1024 if=/dev/zero of=tstfile count=1048576 1048576+0 records in 1048576+0 records out 1073741824 bytes transferred in 28.167481 secs (38119909 bytes/sec) real 0m28.236s user 0m0.785s sys 0m18.901s [13:05:13]paix@sk(~)$ Mike Jakubik wrote: >Nick Pavlica said: > > >>Jeff, >> One of the tests where I saw a large difference was in DD. I did a >>quick test on a server that was brought up to RELENG_5 via cvsup on >>2/2/05. >> >>The Test: >>-bash-2.05b$ time dd bs=1024 if=/dev/zero of=tstfile count=1M >>1048576+0 records in >>1048576+0 records out >>1073741824 bytes transferred in 74.402757 secs (14431479 bytes/sec) >> >>real 1m14.498s >>user 0m0.550s >>sys 0m8.838s >> >> > >FYI. > ># time dd bs=1024 if=/dev/zero of=tstfile count=1M >1048576+0 records in >1048576+0 records out >1073741824 bytes transferred in 22.150709 secs (48474377 bytes/sec) > >real 0m22.173s >user 0m0.501s >sys 0m13.832s > >This is on an old ATA disk. > >FreeBSD 6.0-CURRENT #0: Wed Jan 19 21:11:16 EST 2005. > >CPU: AMD Athlon(tm) Processor (1410.21-MHz 686-class CPU) >real memory = 536788992 (511 MB) >acpi0: on motherboard > >ad0: 78167MB [158816/16/63] at ata0-master UDMA100 > > > > -- wbw, paix From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 14:13:48 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CAF016A4CE for ; Fri, 4 Feb 2005 14:13:48 +0000 (GMT) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F4D543D45 for ; Fri, 4 Feb 2005 14:13:47 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [192.168.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id 707C13F294; Fri, 4 Feb 2005 15:13:45 +0100 (CET) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 12E33286; Fri, 4 Feb 2005 15:13:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 04CAC268; Fri, 4 Feb 2005 15:13:44 +0100 (CET) Date: Fri, 4 Feb 2005 15:13:44 +0100 (CET) From: Sten Spans To: Claus Guttesen In-Reply-To: <20050204103210.69846.qmail@web26806.mail.ukl.yahoo.com> Message-ID: References: <20050204103210.69846.qmail@web26806.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Vladimir Vrzic cc: freebsd-performance@freebsd.org Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 14:13:48 -0000 On Fri, 4 Feb 2005, Claus Guttesen wrote: >> On a FreeBSD 5.3 web server with a very high load, I >> recently switched >> from Apache 1.3 and PHP 4.3 to using 2.0 with the >> prefork MPM and PHP 5. >> I noticed a drop in perfomance. What is currently >> the best (in terms of >> performance) choice for Apache w/ PHP on FreeBSD? >> Which MPM should I >> use? Does worker MPM use KSE on FreeBSD 5 and does >> it perform better >> than prefork? What about perchild and threadpool? Or >> maybe I should go >> back to Apache 1.3? Are there any sysctl or kernel >> tunings that I should >> use? > > It is not recommend to use apache 2 with PHP. That's > at least what the folks at php says. We use 1.3 and > are satisfied with the performance. This could use some clarification. Some of the mpm's for apache are threaded ( worker, perchild, etc ). These require every apache module to be threadsafe. PHP itself is threadsafe but quite a few of the libraries php links to aren't. This is why the php folks have chosen a for the safe advice of apache13. They in general don't see the advantages of apache2. Which for most simple unix mod_php installs arent that apparent. > > Have you tried to set the following in > /usr/local/etc/apache/httpd.conf? > > KeepAlive Off > MaxClients (size of one process) / (avail. RAM) Buffered logs should help a bit too, apache tuning is quite a large topic, with some resource limiting and security choises thrown in as well. I run apache with php as cgi on some boxen for security reasons, and will migrate to apache2 because of the improved errorlog handling ( try print stderr "\n\n\n"; in a cgi to see the difference ). For a better answer to your questions a more detailed explanation of what you are testing will be needed. - What are you testing ( php ? static html ? is nfs involved ? ) - How are you testing ( ab, httperf ? from where ? ) - Which configuration choises ( childs, modules, memory usage, dns settings ) - etc. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 14:27:37 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEE3D16A4CE for ; Fri, 4 Feb 2005 14:27:37 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2857A43D1D for ; Fri, 4 Feb 2005 14:27:37 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from stevenp4 ([193.123.241.40]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000947136.msg for ; Fri, 04 Feb 2005 14:16:25 +0000 Message-ID: <075901c50ac5$8d56acb0$7f06000a@int.mediasurface.com> From: "Steven Hartland" To: "Sten Spans" , "Claus Guttesen" References: <20050204103210.69846.qmail@web26806.mail.ukl.yahoo.com> Date: Fri, 4 Feb 2005 14:26:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Fri, 04 Feb 2005 14:16:25 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 193.123.241.40 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-performance@freebsd.org X-MDAV-Processed: multiplay.co.uk, Fri, 04 Feb 2005 14:16:28 +0000 cc: Vladimir Vrzic cc: freebsd-performance@freebsd.org Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 14:27:38 -0000 ----- Original Message ----- From: "Sten Spans" > I run apache with php as cgi on some boxen for security reasons, > and will migrate to apache2 because of the improved errorlog handling > ( try print stderr "\n\n\n"; in a cgi to see the difference ). iirc this there is a compile time switch which fixes this. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 15:40:52 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F2516A4CE for ; Fri, 4 Feb 2005 15:40:52 +0000 (GMT) Received: from web26807.mail.ukl.yahoo.com (web26807.mail.ukl.yahoo.com [217.146.176.83]) by mx1.FreeBSD.org (Postfix) with SMTP id 74B6E43D1F for ; Fri, 4 Feb 2005 15:40:51 +0000 (GMT) (envelope-from cguttesen@yahoo.dk) Received: (qmail 35526 invoked by uid 60001); 4 Feb 2005 15:40:50 -0000 Message-ID: <20050204154050.35524.qmail@web26807.mail.ukl.yahoo.com> Received: from [194.248.174.58] by web26807.mail.ukl.yahoo.com via HTTP; Fri, 04 Feb 2005 16:40:50 CET Date: Fri, 4 Feb 2005 16:40:50 +0100 (CET) From: Claus Guttesen To: freebsd-performance@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: an import into postgresql X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:40:52 -0000 Hi. I have a postgresql-dump at 748 MB bz2-compressed (3,8 uncompressed). I did an import on FreeBSD 5.3 and 6.0, NetBSD 2.0 and Gentoo Linux using kernel 2.6.10. The import was done on a laptop with 512 MB ram and a 3.2 GHz P4. I applied -O2 -funroll-loops -march=p4 in /etc/make.conf and did 'make world/kernel' using GENERIC as kernel on FreeBSD. Kernel on FreeBSD 6.0 and Gentoo and NetBSD was rebuild without smp. The disk was recognized as a UDMA 33 device. Postgresql was 7.4.6. The import-cmd was: time bzcat dump.bz2 | PGUSER=pgsql psql db FreeBSD 5.3 release: psql: 55 user, 36 system, 1 % CPU 1.40.17 total FreeBSD 5.3 stable: psql: 55 user, 36 system, 1 % CPU 1.39.45 total FreeBSD 6.0 current (wo. debugging and smp in kernel): psql: 55 user, 35 system, 2 % CPU 1.39.20 total NetBSD 2.0 (optimized using cpuflags in mk.conf): pgsql 49.16s user 61.99s system 2% cpu 1:30:05.82 total Gentoo (using xfs as fs): psql 136,79s user 53,57s system 1% cpu 2:45:01,57 total What puzzles me is the Gentoo-import which is almost twice as long as *BSD. When I scp'ed the file from another host the transfer-rate quickly dropped from around 7.4 MB/s to 2.5 MB/s whereas *BSD would transfer the file at approx. 7.2 MB/s. I tried the same on our Dell 2850 with a Perc-controller but only FreeBSD would install and boot where NetBSD's i386 would install but not boot. I installed Gentoo (amd64) but grub was apperantly misconfigured and panicked (stupid installer =)"(%)"(#%)&"#¤!!!) I'll try the i386-port and lilo and will post the same import-times if any one is interested. regards Claus From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 15:44:55 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3BDC16A4CE for ; Fri, 4 Feb 2005 15:44:55 +0000 (GMT) Received: from mail.foolishgames.com (mail.foolishgames.com [216.55.178.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B1E043D45 for ; Fri, 4 Feb 2005 15:44:55 +0000 (GMT) (envelope-from luke@foolishgames.com) Received: from [192.168.0.4] (24.247.120.6.kzo.mi.chartermi.net [24.247.120.6]) (authenticated bits=0)j14Filur074816; Fri, 4 Feb 2005 07:44:47 -0800 (PST) (envelope-from luke@foolishgames.com) X-Authentication-Warning: mail.foolishgames.com: Host 24.247.120.6.kzo.mi.chartermi.net [24.247.120.6] claimed to be [192.168.0.4] Message-ID: <4203986E.50200@foolishgames.com> Date: Fri, 04 Feb 2005 10:44:46 -0500 From: Lucas Holt User-Agent: Mozilla Thunderbird 1.0 (X11/20041211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Vrzic References: <1107510981.23035.17.camel@localhost> In-Reply-To: <1107510981.23035.17.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-performance@freebsd.org Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:44:55 -0000 Vladimir Vrzic wrote: >On a FreeBSD 5.3 web server with a very high load, I recently switched >from Apache 1.3 and PHP 4.3 to using 2.0 with the prefork MPM and PHP 5. >I noticed a drop in perfomance. What is currently the best (in terms of >performance) choice for Apache w/ PHP on FreeBSD? Which MPM should I >use? Does worker MPM use KSE on FreeBSD 5 and does it perform better >than prefork? What about perchild and threadpool? Or maybe I should go >back to Apache 1.3? Are there any sysctl or kernel tunings that I should >use? > > > What I find odd is that you switched two software packages and assume its apache's fault for the performance drop. If you are just testing php code, it could very well be the php5 is slower than php4 for your code. From my understanding prefork is recommended with mod anything in apache 2 right now simply because most modules link with non thread safe libraries. From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 15:57:04 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24CDF16A4CE for ; Fri, 4 Feb 2005 15:57:04 +0000 (GMT) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B99CF43D1D for ; Fri, 4 Feb 2005 15:57:01 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [IPv6:2001:960:301:3:a00:20ff:fe85:fa39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id 059963F294; Fri, 4 Feb 2005 16:57:00 +0100 (CET) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 86B7F286; Fri, 4 Feb 2005 16:56:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 74D8D268; Fri, 4 Feb 2005 16:56:59 +0100 (CET) Date: Fri, 4 Feb 2005 16:56:59 +0100 (CET) From: Sten Spans To: Steven Hartland In-Reply-To: <075901c50ac5$8d56acb0$7f06000a@int.mediasurface.com> Message-ID: References: <20050204103210.69846.qmail@web26806.mail.ukl.yahoo.com> <075901c50ac5$8d56acb0$7f06000a@int.mediasurface.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-performance@freebsd.org cc: Vladimir Vrzic cc: Claus Guttesen Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 15:57:04 -0000 On Fri, 4 Feb 2005, Steven Hartland wrote: > ----- Original Message ----- From: "Sten Spans" > >> I run apache with php as cgi on some boxen for security reasons, >> and will migrate to apache2 because of the improved errorlog handling >> ( try print stderr "\n\n\n"; in a cgi to see the difference ). > > iirc this there is a compile time switch which fixes this. nope, I ain't talking about the unescaped stuff. In apache13 errorlog is straight stderr for cgi's. With apache2 things are fidled with in mod_cgi which stops extranous \n's. I need this to be able to split the errorlog per vhost ( I don't want to waste fd's on an errorlog per vhost ). -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 22:53:30 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A15116A4CE; Fri, 4 Feb 2005 22:53:30 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09AF543D45; Fri, 4 Feb 2005 22:53:30 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 72483C0E6; Fri, 4 Feb 2005 23:53:29 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 01C9D407C; Fri, 4 Feb 2005 23:53:09 +0100 (CET) Date: Fri, 4 Feb 2005 23:53:08 +0100 From: Jeremie Le Hen To: Robert Watson Message-ID: <20050204225308.GJ163@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: performance@FreeBSD.org Subject: Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 22:53:30 -0000 > I have the numbers below, but here are the conclusions: on this hardware, > using a single ATA disk, there was no real measurable performance > difference between UP/SMP, and 4.x/6.x -- 6.x came out slightly ahead on > t/s, but not hugely so. I take this to mean that the hardware was > basically I/O bound on file system meta-data operations. Thank you for your tests Robert. I don't want to consume your precious time needlessly, but I would like to compare these results with 5.x performances. There are already many improvements in CURRENT that will never be MFC'ed to RELENG_5 and this will show us if we can expect RELENG_5 to be someday as effective as RELENG_4 and CURRENT are. Regards, -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-performance@FreeBSD.ORG Sat Feb 5 00:44:44 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 188E816A4CE for ; Sat, 5 Feb 2005 00:44:44 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4003443D3F for ; Sat, 5 Feb 2005 00:44:43 +0000 (GMT) (envelope-from linicks@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so343956rnz for ; Fri, 04 Feb 2005 16:44:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LTLKgk8jBgz2N/7eBpv/lMokrCTpg4XlB4sVZf7LjtyqGwF3iJd1wUMyxwHWU1NtRpCu/BtcuPO0z2xQge9IChFUOw0HNuJKbJl8QX/BV1M3NfcbemLwMUeD+BGcZyCrKAcDS4pmrAgtJlhid6GkEeGzBQKUmNWJKR8lbiPHWro= Received: by 10.38.8.57 with SMTP id 57mr244720rnh; Fri, 04 Feb 2005 16:44:42 -0800 (PST) Received: by 10.38.8.20 with HTTP; Fri, 4 Feb 2005 16:44:42 -0800 (PST) Message-ID: Date: Fri, 4 Feb 2005 17:44:42 -0700 From: Nick Pavlica To: Jeff Roberson In-Reply-To: <20050203230343.M18864@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_792_15334827.1107564282602" References: <20050203175519.K18864@mail.chesapeake.net> <20050203230343.M18864@mail.chesapeake.net> cc: freebsd-performance@freebsd.org Subject: Re: My disk I/O testing methods for FreeBSD 5.3 ... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nick Pavlica List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 00:44:44 -0000 ------=_Part_792_15334827.1107564282602 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Jeff, Here is the data from the same test on the exact same server with 4.11R installed. minime# time dd bs=1024 if=/dev/zero of=tstfile count=1m 1048576+0 records in 1048576+0 records out 1073741824 bytes transferred in 25.278113 secs (42477135 bytes/sec) ------------------------------------------------------------------------------------------------------------------------ real 0m25.387s user 0m0.719s sys 0m6.794s ------------------------------------------------------------------------------------------------------------------------ minime# sysctl hw.ata hw.ata.ata_dma: 1 hw.ata.wc: 1 hw.ata.tags: 0 hw.ata.suspend: 0 hw.ata.atapi_dma: 0 ------------------------------------------------------------------------------------------------------------------------ minime# atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI rev 6 Slave: no device present ATA channel 1: Master: acd0 ATA/ATAPI rev 0 Slave: no device present ATA channel 2: Master: no device present Slave: no device present ATA channel 3: Master: no device present Slave: no device present ------------------------------------------------------------------------------------------------------------------------ minime# atacontrol mode 0 Master = UDMA100 Slave = ??? ------------------------------------------------------------------------------------------------------------------------ minime# atacontrol mode 1 Master = PIO4 Slave = ??? ------------------------------------------------------------------------------------------------------------------------ --Nick On Thu, 3 Feb 2005 23:03:55 -0500 (EST), Jeff Roberson wrote: > > On Thu, 3 Feb 2005, Nick Pavlica wrote: > > > Jeff, > > One of the tests where I saw a large difference was in DD. I did a > > quick test on a server that was brought up to RELENG_5 via cvsup on > > 2/2/05. > > Can you give me the same from RELENG_4? > > > > > The Test: > > -bash-2.05b$ time dd bs=1024 if=/dev/zero of=tstfile count=1M > > 1048576+0 records in > > 1048576+0 records out > > 1073741824 bytes transferred in 74.402757 secs (14431479 bytes/sec) > > > > real 1m14.498s > > user 0m0.550s > > sys 0m8.838s > > > > > > The vmstat -1 info is attached. > > > > > > Thanks! > > --Nick > > > > > > > > On Thu, 3 Feb 2005 17:59:30 -0500 (EST), Jeff Roberson > > wrote: > > > > > > On Thu, 3 Feb 2005, Nick Pavlica wrote: > > > > > > > All, > > > > I would like to share the methods that I have been using in my disk > > > > I/O testing. The detailed results of these tests have been posted to > > > > the performance and questions mailing lists under the title " FreeBSD > > > > 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion". I > > > > originally started this testing as due diligence in an up coming > > > > project. As a result of this testing I discovered an elegant > > > > operating system that I enjoy working with. > > > > > > Nick, first, I'd like to thank you for your efforts so far. I think your > > > tests have been very informative. I'd like to see what we can do to get > > > to the bottom of the differences. Can you perform one test which varied > > > greatly between 5.x and 4.x and collect some data for us? To start with, > > > the output of vmstat 1 piped to a file would be informative. Do you have > > > any indication that 5.x is actually cpu bound in a case where 4.x is not? > > > I'm wondering if this is a latency issue or a cpu utilization issue. > > > > > > I intend to backport some code that lets me graph system activity into > > > RELENG_5. Are you setup to cvsup to this tag? Would it be convenient for > > > you to do so? > > > > > > Thanks, > > > Jeff > > > > > > > > > > > Intent Of This Testing: > > > > 1)To measure the disk I/O performance of various operating systems for > > > > use as a production database server. > > > > 2)Help improve the disk I/O performance of FreeBSD 5.x and greater by > > > > assisting the FreeBSD development team in identifying possible > > > > performance issues, and provide them with data to measure the success > > > > of various changes to the operating system. > > > > > > > > Operating Systems tested: > > > > Fedora Core 3 with EXT3, and XFS. I tested with and with out patches. > > > > SUSE Enterprise Server 9 with Riser FS. > > > > FreeBSD 4.11R > > > > FreeBSD 5.3R, RELENG_5_3, RELENG_5 > > > > NetBSD 2.0R > > > > OpenBSD 3.6R > > > > > > > > Test Hardware: > > > > Compaq DeskPro, PIII 800, 384Mb Ram, 10Gb IDE HD. > > > > Dell PE 2400, Dual PIII 550, 512Mb Ram, (2)10K,LVD SCSI, RAID 1, PERC > > > > 2SI controller with 64Mb ram. > > > > Dell PE SC400, 2.4Ghz P4, 256MB Ram, 40Gb IDE HD. > > > > Dell 4600, 2.8 Ghz P4 with HT, 512MB Ram, 80GB IDE HD. > > > > > > > > Installation Notes: > > > > It's my intention to test these Operating Systems using as many of > > > > the default installation options as possible with no special tuning. > > > > The only deviations in my previous testing were as follows: The #linux > > > > xfs option was used when installing Fedora so that I could use XFS, > > > > and a special test where I installed 5.3R with UFS instead of UFS2 (I > > > > didn't see any improvement when using UFS). I installed FreeBSD using > > > > the standard install option, and used the auto allocate features for > > > > partitioning and slicing. I installed Fedora with the stock server > > > > packages and created a 100Mb /boot, 512Mb swap, and allocated the > > > > remaining space to /. I tested FreeBSD5.3R and FC3R with and without > > > > updates. I used cvsup to update FreeBSD and yum update to update > > > > Fedora. I didn't do any updating to FreeBSD4.11R, NetBSD2.0, and > > > > OpenBSD3.6. > > > > > > > > I used the following utilities/tools in my testing: > > > > DD > > > > CP > > > > IOSTAT (iostat -d 2) > > > > Bonnie++ > > > > TOP > > > > SQL,PL, PSQL > > > > Postgresql 8.0 > > > > > > > > DD Example Tests: > > > > - #time dd bs=1024 if=/dev/zero of=tstfile count=1M > > > > - #time dd bs=1024 if=/dev/zero of=tstfile count=2M > > > > - #time dd bs=1024 if=/dev/zero of=tstfile count=3M > > > > > > > > Bonnie++ Example Tests: > > > > #bonnie++ -u root -s 1024 -r 512 -n 5 > > > > #bonnie++ -u root -s 2048 -r 512 -n 5 > > > > #bonnie++ -u root -s 3072 -r 512 -n 5 > > > > > > > > CP Example Tests: > > > > #time cp tstfile tstfile2 > > > > > > > > SQL, PL, PSQL Example Tests: > > > > > > > > CREATE TABLE test1 ( > > > > thedate TIMESTAMP, > > > > astring VARCHAR(200), > > > > anumber INTEGER > > > > ); > > > > > > > > CREATE FUNCTION build_data() RETURNS integer AS ' > > > > DECLARE > > > > i INTEGER DEFAULT 0; > > > > curtime TIMESTAMP; > > > > BEGIN > > > > FOR i IN 1..1000000 LOOP > > > > curtime := ''now''; > > > > INSERT INTO test1 VALUES (curtime, ''test string'', i); > > > > END LOOP; > > > > RETURN 1; > > > > END; > > > > ' LANGUAGE 'plpgsql'; > > > > > > > > SELECT build_data(); > > > > Then the following script is run under the time program to ascertain > > > > how long it takes to run: > > > > CREATE TABLE test2 ( > > > > thedate TIMESTAMP, > > > > astring VARCHAR(200), > > > > anumber INTEGER > > > > ); > > > > CREATE TABLE test3 AS SELECT * FROM test1; > > > > INSERT INTO test2 SELECT * FROM test1 WHERE ((anumber % 2) = 0); > > > > DELETE FROM test3 WHERE ((anumber % 2) = 0); > > > > DELETE FROM test3 WHERE ((anumber % 13) = 0); > > > > CREATE TABLE test4 AS > > > > SELECT test1.thedate AS t1date, > > > > test2.thedate AS t2date, > > > > test1.astring AS t1string, > > > > test2.astring AS t2string, > > > > test1.anumber AS t1number, > > > > test2.anumber AS t2number > > > > FROM test1 JOIN test2 ON test1.anumber=test2.anumber; > > > > UPDATE test3 SET thedate='now' WHERE ((anumber % 5) = 0); > > > > DROP TABLE test4; > > > > CREATE TABLE test4 AS SELECT * FROM test1; > > > > DELETE FROM test4 WHERE ((anumber % 27) = 0); > > > > VACUUM ANALYZE; > > > > VACUUM FULL; > > > > DROP TABLE test4; > > > > DROP TABLE test3; > > > > DROP TABLE test2; > > > > VACUUM FULL; > > > > > > > > Example FS TAB: > > > > > > > > minime# cat /etc/fstab > > > > # Device Mountpoint FStype Options Dump Pass# > > > > /dev/ad0s1b none swap sw 0 0 > > > > /dev/ad0s1a / ufs rw 1 1 > > > > /dev/ad0s1e /tmp ufs rw 2 2 > > > > /dev/ad0s1f /usr ufs rw 2 2 > > > > /dev/ad0s1d /var ufs rw 2 2 > > > > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > > > > > Verification Of Test: > > > > I have been able to get consistent results in all of my testing. > > > > However, I think the best verification would be to have as many people > > > > as possible test the disk I/O performance on a range of hardware, > > > > testing methods, and configurations. > > > > > > > > Summary Of Results: > > > > The results of my testing have consistently demonstrated that > > > > FreeBSD5.3+ has dramatically slower disk I/O performance than all of > > > > the other operating systems that were tested. FreeBSD 4.11R was the > > > > performance leader followed by Fedora C3 with XFS. All of the BSD > > > > distributions, with the exception of 5.3+, were able to consistently > > > > demonstrate a throughput of 56-58Mb/s sustained throughput, while 5.3+ > > > > consistently demonstrated a throughput of 12-15Mb/s (58 -15 = 43 ?). > > > > > > > > Please let me know if you need any additional details. > > > > > > > > Thanks! > > > > --Nick Pavlica > > > > _______________________________________________ > > > > 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" > > > > > > > > > > ------=_Part_792_15334827.1107564282602 Content-Type: application/octet-stream; name="dmesg_info" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg_info" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDQuMTEtUkVMRUFTRSAjMDogRnJpIEphbiAyMSAxNzoyMToy MiBHTVQgMjAwNQogICAgcm9vdEBwZXJzZXVzLmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Iv c3JjL3N5cy9HRU5FUklDClRpbWVjb3VudGVyICJpODI1NCIgIGZyZXF1ZW5jeSAxMTkzMTgyIEh6 CkNQVTogSW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAyLjI2R0h6ICgyMjYxLjAxLU1IeiA2ODYt Y2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4ZjI5ICBTdGVwcGlu ZyA9IDkKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1D RSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFD UEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KcmVhbCBtZW1vcnkgID0gMjY3ODYy MDE2ICgyNjE1ODRLIGJ5dGVzKQphdmFpbCBtZW1vcnkgPSAyNTUxNTIxMjggKDI0OTE3MksgYnl0 ZXMpClByZWxvYWRlZCBlbGYga2VybmVsICJrZXJuZWwiIGF0IDB4YzA1NWMwMDAuCldhcm5pbmc6 IFBlbnRpdW0gNCBDUFU6IFBTRSBkaXNhYmxlZApQZW50aXVtIFBybyBNVFJSIHN1cHBvcnQgZW5h YmxlZAptZDA6IE1hbGxvYyBkaXNrClVzaW5nICRQSVIgdGFibGUsIDggZW50cmllcyBhdCAweGMw MGZlYWUwCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2 IGludGVyZmFjZQpwY2liMDogPEhvc3QgdG8gUENJIGJyaWRnZT4gb24gbW90aGVyYm9hcmQKcGNp MDogPFBDSSBidXM+IG9uIHBjaWIwCmFncDA6IDxJbnRlbCA4Mjg3NVAgaG9zdCB0byBBR1AgYnJp ZGdlPiBtZW0gMHhmMDAwMDAwMC0weGY3ZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMApwY2li MTogPFBDSSB0byBQQ0kgYnJpZGdlICh2ZW5kb3I9ODA4NiBkZXZpY2U9MjU3OSk+IGF0IGRldmlj ZSAxLjAgb24gcGNpMApwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjEKdWhjaTA6IDxJbnRlbCA4Mjgw MUVCIChJQ0g1KSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAweGZmODAtMHhmZjlmIGlycSAx MSBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVzYjA6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0Ig Y29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDog SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1 YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8SW50ZWwg ODI4MDFFQiAoSUNINSkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhmZjYwLTB4ZmY3ZiBp cnEgMTAgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1c2IxOiA8SW50ZWwgODI4MDFFQiAoSUNINSkg VVNCIGNvbnRyb2xsZXIgVVNCLUI+IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1 YjE6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPElu dGVsIDgyODAxRUIgKElDSDUpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4ZmY0MC0weGZm NWYgaXJxIDkgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1c2IyOiA8SW50ZWwgODI4MDFFQiAoSUNI NSkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAK dWh1YjI6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMzog PEludGVsIDgyODAxRUIgKElDSDUpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4ZmYyMC0w eGZmM2YgaXJxIDExIGF0IGRldmljZSAyOS4zIG9uIHBjaTAKdXNiMzogPEludGVsIDgyODAxRUIg KElDSDUpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBvbiB1aGNpMwp1c2IzOiBVU0IgcmV2aXNpb24g MS4wCnVodWIzOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMQp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNp MDogPFVTQiBjb250cm9sbGVyPiBhdCAyOS43IGlycSA1CnBjaWIyOiA8SW50ZWwgODI4MDFCQS9C QU0gKElDSDIpIEh1YiB0byBQQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTI6 IDxQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiA8QVRJIE1hY2g2NC1HUiBncmFwaGljcyBhY2NlbGVy YXRvcj4gYXQgMC4wIGlycSA1CmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVj dGlvbiwgVmVyc2lvbiAtIDEuNy40Mj4gcG9ydCAweGRkYzAtMHhkZGZmIG1lbSAweGZlOWUwMDAw LTB4ZmU5ZmZmZmYgaXJxIDkgYXQgZGV2aWNlIDEyLjAgb24gcGNpMgplbTA6ICBTcGVlZDpOL0Eg IER1cGxleDpOL0EKaXNhYjA6IDxQQ0kgdG8gSVNBIGJyaWRnZSAodmVuZG9yPTgwODYgZGV2aWNl PTI0ZDApPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAph dGFwY2kwOiA8SW50ZWwgSUNINSBBVEExMDAgY29udHJvbGxlcj4gcG9ydCAweGZmYTAtMHhmZmFm LDB4Mzc0LTB4Mzc3LDB4MTcwLTB4MTc3LDB4M2Y0LTB4M2Y3LDB4MWYwLTB4MWY3IG1lbSAweGZl YmZmYzAwLTB4ZmViZmZmZmYgaXJxIDkgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAphdGEwOiBhdCAw eDFmMCBpcnEgMTQgb24gYXRhcGNpMAphdGExOiBhdCAweDE3MCBpcnEgMTUgb24gYXRhcGNpMAph dGFwY2kxOiA8SW50ZWwgSUNINSBTQVRBMTUwIGNvbnRyb2xsZXI+IHBvcnQgMHhmZWEwLTB4ZmVh ZiwweGZlMzAtMHhmZTMzLDB4ZmUyMC0weGZlMjcsMHhmZTEwLTB4ZmUxMywweGZlMDAtMHhmZTA3 IGlycSA5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYXRhMjogYXQgMHhmZTAwIG9uIGF0YXBjaTEK YXRhMzogYXQgMHhmZTIwIG9uIGF0YXBjaTEKcGNpMDogPHVua25vd24gY2FyZD4gKHZlbmRvcj0w eDgwODYsIGRldj0weDI0ZDMpIGF0IDMxLjMgaXJxIDEwCnBjaTA6IDx1bmtub3duIGNhcmQ+ICh2 ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGQ1KSBhdCAzMS41IGlycSAxMApvcm0wOiA8T3B0aW9uIFJP TXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4Yzk3ZmYsMHhjOTgwMC0weGNi ZmZmIG9uIGlzYTAKcG10aW1lcjAgb24gaXNhMApmZGMwOiA8TkVDIDcyMDY1QiBvciBjbG9uZT4g YXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCmZkYzA6IEZJRk8g ZW5hYmxlZCwgOCBieXRlcyB0aHJlc2hvbGQKZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBm ZGMwIGRyaXZlIDAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9y dCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gZmxhZ3MgMHgxIGlycSAx IG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBh dGtiZGMwCnBzbTA6IG1vZGVsIEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAKdmdhMDog PEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZm ZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApz YzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzAgYXQgcG9ydCAw eDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGlzYTAKc2lvMDogdHlwZSAxNjU1MEEKc2lv MSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAKc2lvMTogdHlwZSAxNjU1MEEKcHBj MDogPFBhcmFsbGVsIHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhMApwcGMw OiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9k ZQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOCBieXRlcyB0aHJlc2hvbGQKcGxpcDA6IDxQTElQIG5l dHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czAKbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQw OiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCmFk MDogMzgxNDZNQiA8U1QzNDAwMTRBPiBbNzc1MDQvMTYvNjNdIGF0IGF0YTAtbWFzdGVyIFVETUEx MDAKYWNkMDogQ0RST00gPExpdGUtT24gTFRONDg2UyA0OHggTWF4PiBhdCBhdGExLW1hc3RlciBQ SU80Ck1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEKZW0wOiBMaW5rIGlzIHVwIDEw MCBNYnBzIEZ1bGwgRHVwbGV4Cg== ------=_Part_792_15334827.1107564282602 Content-Type: application/octet-stream; name="vm_stat_info" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="vm_stat_info" IHByb2NzICAgICAgbWVtb3J5ICAgICAgcGFnZSAgICAgICAgICAgICAgICAgICAgZGlza3MgICAg IGZhdWx0cyAgICAgIGNwdQogciBiIHcgICAgIGF2bSAgICBmcmUgIGZsdCAgcmUgIHBpICBwbyAg ZnIgIHNyIGFkMCBtZDAgICBpbiAgIHN5ICBjcyB1cyBzeSBpZAogMCAwIDAgICAxMzcwOCAyMTkw NjAgICAgOSAgIDAgICAwICAgMCAgIDYgICAwICAgMCAgIDAgIDIzMSAgIDMxICAgNiAgMCAgMCAx MDAKIDAgMCAwICAgMTMyNzIgMjE5MDUyICAgIDggICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAw ICAyMzIgICAyMyAgIDUgIDAgIDAgMTAwCiAwIDAgMCAgIDEyOTIwIDIxOTA1MiAgICAzICAgMCAg IDAgICAwICAgMCAgIDAgICAwICAgMCAgMjMyICAgMTAgICA0ICAwICAwIDEwMAogMSAwIDAgICAx MzE1NiAxOTQwMDAgICAzNiAgIDAgICAzICAgMCAgMjMgICAwIDE4NyAgIDAgIDQyNiA0OTYyMyAg NDMgIDEgMTcgODIKIDAgMSAwICAgMTMxNTYgMTUxNDc2ICAgIDMgICAwICAgMCAgIDAgIDE4ICAg MCAzMzEgICAwICA1NjQgODQ3NDQgIDYxICAyIDI1IDczCiAwIDEgMCAgIDEzMTU2IDEwNjg4OCAg ICA2ICAgMCAgIDAgICAwICAgMCAgIDAgMzQxICAgMCAgNTc1IDg4ODU0ICA2MiAgMyAyOSA2Nwog MCAxIDAgICAxMzE1NiAgNjM3OTIgICAgMyAgIDAgICAwICAgMCAgIDAgICAwIDMzNCAgIDAgIDU2 NyA4NTc3MCAgNjAgIDQgMjYgNzEKIDAgMSAwICAgMTMxNTYgIDIxMjQwICAgIDMgICAwICAgMCAg IDAgICAwICAgMCAzMzYgICAwICA1NzAgODQ3NDggIDU5ICAyIDMwIDY4CiAwIDEgMCAgIDEzNTky ICAxNDkyMCAgICAzICAgMCAgIDAgICAwIDYwMDkgMTAzNjMgMzM4ICAgMCAgNTcxIDg4ODQ1ICA3 MCAgNCAzMyA2NAogMCAxIDAgICAxMzU5MiAgMTAzOTIgICAgMyAgIDAgICAwICAgMCAxMDcxMCA5 NTc4IDMzMyAgIDAgIDU2NiA4NTI1OCAgNjkgIDIgMzEgNjcKIDAgMTEgMCAgIDE3NjI4ICAxMjA5 MiAgIDI0ICAgMCAgIDEgICAwIDExMDg0IDExNDkzIDM0MiAgIDAgIDU4NyA4ODE5MSAgODUgIDQg MjggNjgKIDEgMSAwICAgMTgwOTYgICA5NDc2ICAgIDkgICAwICAgMCAgIDAgMTAyMjkgOTU3NCAz MTYgICAwICA1NDkgODE0MDAgIDcwICAzIDI5IDY4CiAwIDUgMCAgIDE4NDUyICAxNDQ4OCAgICA3 ICAgMCAgIDAgICAwIDEwMjM3IDExNDkwIDMxNiAgIDAgIDU0OSA4MTQ2MCAgNzUgIDIgMjkgNjkK IDAgNSAwICAgMTg0NTIgIDEwMDA0ICAgIDMgICAwICAgMCAgIDAgMTA2OTggOTU3NyAzMjkgICAw ICA1NjIgODUyNTggIDY5ICAyIDMxIDY3CiAwIDUgMCAgIDE4NDg4ICAxNDY0OCAgICA0ICAgMCAg IDIgICAwIDEwMzMzIDExNDk0IDMyMCAgIDAgIDU1NyA4MjE4OCAgNzQgIDQgMjcgNjkKIDAgMTMg MCAgIDE4NDkyICAxMTg4NCAgICA3ICAgMCAgIDEgICAwIDEwMjY2IDk1NzUgMzIxICAgMCAgNTU2 IDgxNjk0ICA3MiAgMSAzMSA2OAogMCAxMyAwICAgMTg0OTIgIDE1MDY4ICAgIDMgICAwICAgMCAg IDAgMTA2OTcgMTE0OTMgMzI5ICAgMCAgNTYzIDg1MjU4ICA3MiAgMyAyOSA2OAogMSAxMiAwICAg MTg1MTIgIDEyMzY4ICAgIDQgICAwICAgMSAgIDAgMTAyNTAgOTU3NiAzMTkgICAwICA1NTQgODE1 ODAgIDY5ICAyIDI5IDY4CiBwcm9jcyAgICAgIG1lbW9yeSAgICAgIHBhZ2UgICAgICAgICAgICAg ICAgICAgIGRpc2tzICAgICBmYXVsdHMgICAgICBjcHUKIHIgYiB3ICAgICBhdm0gICAgZnJlICBm bHQgIHJlICBwaSAgcG8gIGZyICBzciBhZDAgbWQwICAgaW4gICBzeSAgY3MgdXMgc3kgaWQKIDAg NSAwICAgMTg1OTYgICA5NTY0ICAgMTMgICAwICAgMiAgIDAgMTAyODIgOTU3NyAzMjEgICAwICA1 NTcgODE3OTEgIDc0ICAxIDI5IDcwCiAwIDUgMCAgIDE4NTk2ICAxMjYwOCAgICAzICAgMCAgIDAg ICAwIDEwNzMwIDExNDkxIDMyOSAgIDAgIDU2MiA4NTUxNCAgNzQgIDIgMzMgNjUKIDAgNCAwICAg MTQ5MzYgIDEwMjE2ICAgIDcgICAwICAgMSAgIDAgMTAxNzMgOTU3NSAzMTYgICAwICA1NTEgODA5 MzUgIDcxICAxIDI5IDcxCiAwIDQgMCAgIDE0OTM2ICAxMzI2OCAgICAzICAgMCAgIDAgICAwIDEw NzMwIDExNDk2IDMyOSAgIDAgIDU2MyA4NTUxNCAgNzIgIDQgMzEgNjUKIDEgMCAwICAgMTAxNDAg IDEwMjk2ICAgIDUgICAwICAgMCAgIDAgMTAzNDggOTU3NyAzMjAgICAwICA1NTQgODIzNjYgIDcy ICAyIDI3IDcxCiAwIDEgMCAgIDEwMTQwICAxNDY4MCAgICAzICAgMCAgIDAgICAwIDEwMzk3IDEx NDkzIDMyNCAgIDAgIDU1OSA4MjgwNyAgNzUgIDQgMjcgNjkKIDAgMSAwICAgMTAxNDAgIDEwMDY4 ICAgIDMgICAwICAgMCAgIDAgMTA3MzAgOTU3NyAzMjkgICAwICA1NjkgODU1NjUgIDc2ICA0IDI4 IDY4CiAwIDUgMCAgIDEwMDI4ICAxNTg4NCAgIDM3ICAgMCAgIDIgICAwIDEwMDY4IDExNDkzIDMx MyAgIDAgIDU1NSA3OTk5MyAgODcgIDMgMzMgNjQKIDEgNyAwICAgMTA4NDQgIDEzOTI0ICAgMjUg ICAwICAgMyAgIDAgMTAwNjcgOTU3NiAzMTUgICAwICA1NTEgNzk4NDUgIDczICA1IDI0IDcxCiAw IDggMCAgIDEwNDA4ICAxMTYxMiAgICAzICAgMCAgIDAgICAwIDEwMTU1IDk1NzcgMzE0ICAgMCAg NTQ3IDgwOTY4ICA2OSAgMyAyOSA2OAogMCAxIDAgICAxMjg4MCAgMTU1OTIgIDE5NiAgIDkgICA2 ICAgMCA0OTY4IDU3NDcgMTc5ICAgMCAgNDM3IDM4MjA0IDExNSAgNSAxMiA4MwogMCAwIDAgICAx MzMzMiAgMTU0MzYgICA1MCAgIDAgICAxICAgMCAxNzkgICAwICAyMiAgIDAgIDI1OSAgMTA5ICAy OSAgMCAgMSA5OQogMCAwIDAgICAxMzMzMiAgMTU2NTIgICAgNiAgIDAgICAwICAgMCAgNjAgICAw ICAyMSAgIDAgIDI1MyAgIDIyICAgNiAgMCAgMCAxMDAKIDAgMCAwICAgMTI4OTIgIDE1NjUyICAg IDMgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAyMzIgICAxMCAgIDQgIDAgIDAgMTAwCiAw IDAgMCAgIDEyNTQwICAxNTY1MiAgICAzICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgMjMx ICAgMTAgICA0ICAwICAwIDEwMAogMCAwIDAgICAxMjU0MCAgMTU2NjggICAgMyAgIDAgICAwICAg MCAgIDggICAwICAgMiAgIDAgIDIzNCAgIDEwICAgNSAgMCAgMCAxMDAKIDAgMCAwICAgMTI5ODAg IDE1NjQ0ICAgNjAgICA0ICAgMiAgIDAgIDU2ICAgMCAgIDUgICAwICAyNDIgIDE0OSAgNTEgIDAg IDAgMTAwCiAwIDAgMCAgIDEyOTgwICAxNTY0NCAgICA2ICAgMCAgIDAgICAwICAgMCAgIDAgICAw ICAgMCAgMjMxICAgMjIgICA1ICAwICAwIDEwMAogcHJvY3MgICAgICBtZW1vcnkgICAgICBwYWdl ICAgICAgICAgICAgICAgICAgICBkaXNrcyAgICAgZmF1bHRzICAgICAgY3B1CiByIGIgdyAgICAg YXZtICAgIGZyZSAgZmx0ICByZSAgcGkgIHBvICBmciAgc3IgYWQwIG1kMCAgIGluICAgc3kgIGNz IHVzIHN5IGlkCiAwIDAgMCAgIDEyOTgwICAxNTY0NCAgICAzICAgMCAgIDAgICAwICAgMCAgIDAg ICAwICAgMCAgMjMwICAgMTAgICA0ICAwICAwIDEwMAogMCAwIDAgICAxNDM0NCAgMTUwNTYgIDI4 NiAgIDAgICA4ICAgMCAyMzAgICAwICAzMSAgIDAgIDI4NiAxMDEwIDEzOSAgMSAgMCA5OQogMCAw IDAgICAxNDM0NCAgMTUwNTYgICAgMyAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgIDIzMSAg IDEwICAgNSAgMCAgMCAxMDAKIDAgMCAwICAgMTQzNDQgIDE1MDU2ICAgIDYgICAwICAgMCAgIDAg ICAwICAgMCAgIDAgICAwICAyMzQgICA1MCAgMTAgIDAgIDAgMTAwCiAwIDAgMCAgIDE0MzQ0ICAx NTA1NiAgICA2ICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgMjM0ICAgNjIgIDE1ICAwICAx IDk5CiAwIDAgMCAgIDE0MzQ0ICAxNTA1NiAgICAzICAgMCAgIDAgICAwICAgMCAgIDAgICA1ICAg MCAgMjM5ICAgMzQgICA4ICAwICAwIDEwMAogMCAwIDAgICAxNDY5NiAgMTUwNTYgICAgMyAgIDAg ICAwICAgMCAgIDAgICAwICAgMCAgIDAgIDI0MCAgIDkzICAxNyAgMCAgMCAxMDAKIDAgMCAwICAg MTQ2OTYgIDE1MDU2ICAgIDMgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAyNDIgICA5MCAg MTcgIDAgIDAgMTAwCiAwIDAgMCAgIDE0Njk2ICAxNTA1NiAgICAzICAgMCAgIDAgICAwICAgMCAg IDAgICAwICAgMCAgMjM2ICAgNTAgIDEwICAwICAwIDEwMAogMCAwIDAgICAxNDY5NiAgMTUwNTYg ICAgNiAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgIDIzMyAgIDIzICAgNSAgMCAgMCAxMDAK IDAgMCAwICAgMTQ2OTYgIDE1MDUyICAgIDMgICAwICAgMCAgIDAgICAxICAgMCAgIDAgICAwICAy MzIgICAxMCAgIDQgIDAgIDAgMTAwCiAwIDAgMCAgIDE0Njk2ICAxNTA1MiAgICAzICAgMCAgIDAg ICAwICAgMCAgIDAgICAwICAgMCAgMjM1ICAgNTAgIDEwICAwICAwIDEwMAogMCAwIDAgICAxMTAy OCAgMTUwNTIgICAgMyAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgIDIzNSAgIDUwICAxMSAg MCAgMiA5OAogMCAwIDAgICAxMTM3MiAgMTQ4MjAgIDExMyAgIDAgICAyICAgMCAgOTQgICAwICAg OCAgIDAgIDI0NSAgMjA1ICAyNCAgMCAgMSA5OQogMCAwIDAgICAxMTM3MiAgMTQ4MjAgICAgNiAg IDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgIDIzMCAgIDIyICAgNSAgMCAgMCAxMDAKIDAgMCAw ICAgMTEzNzIgIDE0ODIwICAgIDUgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAyMzEgICAy OSAgIDcgIDAgIDAgMTAwCiAwIDAgMCAgIDExMzcyICAxNDgyMCAgICAzICAgMCAgIDAgICAwICAg MCAgIDAgICAwICAgMCAgMjMxICAgMTAgICA0ICAwICAwIDEwMAo= ------=_Part_792_15334827.1107564282602-- From owner-freebsd-performance@FreeBSD.ORG Fri Feb 4 14:41:16 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC4E16A4CE for ; Fri, 4 Feb 2005 14:41:16 +0000 (GMT) Received: from goofy.cultdeadsheep.org (charon.cultdeadsheep.org [80.65.226.72]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F06A43D2F for ; Fri, 4 Feb 2005 14:41:14 +0000 (GMT) (envelope-from sheepkiller@cultdeadsheep.org) Received: (qmail 63570 invoked by uid 1000); 4 Feb 2005 15:41:12 +0100 Date: Fri, 4 Feb 2005 15:41:12 +0100 From: Clement Laforet To: Vladimir Vrzic Message-ID: <20050204144112.GA44383@goofy.cultdeadsheep.org> References: <1107510981.23035.17.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107510981.23035.17.camel@localhost> User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Sat, 05 Feb 2005 13:16:42 +0000 cc: freebsd-performance@freebsd.org Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2005 14:41:16 -0000 On Fri, Feb 04, 2005 at 10:56:21AM +0100, Vladimir Vrzic wrote: > On a FreeBSD 5.3 web server with a very high load, I recently switched > from Apache 1.3 and PHP 4.3 to using 2.0 with the prefork MPM and PHP 5. > I noticed a drop in perfomance. Did you find the bottleneck? > What is currently the best (in terms of > performance) choice for Apache w/ PHP on FreeBSD? Which MPM should I > use? Does worker MPM use KSE on FreeBSD 5 and does it perform better > than prefork? What about perchild and threadpool? Or maybe I should go > back to Apache 1.3? Are there any sysctl or kernel tunings that I should > use? - Notes on MPM's: Currently, you can expect good performance with prefork and worker. perchild is b0rked and threadpool is experimental. - Using apache2 with PHP is *safe* with prefork. - worker MPM use KSE and performs well, with a custom apache2 (see options for apache2 port), in some cases, worker MPM outperforms prefork one. - If you use apache2 in ports tree, you can try apr_poll() patch which supports kqueue, define WITH_EXPERIMENTAL_PATCHES. It's pretty stable and improves significantly apache reponsivness. clem From owner-freebsd-performance@FreeBSD.ORG Sat Feb 5 14:04:24 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 351D316A4CE for ; Sat, 5 Feb 2005 14:04:24 +0000 (GMT) Received: from pulaski.gmtstudio.com (gmtstudio.com [80.55.96.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED66043D4C for ; Sat, 5 Feb 2005 14:04:21 +0000 (GMT) (envelope-from rafal@junglist.art.pl) Received: from localhost (localhost [127.0.0.1]) by pulaski.gmtstudio.com (Postfix) with ESMTP id BED0A1B9C37; Sat, 5 Feb 2005 15:04:19 +0100 (CET) Received: from pulaski.gmtstudio.com ([127.0.0.1]) by localhost (pulaski.gmtstudio.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46962-14; Sat, 5 Feb 2005 15:04:17 +0100 (CET) Received: from [10.4.4.4] (quark.zabki.net.pl [62.29.136.5]) by pulaski.gmtstudio.com (Postfix) with ESMTP id 7FD0B1B9C12; Sat, 5 Feb 2005 15:04:17 +0100 (CET) Message-ID: <4204D26A.3070802@junglist.art.pl> Date: Sat, 05 Feb 2005 15:04:26 +0100 From: =?ISO-8859-2?Q?Rafa=B3_Banaszkiewicz?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clement Laforet References: <1107510981.23035.17.camel@localhost> <20050204144112.GA44383@goofy.cultdeadsheep.org> In-Reply-To: <20050204144112.GA44383@goofy.cultdeadsheep.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gmtstudio.com cc: freebsd-performance@freebsd.org Subject: Re: Apache 2 on FreeBSD 5.3 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 14:04:24 -0000 >>What is currently the best (in terms of >>performance) choice for Apache w/ PHP on FreeBSD? Which MPM should I >>use? Does worker MPM use KSE on FreeBSD 5 and does it perform better >>than prefork? What about perchild and threadpool? Or maybe I should go >>back to Apache 1.3? Are there any sysctl or kernel tunings that I should >>use? Try to use 'eaccelerator' from www ports tree (development od mmcache has stopped - this one is continuation). If you'll notice heavy loads this could probably help. I also suggest to read this http://httpd.apache.org/docs/misc/perf-tuning.html and this http://talks.php.net/show/perf_tunning . How many requests per second has your webserver ? regards, Rafa³ Banaszkiewicz From owner-freebsd-performance@FreeBSD.ORG Sat Feb 5 15:29:37 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A5EF16A4CE for ; Sat, 5 Feb 2005 15:29:37 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9A9343D4C for ; Sat, 5 Feb 2005 15:29:36 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 4EC7746B27; Sat, 5 Feb 2005 10:29:36 -0500 (EST) Date: Sat, 5 Feb 2005 15:28:43 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jeremie Le Hen In-Reply-To: <20050204225308.GJ163@obiwan.tataz.chchile.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: performance@FreeBSD.org Subject: Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 15:29:37 -0000 On Fri, 4 Feb 2005, Jeremie Le Hen wrote: > > I have the numbers below, but here are the conclusions: on this hardware, > > using a single ATA disk, there was no real measurable performance > > difference between UP/SMP, and 4.x/6.x -- 6.x came out slightly ahead on > > t/s, but not hugely so. I take this to mean that the hardware was > > basically I/O bound on file system meta-data operations. > > Thank you for your tests Robert. I don't want to consume your precious > time needlessly, but I would like to compare these results with 5.x > performances. There are already many improvements in CURRENT that will > never be MFC'ed to RELENG_5 and this will show us if we can expect > RELENG_5 to be someday as effective as RELENG_4 and CURRENT are. I'll attempt to get a 5.x kernel on the box today and see how it looks. While it's true there is work in 6.x that won't be merged to 5.x, a lot of the interesting work will be. In particular, we'd like to work hard to not let 5.x diverge substantially from 6.x, where it's possible. This means you'll see a lot more getting merged to 5.x after testing and exercise in 6.x. For example, pretty much all network performance work is getting merged to 5.x within a couple of months from 6.x; likewise, I know that Jeff is very interested in getting the MPSAFE VFS into 5.x in the medium term (as an option, not the default), and Soren has every intent of merging the new atamkIII work once it's settled (presumably a bit after 5.4). Everyone agrees the gap between 5.x and 4.x was allowed to get much too large, so between more frequent cuts from -CURRENT to -STABLE, and keeping -CURRENT and -STABLE more in sync, we hope to prevent this from happening in the future. The plan, of course, is to do this without negatively impacting the performance and stability of the -STABLE branch, so it will be a careful balancing act. Thus far, it seems to be working out well: the performance and stability of RELENG_5 has increased since the 5.3 release, despite relatively agressive merging. Robert N M Watson From owner-freebsd-performance@FreeBSD.ORG Sat Feb 5 19:42:25 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB15F16A4CE for ; Sat, 5 Feb 2005 19:42:25 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DCDB43D1F for ; Sat, 5 Feb 2005 19:42:25 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id EB7EB46B09 for ; Sat, 5 Feb 2005 14:42:24 -0500 (EST) Date: Sat, 5 Feb 2005 19:41:31 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: performance@FreeBSD.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2005 19:42:26 -0000 At the request of Jeremie Le Hen, I've inserted 5.x-STABLE UP and SMP numbers below. On Fri, 4 Feb 2005, Robert Watson wrote: > UP=Uniprocessor > SMP=Multiprocessor > MV=MPSAFE VFS > > tran sec Length of transaction run in seconds > tran/s Number of transactions/sec over total run > creat/s Number of create transactions/sec ("mixed") > read/s Number of read transactions/sec ("mixed") > app/s Number of append transactions/sec ("mixed") > del/s Number of delete transactions/sec ("mixed") > rd/s Number of read transaction/sec ("mixed") > wr/s Number of write transactions/sec ("mixed") > > tran sec tran/s creat/s read/s app/s del/s rd/s wr/s > 4.x UP 76 131 66 65 66 65 4.00 4.45 > 75 133 67 66 67 66 4.00 4.45 > > 4.x SMP 74 135 68 66 68 67 4.11 4.56 > 76 131 66 65 66 65 3.95 4.39 5.x UP 76 131 66 65 66 65 4.00 4.45 75 133 67 66 67 66 4.06 4.50 5.x SMP 75 133 67 66 67 66 4.00 4.45 74 135 68 66 68 67 4.11 4.56 This would seem to place it closer to 4.x than 5.x -- possibly a property of a lack of preemption. Again, the differences here are so small it's a bit difficult to reason using them. > 6.x UP 73 136 68 67 69 68 4.17 4.62 > 71 140 70 69 70 69 4.22 4.69 > > 6.x UP MV 71 140 70 69 70 69 4.22 4.69 > 71 140 70 69 70 69 4.22 4.69 > > 6.x SMP 72 138 69 68 70 68 4.17 4.62 > 72 138 69 68 70 68 4.22 4.69 > > 6.x SMP MV 72 138 69 68 70 68 4.17 4.62 > 74 135 68 66 68 67 4.11 4.56 > > _______________________________________________ > 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" >