From owner-freebsd-performance@FreeBSD.ORG Sun Feb 17 15:51:33 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B498616A417 for ; Sun, 17 Feb 2008 15:51:33 +0000 (UTC) (envelope-from gemini@geminix.org) Received: from geminix.org (geminix.org [213.73.82.81]) by mx1.freebsd.org (Postfix) with ESMTP id 7C43C13C45B for ; Sun, 17 Feb 2008 15:51:33 +0000 (UTC) (envelope-from gemini@geminix.org) Message-ID: <47B857FB.9090700@geminix.org> Date: Sun, 17 Feb 2008 16:51:23 +0100 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080129 SeaMonkey/1.1.8 (Ubuntu-1.1.8+nobinonly-0ubuntu1) MIME-Version: 1.0 To: Brett Bump References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <47B4C19F.6000900@palisadesys.com> <20080214154528.N75492@mail.rsts.org> <47B4E0A6.3010205@geminix.org> <20080215083930.P79197@mail.rsts.org> In-Reply-To: <20080215083930.P79197@mail.rsts.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JQlnY-000Ow9-Ig; Sun, 17 Feb 2008 16:51:24 +0100 Cc: freebsd-performance@freebsd.org, Guy Helmer Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 15:51:33 -0000 Brett Bump wrote: > On Fri, 15 Feb 2008, Uwe Doering wrote: > >> Have you tried sorting this list alphabetically? Believe it or not, >> when I tried to use Apache 1.3.x with PHP 5.2.x with extensions in >> arbitrary order I got inexplicable crashes, too. >> >> Now, of course it was just a coincidence that it worked for me after >> sorting the extension list. What this in fact points to is that the >> order of extensions can be important in that list, for whatever reason. >> For me it worked after sorting the list, but YMMV. Might be worth a >> try, though. > > Ran it stock, sorted, read a thread a while back about someone who thought > you should have mysql first, then imap, then blah blah blah, nothing made > any difference. The machine tends to always show about 98% memory used, > although at any point in time 1/2 of that could be inact. This is normal. FreeBSD uses almost all RAM for caching purposes if it isn't needed otherwise. > The malloc > errors in the apache logs made me consider the idea of adding more memory > to the box (but there are always pundits that say, "wow, more than 2g?"). As long as swap is barely touched (as I believe you stated in another mail) too little RAM is not your problem. However, 'RAM' brings me to another possibility. There have been reports in the past that certain BIOSes can cause some parts of the RAM to be uncached, which would result in anemic server performance under load. You may want to check with memcontrol list that all relevant memory regions are set to 'write-back'. Note that regions not mentioned explicitly are normally dealt with by a catch-all line towards the end of the list. IIRC, doing a BIOS upgrade usually fixed the problem, but that is of course not guaranteed. Regards, Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-performance@FreeBSD.ORG Mon Feb 18 06:08:57 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BC2216A419 for ; Mon, 18 Feb 2008 06:08:57 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id C0CA313C46B for ; Mon, 18 Feb 2008 06:08:55 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 81094 invoked from network); 18 Feb 2008 05:42:13 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 18 Feb 2008 05:42:13 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 17 Feb 2008 23:42:12 -0600 (CST) From: Mike Silbersack To: freebsd-performance@freebsd.org Message-ID: <20080210112241.W11665@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Syncache / syncookies performance X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 06:08:57 -0000 Kris Kennaway pointed me at Stefan Lambrev's benchmarks on the syncache/syncookies: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=188234+0+archive/2008/freebsd-performance/20080210.freebsd-performance Which seem to say: Syncache only (default size): 316000 pps Syncookies only: 281000 pps Syncookies + syncache: 252000 pps Syncache (larger size): 186000 pps This seems to line up with what I was told by some of the Yahoo guys a few years back. They said that the syncache gets more expensive the bigger you make its hash tables. In theory, the root of problem with the syncache is the dropping of entries; if you're just dropping entries out of the syncache before you get a response, it's not doing anything productive. What SHOULD be the optimal thing to do is to avoid using syncookies in the normal case, unless a syncache bucket fills up. In the case where a bucket is full, we should then leave the syncache entries alone (rather than purging them) and emit a syncookie at that time. I don't have time to implement that, but I'd be happy review it if someone else gets it working and is able to show that it is more efficient. Mike "Silby" Silbersack From owner-freebsd-performance@FreeBSD.ORG Tue Feb 19 13:59:22 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF5E16A417 for ; Tue, 19 Feb 2008 13:59:22 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id D22F613C467 for ; Tue, 19 Feb 2008 13:59:21 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from japan.t-online.private (people [192.168.2.4]) by people.fsn.hu (Postfix) with ESMTP id B02CF80678; Tue, 19 Feb 2008 14:59:15 +0100 (CET) Message-ID: <47BAE0B3.4090004@fsn.hu> Date: Tue, 19 Feb 2008 14:59:15 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 13:59:22 -0000 On 02/13/08 21:44, wrote: > Okay, then please try this patch with '-n 1' (note: this patch doesn't > contain the memory statistics hack via the HTTP interface, but I don't > we don't need it for this test). > > Sorry for the delay, here are the logs: Feb 19 13:51:29 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3679584 Feb 19 13:51:30 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145608 Feb 19 13:51:30 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670040 Feb 19 13:51:31 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3142784 Feb 19 13:51:31 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670960 Feb 19 13:51:32 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3142568 Feb 19 13:51:33 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3699168 Feb 19 13:51:35 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3143144 Feb 19 13:51:35 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3671088 Feb 19 13:51:37 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3141408 Feb 19 13:51:37 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3672184 Feb 19 13:51:38 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3137912 Feb 19 13:51:40 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670160 Feb 19 13:51:41 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145440 Feb 19 13:51:41 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3680224 Feb 19 13:51:42 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145528 Feb 19 13:51:43 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3674320 Feb 19 13:51:45 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145696 Feb 19 13:51:46 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3675800 Feb 19 13:51:48 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3142104 Feb 19 13:51:48 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3674800 Feb 19 13:51:50 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3144104 Feb 19 13:51:50 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670504 Feb 19 13:51:51 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145584 Feb 19 13:51:52 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670200 Feb 19 13:51:54 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145496 Feb 19 13:51:55 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3687768 Feb 19 13:51:57 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 3188272, overmem=1 Feb 19 13:51:57 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:51:57 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3141232 Feb 19 13:51:58 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670632 Feb 19 13:51:59 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3144408 Feb 19 13:52:00 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670704 Feb 19 13:52:01 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3684296 Feb 19 13:52:03 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3144712 Feb 19 13:52:03 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670112 Feb 19 13:52:04 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145712 Feb 19 13:52:05 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3671232 Feb 19 13:52:07 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3145584 Feb 19 13:52:08 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3697744 Feb 19 13:52:09 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3144664 Feb 19 13:52:10 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670040 Feb 19 13:52:13 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3142976 Feb 19 13:52:13 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3670592 Feb 19 13:52:16 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to FALSE, mem inuse 3142792 Feb 19 13:52:16 cns00a named[45171]: database: info: ADB 0x800f16000: overmem switch to TRUE, mem inuse 3672720 Feb 19 13:52:27 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 3651072, overmem=1 Feb 19 13:52:27 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:52:57 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 6832056, overmem=1 Feb 19 13:52:57 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:53:27 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 6331216, overmem=1 Feb 19 13:53:27 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:53:57 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 7005632, overmem=1 Feb 19 13:53:57 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:54:27 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 5024232, overmem=1 Feb 19 13:54:27 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:54:57 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 6819600, overmem=1 Feb 19 13:54:57 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:55:27 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 6863768, overmem=1 Feb 19 13:55:27 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:55:57 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 7097880, overmem=1 Feb 19 13:55:57 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:56:27 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 5771000, overmem=1 Feb 19 13:56:27 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:56:57 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 7198400, overmem=1 Feb 19 13:56:57 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 Feb 19 13:57:27 cns00a named[45171]: database: info: ADB memory usage 0x800f16000: mem inuse 7568776, overmem=1 Feb 19 13:57:27 cns00a named[45171]: database: info: ADB memory usage 0x8011e8000: mem inuse 65536, overmem=0 407 MB RES at this point... (max-cache-size still 32M) -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From owner-freebsd-performance@FreeBSD.ORG Tue Feb 19 19:53:20 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C443216A420; Tue, 19 Feb 2008 19:53:20 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8CA13C4E1; Tue, 19 Feb 2008 19:53:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BB33AD.1050005@FreeBSD.org> Date: Tue, 19 Feb 2008 20:53:17 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Valerio Daelli References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> In-Reply-To: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-performance@freebsd.org" , freebsd-questions Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "freebsd-performance@freebsd.org" List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 19:53:20 -0000 Valerio Daelli wrote: > Hi list > > we have a FreeBSD 7.0 NFS client (csup today, built world and kernel). > It mounts a Solaris 10 NFS share. > We have bad performance with 7.0 (3MB/s). > We have tried both UDP and TCP mounts, both sync and async. > This is our mount: > > nest.xx.xx:/data/export/hosts/bsd7.xx.xx/ /mnt/nest.xx.xx nfs > noatime,async,-i,rw,-T,-3 > > Both our server (7.0 and Solaris 10) are Gigabit Ethernet, both are HP > Proliant DL360 i386 (NIC bge0): > > --- > FreeBSD 7.0: > > [eldon@bsd7 ~]$ uname -a > FreeBSD bsd7.xx.xx 7.0-RC2 FreeBSD 7.0-RC2 #1: Mon Feb 18 17:46:46 CET > 2008 root@bsd7.xx.xx:/usr/obj/usr/src/sys/BSD7 i386 > > --- > This is our performance with iozone: > command line: > > iozone -+q 1 -i 0 -i 1 -n 2048 -g 2G -Raceb iozone.xls -f > /mnt/nest.xx.xx/iozone.bsd7/iozone.tmp > > FreeBSD 7: > > File stride size set to 17 * record size. > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 2048 1024 109883 101289 769058 779880 > 2048 2048 3812 3674 760479 767066 > 4096 1024 111156 106788 724692 728040 > 4096 2048 3336 2241 157132 733417 > 4096 4096 2829 3364 699351 699807 > > > As you can see, while with record length less than 1024KB the speed is > 'fast', with record of 2048 or more (I've tried with record much > bigger) we get only > 3 MB/s. > Is this a known issue? If you need more details please contact me, I > am willing to do more tests to risolve this problem. Can you characterize what is different about the NFS traffic when FreeBSD and Solaris are the clients? Does other network traffic to the server perform well? 2048 bytes records are > the 1500 byte MTU, so you will be invoking packet fragmentation and reassembly. Maybe you are getting packet loss for some reason. What does netstat say about interface errors on the bge, and for the protocol layers? Follow-ups set to performance@ Kris From owner-freebsd-performance@FreeBSD.ORG Tue Feb 19 22:02:46 2008 Return-Path: Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D80D16A421; Tue, 19 Feb 2008 22:02:46 +0000 (UTC) (envelope-from bbump@rsts.org) Received: from mail.rsts.org (host-82-161-107-208.midco.net [208.107.161.82]) by mx1.freebsd.org (Postfix) with ESMTP id 1472513C458; Tue, 19 Feb 2008 22:02:45 +0000 (UTC) (envelope-from bbump@rsts.org) Received: from mail.rsts.org (localhost [127.0.0.1]) by mail.rsts.org (8.13.6/8.12.11) with ESMTP id m1JM2iZg096787; Tue, 19 Feb 2008 15:02:44 -0700 (MST) (envelope-from bbump@rsts.org) Received: from localhost (bbump@localhost) by mail.rsts.org (8.13.6/8.12.11/Submit) with ESMTP id m1JM2iQb096784; Tue, 19 Feb 2008 15:02:44 -0700 (MST) (envelope-from bbump@rsts.org) X-Authentication-Warning: mail.rsts.org: bbump owned process doing -bs Date: Tue, 19 Feb 2008 15:02:44 -0700 (MST) From: Brett Bump To: Kris Kennaway In-Reply-To: <47B5F7BF.9050608@FreeBSD.org> Message-ID: <20080219145105.C96725@mail.rsts.org> References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-performance@FreeBSD.org, Mike Tancsa Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 22:02:46 -0000 Oops! ../../../ufs/ufs/ufs_quota.c: In function `chkdq': ../../../ufs/ufs/ufs_quota.c:168: error: `do_check' undeclared (first use in this function) ../../../ufs/ufs/ufs_quota.c:168: error: (Each undeclared identifier is reported only once ../../../ufs/ufs/ufs_quota.c:168: error: for each function it appears in.) ../../../ufs/ufs/ufs_quota.c:174: error: `warn' undeclared (first use in this function) ../../../ufs/ufs/ufs_quota.c:178: error: too many arguments to function `chkdqchg' ../../../ufs/ufs/ufs_quota.c: In function `chkdqchg': ../../../ufs/ufs/ufs_quota.c:230: error: number of arguments doesn't match prototype ../../../ufs/ufs/ufs_quota.c:75: error: prototype declaration ../../../ufs/ufs/ufs_quota.c: In function `chkiq': ../../../ufs/ufs/ufs_quota.c:330: error: too many arguments to function `chkiqchg' ../../../ufs/ufs/ufs_quota.c: In function `chkiqchg': ../../../ufs/ufs/ufs_quota.c:412: error: `warn' undeclared (first use in this function) ../../../ufs/ufs/ufs_quota.c: In function `quotaon': ../../../ufs/ufs/ufs_quota.c:522: warning: implicit declaration of function `quotaoff1' ../../../ufs/ufs/ufs_quota.c:522: warning: nested extern declaration of `quotaoff1' ../../../ufs/ufs/ufs_quota.c:583: warning: implicit declaration of function `quotaoff_inchange' ../../../ufs/ufs/ufs_quota.c:583: warning: nested extern declaration of `quotaoff_inchange' ../../../ufs/ufs/ufs_quota.c: At top level: ../../../ufs/ufs/ufs_quota.c:599: warning: function declaration isn't a prototype ../../../ufs/ufs/ufs_quota.c:599: warning: static declaration of 'quotaoff1' follows non-static declaration ../../../ufs/ufs/ufs_quota.c:522: warning: previous implicit declaration of 'quotaoff1' was here ../../../ufs/ufs/ufs_quota.c:680: warning: function declaration isn't a prototype ../../../ufs/ufs/ufs_quota.c: In function `dqget': ../../../ufs/ufs/ufs_quota.c:1130: error: `vfslocked' undeclared (first use in this function) ../../../ufs/ufs/ufs_quota.c:1134: error: `dqvplocked' undeclared (first use in this function) ../../../ufs/ufs/ufs_quota.c:1054: warning: unused variable `td' ../../../ufs/ufs/ufs_quota.c: At top level: ../../../ufs/ufs/ufs_quota.c:1022: warning: 'dqhashfind' defined but not used *** Error code 1 This was after applying the patch and disabling quotas. Brett On Fri, 15 Feb 2008, Kris Kennaway wrote: > Brett Bump wrote: > > > Possilby the weekend project will be setting up the backup with 6.3 to > > switch everything over to that. > > The first thing you need to do is either disable quotas or apply the > patch (maybe in conjunction with the 6.3 upgrade). That *is* the cause > of at least some of your performance problems. If any issues remain, > then we can revisit once you have done that. > > Kris > From owner-freebsd-performance@FreeBSD.ORG Tue Feb 19 22:09:48 2008 Return-Path: Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A41E016A421; Tue, 19 Feb 2008 22:09:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1F713C4EA; Tue, 19 Feb 2008 22:09:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BB53A5.30100@FreeBSD.org> Date: Tue, 19 Feb 2008 23:09:41 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Brett Bump , kib@FreeBSD.org References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> In-Reply-To: <20080219145105.C96725@mail.rsts.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@FreeBSD.org, Mike Tancsa Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 22:09:48 -0000 Brett Bump wrote: > Oops! > > ../../../ufs/ufs/ufs_quota.c: In function `chkdq': > ../../../ufs/ufs/ufs_quota.c:168: error: `do_check' undeclared (first use in this function) > ../../../ufs/ufs/ufs_quota.c:168: error: (Each undeclared identifier is reported only once > ../../../ufs/ufs/ufs_quota.c:168: error: for each function it appears in.) > ../../../ufs/ufs/ufs_quota.c:174: error: `warn' undeclared (first use in this function) > ../../../ufs/ufs/ufs_quota.c:178: error: too many arguments to function `chkdqchg' > ../../../ufs/ufs/ufs_quota.c: In function `chkdqchg': > ../../../ufs/ufs/ufs_quota.c:230: error: number of arguments doesn't match prototype > ../../../ufs/ufs/ufs_quota.c:75: error: prototype declaration > ../../../ufs/ufs/ufs_quota.c: In function `chkiq': > ../../../ufs/ufs/ufs_quota.c:330: error: too many arguments to function `chkiqchg' > ../../../ufs/ufs/ufs_quota.c: In function `chkiqchg': > ../../../ufs/ufs/ufs_quota.c:412: error: `warn' undeclared (first use in this function) > ../../../ufs/ufs/ufs_quota.c: In function `quotaon': > ../../../ufs/ufs/ufs_quota.c:522: warning: implicit declaration of function `quotaoff1' > ../../../ufs/ufs/ufs_quota.c:522: warning: nested extern declaration of `quotaoff1' > ../../../ufs/ufs/ufs_quota.c:583: warning: implicit declaration of function `quotaoff_inchange' > ../../../ufs/ufs/ufs_quota.c:583: warning: nested extern declaration of `quotaoff_inchange' > ../../../ufs/ufs/ufs_quota.c: At top level: > ../../../ufs/ufs/ufs_quota.c:599: warning: function declaration isn't a prototype > ../../../ufs/ufs/ufs_quota.c:599: warning: static declaration of 'quotaoff1' follows non-static declaration > ../../../ufs/ufs/ufs_quota.c:522: warning: previous implicit declaration of 'quotaoff1' was here > ../../../ufs/ufs/ufs_quota.c:680: warning: function declaration isn't a prototype > ../../../ufs/ufs/ufs_quota.c: In function `dqget': > ../../../ufs/ufs/ufs_quota.c:1130: error: `vfslocked' undeclared (first use in this function) > ../../../ufs/ufs/ufs_quota.c:1134: error: `dqvplocked' undeclared (first use in this function) > ../../../ufs/ufs/ufs_quota.c:1054: warning: unused variable `td' > ../../../ufs/ufs/ufs_quota.c: At top level: > ../../../ufs/ufs/ufs_quota.c:1022: warning: 'dqhashfind' defined but not used > *** Error code 1 > > This was after applying the patch and disabling quotas. If you can just disable quotas you don't need the mpsafe quota patch :) I guess the patch has become stale in the time since it was created. There were other changes committed to the 6.x quota support in recent months, so they probably invalidated it. Kris From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 03:30:08 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388BB16A405 for ; Wed, 20 Feb 2008 03:30:08 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by mx1.freebsd.org (Postfix) with ESMTP id 2510013C4D3 for ; Wed, 20 Feb 2008 03:30:08 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from user-64-9-233-225.googlewifi.com (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id E9DCF33C59; Tue, 19 Feb 2008 19:30:07 -0800 (PST) Date: Tue, 19 Feb 2008 20:30:07 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Attila Nagy In-Reply-To: <47BAE0B3.4090004@fsn.hu> References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 20 Feb 2008 04:09:50 +0000 Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 03:30:08 -0000 At Tue, 19 Feb 2008 14:59:15 +0100, Attila Nagy wrote: > > Okay, then please try this patch with '-n 1' (note: this patch doesn't > > contain the memory statistics hack via the HTTP interface, but I don't > > we don't need it for this test). [...] > (max-cache-size still 32M) Hmm, then the mutex locks dynamically generated are also irrelevant. I've also tried to reproduce the problem in a similar environment (BIND 9.5.0b1 with threads on FreeBSD 7.0RC1/AMD64, cache-only configuration, using a real query sample), unsuccessfully. One significant difference is that I disabled SMP in the kernel (it was very unstable with the SMP support for some unknown reason), but I doubt this is the key for the difference of the named behavior. BTW, is this reproduceable on FreeBSD 6.x? If so, then I'd like to see what happens if you specify some small value of datasize (e.g. 512MB) and have named abort when malloc() fails with the "X" _malloc_options. (This option doesn't seem to work for FreeBSD 7.x, at least at the moment). Some other questions: - can we see your named.conf? If you specify non-default configuration options, that might be the reason for, or related to, this problem. - does your named produce lot of log messages? If so, it might also be a reason (simply because it relies on standard libraries). Thanks, --- JINMEI, Tatuya From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 11:48:49 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBFAE16A406 for ; Wed, 20 Feb 2008 11:48:49 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id 927BF13C478 for ; Wed, 20 Feb 2008 11:48:49 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2104512wri.3 for ; Wed, 20 Feb 2008 03:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bxGDfQ0d79iN7KGSkZKEl3AKTsvxYgB2mBcIGjsNPqs=; b=rPxU/8jjN3HeFbrqTMknWc28pp7rVDTMSm8kWEmxgQ7BJQ3McVkRQ+tfwTPGbAI5O6CQb99KW4WuU6WN0XDvugMT9kAUDmAaxB7LBTVLjrRjcnRYU/UOYBHhMfJgd0yrAKF7ItJldfc7JuV93KdHoX9bL05XyUbhMYBu55jNs6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=x6CCjUp/9PIPfF/n/4UXWGZ6uV3vO2fllx4476APMd5pSvKrsgJRd7BrGORfsZUXBT2GZricEivJXYJH+cgHMQYrmZpRPMg33+ki1Tf8imRSF2FrGi1RgeKy6Q73oIlPd2ieOCw9/dBWOJcIx8nwV6joKHFyrqHfi1Iq6CvwX8w= Received: by 10.143.31.4 with SMTP id i4mr4347682wfj.87.1203506636334; Wed, 20 Feb 2008 03:23:56 -0800 (PST) Received: by 10.143.158.2 with HTTP; Wed, 20 Feb 2008 03:23:56 -0800 (PST) Message-ID: <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> Date: Wed, 20 Feb 2008 12:23:56 +0100 From: "Valerio Daelli" To: "freebsd-performance@freebsd.org" In-Reply-To: <47BB33AD.1050005@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 11:48:50 -0000 On Feb 19, 2008 8:53 PM, Kris Kennaway wrote: > > Valerio Daelli wrote: > > Hi list > > > > we have a FreeBSD 7.0 NFS client (csup today, built world and kernel). > > It mounts a Solaris 10 NFS share. > > We have bad performance with 7.0 (3MB/s). > > We have tried both UDP and TCP mounts, both sync and async. > > This is our mount: > > > > nest.xx.xx:/data/export/hosts/bsd7.xx.xx/ /mnt/nest.xx.xx nfs > > noatime,async,-i,rw,-T,-3 > > > > Both our server (7.0 and Solaris 10) are Gigabit Ethernet, both are HP > > Proliant DL360 i386 (NIC bge0): > > > > --- > > FreeBSD 7.0: > > > > [eldon@bsd7 ~]$ uname -a > > FreeBSD bsd7.xx.xx 7.0-RC2 FreeBSD 7.0-RC2 #1: Mon Feb 18 17:46:46 CET > > 2008 root@bsd7.xx.xx:/usr/obj/usr/src/sys/BSD7 i386 > > > > --- > > This is our performance with iozone: > > command line: > > > > iozone -+q 1 -i 0 -i 1 -n 2048 -g 2G -Raceb iozone.xls -f > > /mnt/nest.xx.xx/iozone.bsd7/iozone.tmp > > > > FreeBSD 7: > > > > File stride size set to 17 * record size. > > random > > random bkwd record stride > > KB reclen write rewrite read reread read > > write read rewrite read fwrite frewrite fread freread > > 2048 1024 109883 101289 769058 779880 > > 2048 2048 3812 3674 760479 767066 > > 4096 1024 111156 106788 724692 728040 > > 4096 2048 3336 2241 157132 733417 > > 4096 4096 2829 3364 699351 699807 > > > > > > As you can see, while with record length less than 1024KB the speed is > > 'fast', with record of 2048 or more (I've tried with record much > > bigger) we get only > > 3 MB/s. > > Is this a known issue? If you need more details please contact me, I > > am willing to do more tests to risolve this problem. > > Can you characterize what is different about the NFS traffic when > FreeBSD and Solaris are the clients? Does other network traffic to the > server perform well? 2048 bytes records are > the 1500 byte MTU, so you > will be invoking packet fragmentation and reassembly. Maybe you are > getting packet loss for some reason. What does netstat say about > interface errors on the bge, and for the protocol layers? > > Follow-ups set to performance@ > > Kris > Hi thanks for responding. I did a couple of test on 7.0, and I've not seen error on interfaces. Attached are netstat -s ad netstat -i. TCP mount --- root@bsd7:~ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bge0 1500 00:0b:cd:37:45:e8 45444 0 110188 0 0 bge0 1500 xx.xx.xx.xx bsd7 45427 - 110183 - - ---tcp: 1536 packets sent 396 data packets (68516 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 1021 ack-only packets (6 delayed) 0 URG only packets 0 window probe packets 101 window update packets 18 control packets 2555 packets received 413 acks (for 68487 bytes) 1 duplicate ack 0 acks for unsent data 2173 packets (763594 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 7 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 10 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 11 connections established (including accepts) 10 connections closed (including 1 drop) 7 connections updated cached RTT on close 7 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 413 segments updated rtt (of 358 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 2122 correct data packet header predictions 1 syncache entrie added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow [...] ip: 99904 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 61441 fragments received 0 fragments dropped (dup or out of space) 1 fragment dropped after timeout 10240 packets reassembled ok 48703 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 47693 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 34819 output datagrams fragmented 208914 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header [...] UDP mount --- root@bsd7:~ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bge0 1500 00:0b:cd:37:45:e8 63685 1 119978 0 0 bge0 1500 xx.xx.xx.xx bsd7 63628 - 119973 - - --- udp: 25880 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 7 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 25873 delivered 25882 datagrams output 0 times multicast source filter matched [...] ip: 62379 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 41473 fragments received 0 fragments dropped (dup or out of space) 1 fragment dropped after timeout 6912 packets reassembled ok 27818 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 27056 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 18438 output datagrams fragmented 110628 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header [...] Then I tried with different versions of FreeBSD and I discovered that: -FreeBSD 6.2-p3 has good performance with reclen 2048 and bad with 4096 and 8192: --- root@litio:~ uname -a FreeBSD litio.xx.xx 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #1: Thu Mar 15 14:52:08 CET 2007 root@litio.xx.xx:/usr/obj/usr/src/sys/LITIO amd64 TCP KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 2048 1024 90041 97352 82001 1019428 2048 2048 87030 88329 1009366 1053046 4096 1024 96139 95218 74186 1032306 4096 2048 103038 99700 79950 1003190 4096 4096 2897 3354 970821 522038 8192 1024 97978 100020 80681 946699 8192 2048 95260 104290 82395 1032127 8192 4096 3300 3169 149505 860882 8192 8192 3371 3090 998300 1012987 16384 1024 100072 98446 80503 962737 16384 2048 99360 105249 80983 924453 16384 4096 3162 3173 106750 936178 16384 8192 3233 3223 150394 998913 16384 16384 3250 3316 955004 944153 UDP similar -FreeBSD 6.2-p4 and 6.2-p6 has the same performance as 7.0: --- root@xtl:~ uname -a FreeBSD xtl.xx.xx 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #0: Wed Jul 25 14:32:07 CEST 2007 root@xtl.xx.xx:/usr/obj/usr/src/sys/XTL i386 TCP random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 2048 1024 15544 14560 846597 841044 2048 2048 2769 2649 852225 851211 4096 1024 17366 16851 833229 835417 4096 2048 2777 2457 49038 841226 4096 4096 2527 2813 847868 847492 root@rubidio:~ uname -a FreeBSD rubidio.xx.xx 6.2-RELEASE-p4 FreeBSD 6.2-RELEASE-p4 #0: Tue May 8 11:24:10 CEST 2007 root@rubidio.xx.xx:/usr/obj/usr/src/sys/PROXYCARP1 amd64 TCP random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 2048 1024 93010 89366 996997 970635 2048 2048 94740 90820 943347 946048 4096 2048 100036 94668 81065 927548 4096 4096 3274 3319 1074493 1047309 8192 2048 100990 98212 80574 1054050 8192 4096 3078 3071 149890 990428 8192 8192 3074 3055 992029 995391 --- Now I will try with a Solaris client and with rsync as protocol. Other suggestions? Bye Valerio Daelli From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 12:09:50 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B0F16A406 for ; Wed, 20 Feb 2008 12:09:50 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4388213C442 for ; Wed, 20 Feb 2008 12:09:49 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3133130pyb.10 for ; Wed, 20 Feb 2008 04:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=habmANXrZQZHpIey1WhFQMB8fNR6+OhJF8MEFgTyibM=; b=CLeiZm4pyexvTSIaNBIJRVcUa6wdQb2dpil0UFCI9S9bbYHfaR4ezXvo6V9hkhJnTKkGN95Je1UjuZ7H2iyFqSQFVOdUQ6HoTtcC+N+5CMAxAxUysuXLXan7V1aEXR0yEQFvruXKoDDSL5GrJsbDD5cSWdFNTSBGie4H0OQ1aVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fMRx94Rw1/eTcMuxW6ReN/PIh9DG04l41T8Re0nTE2esBbSlvJubi06oafux3gLPN/2eDN+OYJCtuqKVfKicdJrvhS0My3hCW6nhN8qkKnsyhH0UIl14fv2MeRYjGDsz5DGiFuXUlkrqTC+2XheVQJfRzwY356dyoqDHdjfq4R8= Received: by 10.65.23.7 with SMTP id a7mr16203169qbj.79.1203509389048; Wed, 20 Feb 2008 04:09:49 -0800 (PST) Received: by 10.65.83.4 with HTTP; Wed, 20 Feb 2008 04:09:48 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 13:09:48 +0100 From: "Claus Guttesen" To: "freebsd-performance@freebsd.org" In-Reply-To: <47BB33AD.1050005@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> Cc: freebsd-questions , Valerio Daelli Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 12:09:51 -0000 > > we have a FreeBSD 7.0 NFS client (csup today, built world and kernel). > > It mounts a Solaris 10 NFS share. > > We have bad performance with 7.0 (3MB/s). > > We have tried both UDP and TCP mounts, both sync and async. > > This is our mount: > > > > nest.xx.xx:/data/export/hosts/bsd7.xx.xx/ /mnt/nest.xx.xx nfs > > noatime,async,-i,rw,-T,-3 > > > > Both our server (7.0 and Solaris 10) are Gigabit Ethernet, both are HP > > Proliant DL360 i386 (NIC bge0): I have a solaris 9 nfs-server (on sparc) with som TB on HDS attached to it with two qlogic-hba's. These partitions are shared to our webservers via nfs, according to my mrtg-graph I get approx. 8 MB/s at peak. I can probably get more but the requirement is not there. With four-way-servers and FreeBSD 6.2 I had a read- and write-size of 8192. I ended up with this size by copying to and from the nfs-server until I didn't get "nfs server not responding; is alive again" message. Then I upgraded to FreeBSD 7.0 in October 2007 on a new eight-way-server I started to get "not responding; alive again" during load. So I decreased rw-size to the current 2048. When I decreased the size I also avoided another problem (by accident :-) ). When uploading images I sometimes saw ImageMagick's convert went into an (almost) infinite loop, comsuming 100 % cpu (on one core) until killed. Reducing the rw-size eliminated this issue. fstab-entry: my.nfs.server:/archive /archive nfs rw,nfsv3,-w=2048,-r=2048 0 0 I'm using udp-mounts, does not appear to change performance for my part. HTH. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 13:06:18 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA7F16A407 for ; Wed, 20 Feb 2008 13:06:18 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id DBFB513C4EC for ; Wed, 20 Feb 2008 13:06:17 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.tenantsolutions.net [209.163.168.124] (may be forged)) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id m1KD6DB9070254; Wed, 20 Feb 2008 07:06:16 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <47BC25C5.1000300@freebsd.org> Date: Wed, 20 Feb 2008 07:06:13 -0600 From: Eric Anderson User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Valerio Daelli References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> In-Reply-To: <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: "freebsd-performance@freebsd.org" Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:06:18 -0000 Valerio Daelli wrote: > On Feb 19, 2008 8:53 PM, Kris Kennaway wrote: >> Valerio Daelli wrote: >>> Hi list >>> >>> we have a FreeBSD 7.0 NFS client (csup today, built world and kernel). >>> It mounts a Solaris 10 NFS share. >>> We have bad performance with 7.0 (3MB/s). >>> We have tried both UDP and TCP mounts, both sync and async. >>> This is our mount: >>> >>> nest.xx.xx:/data/export/hosts/bsd7.xx.xx/ /mnt/nest.xx.xx nfs >>> noatime,async,-i,rw,-T,-3 >>> >>> Both our server (7.0 and Solaris 10) are Gigabit Ethernet, both are HP >>> Proliant DL360 i386 (NIC bge0): >>> >>> --- >>> FreeBSD 7.0: >>> >>> [eldon@bsd7 ~]$ uname -a >>> FreeBSD bsd7.xx.xx 7.0-RC2 FreeBSD 7.0-RC2 #1: Mon Feb 18 17:46:46 CET >>> 2008 root@bsd7.xx.xx:/usr/obj/usr/src/sys/BSD7 i386 >>> >>> --- >>> This is our performance with iozone: >>> command line: >>> >>> iozone -+q 1 -i 0 -i 1 -n 2048 -g 2G -Raceb iozone.xls -f >>> /mnt/nest.xx.xx/iozone.bsd7/iozone.tmp >>> >>> FreeBSD 7: >>> >>> File stride size set to 17 * record size. >>> random >>> random bkwd record stride >>> KB reclen write rewrite read reread read >>> write read rewrite read fwrite frewrite fread freread >>> 2048 1024 109883 101289 769058 779880 >>> 2048 2048 3812 3674 760479 767066 >>> 4096 1024 111156 106788 724692 728040 >>> 4096 2048 3336 2241 157132 733417 >>> 4096 4096 2829 3364 699351 699807 >>> >>> >>> As you can see, while with record length less than 1024KB the speed is >>> 'fast', with record of 2048 or more (I've tried with record much >>> bigger) we get only >>> 3 MB/s. >>> Is this a known issue? If you need more details please contact me, I >>> am willing to do more tests to risolve this problem. >> Can you characterize what is different about the NFS traffic when >> FreeBSD and Solaris are the clients? Does other network traffic to the >> server perform well? 2048 bytes records are > the 1500 byte MTU, so you >> will be invoking packet fragmentation and reassembly. Maybe you are >> getting packet loss for some reason. What does netstat say about >> interface errors on the bge, and for the protocol layers? >> >> Follow-ups set to performance@ >> >> Kris >> > > Hi > thanks for responding. I did a couple of test on 7.0, and I've not > seen error on interfaces. > Attached are netstat -s ad netstat -i. > > > TCP mount > --- > root@bsd7:~ netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > bge0 1500 00:0b:cd:37:45:e8 45444 0 110188 0 0 > bge0 1500 xx.xx.xx.xx bsd7 45427 - 110183 - - > ---tcp: > 1536 packets sent > 396 data packets (68516 bytes) > 0 data packets (0 bytes) retransmitted > 0 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 1021 ack-only packets (6 delayed) > 0 URG only packets > 0 window probe packets > 101 window update packets > 18 control packets > 2555 packets received > 413 acks (for 68487 bytes) > 1 duplicate ack > 0 acks for unsent data > 2173 packets (763594 bytes) received in-sequence > 0 completely duplicate packets (0 bytes) > 0 old duplicate packets > 0 packets with some dup. data (0 bytes duped) > 0 out-of-order packets (0 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 0 window update packets > 7 packets received after close > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 0 discarded due to memory problems > 10 connection requests > 1 connection accept > 0 bad connection attempts > 0 listen queue overflows > 0 ignored RSTs in the windows > 11 connections established (including accepts) > 10 connections closed (including 1 drop) > 7 connections updated cached RTT on close > 7 connections updated cached RTT variance on close > 0 connections updated cached ssthresh on close > 0 embryonic connections dropped > 413 segments updated rtt (of 358 attempts) > 0 retransmit timeouts > 0 connections dropped by rexmit timeout > 0 persist timeouts > 0 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 0 keepalive timeouts > 0 keepalive probes sent > 0 connections dropped by keepalive > 0 correct ACK header predictions > 2122 correct data packet header predictions > 1 syncache entrie added > 0 retransmitted > 0 dupsyn > 0 dropped > 1 completed > 0 bucket overflow > 0 cache overflow > 0 reset > 0 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > 1 cookie sent > 0 cookies received > 0 SACK recovery episodes > 0 segment rexmits in SACK recovery episodes > 0 byte rexmits in SACK recovery episodes > 0 SACK options (SACK blocks) received > 0 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > [...] > ip: > 99904 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 61441 fragments received > 0 fragments dropped (dup or out of space) > 1 fragment dropped after timeout > 10240 packets reassembled ok > 48703 packets for this host > 0 packets for unknown/unsupported protocol > 0 packets forwarded (0 packets fast forwarded) > 0 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 47693 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 34819 output datagrams fragmented > 208914 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > > [...] > > > UDP mount > --- > root@bsd7:~ netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > bge0 1500 00:0b:cd:37:45:e8 63685 1 119978 0 0 > bge0 1500 xx.xx.xx.xx bsd7 63628 - 119973 - - > --- > udp: > 25880 datagrams received > 0 with incomplete header > 0 with bad data length field > 0 with bad checksum > 0 with no checksum > 0 dropped due to no socket > 7 broadcast/multicast datagrams undelivered > 0 dropped due to full socket buffers > 0 not for hashed pcb > 25873 delivered > 25882 datagrams output > 0 times multicast source filter matched > [...] > ip: > 62379 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 41473 fragments received > 0 fragments dropped (dup or out of space) > 1 fragment dropped after timeout > 6912 packets reassembled ok > 27818 packets for this host > 0 packets for unknown/unsupported protocol > 0 packets forwarded (0 packets fast forwarded) > 0 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 27056 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 18438 output datagrams fragmented > 110628 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > [...] > > Then I tried with different versions of FreeBSD and I discovered that: > -FreeBSD 6.2-p3 has good performance with reclen 2048 and bad with > 4096 and 8192: > > --- > root@litio:~ uname -a > FreeBSD litio.xx.xx 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #1: Thu Mar > 15 14:52:08 CET 2007 root@litio.xx.xx:/usr/obj/usr/src/sys/LITIO > amd64 > > TCP > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 2048 1024 90041 97352 82001 1019428 > 2048 2048 87030 88329 1009366 1053046 > 4096 1024 96139 95218 74186 1032306 > 4096 2048 103038 99700 79950 1003190 > 4096 4096 2897 3354 970821 522038 > 8192 1024 97978 100020 80681 946699 > 8192 2048 95260 104290 82395 1032127 > 8192 4096 3300 3169 149505 860882 > 8192 8192 3371 3090 998300 1012987 > 16384 1024 100072 98446 80503 962737 > 16384 2048 99360 105249 80983 924453 > 16384 4096 3162 3173 106750 936178 > 16384 8192 3233 3223 150394 998913 > 16384 16384 3250 3316 955004 944153 > > UDP similar > > > -FreeBSD 6.2-p4 and 6.2-p6 has the same performance as 7.0: > --- > > root@xtl:~ uname -a > FreeBSD xtl.xx.xx 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #0: Wed Jul 25 > 14:32:07 CEST 2007 root@xtl.xx.xx:/usr/obj/usr/src/sys/XTL i386 > > TCP > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 2048 1024 15544 14560 846597 841044 > 2048 2048 2769 2649 852225 851211 > 4096 1024 17366 16851 833229 835417 > 4096 2048 2777 2457 49038 841226 > 4096 4096 2527 2813 847868 847492 > > > > > root@rubidio:~ uname -a > FreeBSD rubidio.xx.xx 6.2-RELEASE-p4 FreeBSD 6.2-RELEASE-p4 #0: Tue > May 8 11:24:10 CEST 2007 > root@rubidio.xx.xx:/usr/obj/usr/src/sys/PROXYCARP1 amd64 > > TCP > > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 2048 1024 93010 89366 996997 970635 > 2048 2048 94740 90820 943347 946048 > 4096 2048 100036 94668 81065 927548 > 4096 4096 3274 3319 1074493 1047309 > 8192 2048 100990 98212 80574 1054050 > 8192 4096 3078 3071 149890 990428 > 8192 8192 3074 3055 992029 995391 > > > > --- > Now I will try with a Solaris client and with rsync as protocol. > Other suggestions? > Bye > If possible, it might help a lot to send the output (or a snippet of it) or post it somewhere on the web, of a tshark output from the client. You might try UDP mounting the NFS export also, just to try it. Eric From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 13:08:31 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF0216A400 for ; Wed, 20 Feb 2008 13:08:31 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 2384113C458 for ; Wed, 20 Feb 2008 13:08:31 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.tenantsolutions.net [209.163.168.124] (may be forged)) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id m1KD8RIP070335; Wed, 20 Feb 2008 07:08:30 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <47BC264B.8010308@freebsd.org> Date: Wed, 20 Feb 2008 07:08:27 -0600 From: Eric Anderson User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Claus Guttesen References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: "freebsd-performance@freebsd.org" , freebsd-questions , Valerio Daelli Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:08:31 -0000 Claus Guttesen wrote: >>> we have a FreeBSD 7.0 NFS client (csup today, built world and kernel). >>> It mounts a Solaris 10 NFS share. >>> We have bad performance with 7.0 (3MB/s). >>> We have tried both UDP and TCP mounts, both sync and async. >>> This is our mount: >>> >>> nest.xx.xx:/data/export/hosts/bsd7.xx.xx/ /mnt/nest.xx.xx nfs >>> noatime,async,-i,rw,-T,-3 >>> >>> Both our server (7.0 and Solaris 10) are Gigabit Ethernet, both are HP >>> Proliant DL360 i386 (NIC bge0): > > I have a solaris 9 nfs-server (on sparc) with som TB on HDS attached > to it with two qlogic-hba's. These partitions are shared to our > webservers via nfs, according to my mrtg-graph I get approx. 8 MB/s at > peak. I can probably get more but the requirement is not there. > > With four-way-servers and FreeBSD 6.2 I had a read- and write-size of > 8192. I ended up with this size by copying to and from the nfs-server > until I didn't get "nfs server not responding; is alive again" > message. Then I upgraded to FreeBSD 7.0 in October 2007 on a new > eight-way-server I started to get "not responding; alive again" during > load. So I decreased rw-size to the current 2048. > > When I decreased the size I also avoided another problem (by accident > :-) ). When uploading images I sometimes saw ImageMagick's convert > went into an (almost) infinite loop, comsuming 100 % cpu (on one core) > until killed. Reducing the rw-size eliminated this issue. > > fstab-entry: > > my.nfs.server:/archive /archive nfs > rw,nfsv3,-w=2048,-r=2048 0 0 > > I'm using udp-mounts, does not appear to change performance for my part. > > HTH. If FreeBSD is your NFS server, you should increase the number of nfsd threads to help with the "not responding" error. I usually run one nfsd thread per active client. Eric From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 13:53:29 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C8E16A401 for ; Wed, 20 Feb 2008 13:53:29 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 29D8313C442 for ; Wed, 20 Feb 2008 13:53:28 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRpO2-0003bd-DL for freebsd-performance@freebsd.org; Wed, 20 Feb 2008 13:53:26 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2008 13:53:26 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2008 13:53:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Ivan Voras Date: Wed, 20 Feb 2008 14:55:52 +0100 Lines: 37 Message-ID: References: <20080214114759.R75215@mail.rsts.org> <20080214151614.7fa0c091.wmoran@collaborativefusion.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD25F2AFBA7C3B84C42844511" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: <20080214151614.7fa0c091.wmoran@collaborativefusion.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:53:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD25F2AFBA7C3B84C42844511 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bill Moran wrote: > In response to Brett Bump : >> I'm seeing signal 6's on apache and imapd (never happened before) >> network errors, serious response time errors and generally poor >> performance during peak activity (same box, same people). >=20 > IIRC, signal 6 is an indicator that you've compiled binaries that are > almost, but not quite compatible with your CPU. You probably mean signals 4 (SIGILL) or 10 (SIGBUS), rather than 6 (SIGABRT) :) I was getting a lot of SIGABRTs once, but that turned out to be due to PHP module order bogosity and linking mismatched threaded libraries into apache. --------------enigD25F2AFBA7C3B84C42844511 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHvDFoldnAQVacBcgRAgPYAKDc7dE1BJZi3gU6YioTWeWqUVWiOwCgnJYC 42LqA7zNIU8dS3/5uz4yKRA= =Ydq2 -----END PGP SIGNATURE----- --------------enigD25F2AFBA7C3B84C42844511-- From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 14:23:34 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17FA816A401 for ; Wed, 20 Feb 2008 14:23:34 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id A93BA13C447 for ; Wed, 20 Feb 2008 14:23:33 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 20 Feb 2008 09:23:32 -0500 id 00056448.47BC37E4.000106F4 Date: Wed, 20 Feb 2008 09:21:36 -0500 From: Bill Moran To: Ivan Voras Message-Id: <20080220092136.4dee013b.wmoran@collaborativefusion.com> In-Reply-To: References: <20080214114759.R75215@mail.rsts.org> <20080214151614.7fa0c091.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 14:23:34 -0000 In response to Ivan Voras : > Bill Moran wrote: > > In response to Brett Bump : > >> I'm seeing signal 6's on apache and imapd (never happened before) > >> network errors, serious response time errors and generally poor > >> performance during peak activity (same box, same people). > > > > IIRC, signal 6 is an indicator that you've compiled binaries that are > > almost, but not quite compatible with your CPU. > > You probably mean signals 4 (SIGILL) or 10 (SIGBUS), rather than 6 > (SIGABRT) :) > > I was getting a lot of SIGABRTs once, but that turned out to be due to > PHP module order bogosity and linking mismatched threaded libraries into > apache. You're quite likely correct. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 18:35:36 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA9016A401 for ; Wed, 20 Feb 2008 18:35:36 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id F015913C4F2 for ; Wed, 20 Feb 2008 18:35:35 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id EBDB122CB07D; Wed, 20 Feb 2008 10:35:35 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id D563228091; Wed, 20 Feb 2008 10:35:35 -0800 (PST) X-AuditID: 11807130-a8442bb0000028a7-e4-47bc72f70bea Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay11.apple.com (Apple SCV relay) with ESMTP id BDFCF28093; Wed, 20 Feb 2008 10:35:35 -0800 (PST) Message-Id: <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> From: Chuck Swiger To: Valerio Daelli In-Reply-To: <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 10:35:35 -0800 References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Cc: "freebsd-performance@freebsd.org" Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 18:35:36 -0000 Hi-- On Feb 20, 2008, at 3:23 AM, Valerio Daelli wrote: > 99904 total packets received [ ... ] > > 61441 fragments received [ ... ] > 34819 output datagrams fragmented > 208914 fragments created Take a look at the level of packet fragmentation you are encountering; yes, this is expected and things will work but there is extra latency added when the IP stack has to reassemble packets before the data can be delivered. Try setting the NFS rsize/wsize to 1024 or perhaps 1400 and see whether that improves performance. Or, if your switch and NICs support it, see whether you can get Gb Ethernet jumbo frames working so that you don't have to fragment for 2K or 4K data packets.... -- -Chuck From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 21:20:54 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C0416A406 for ; Wed, 20 Feb 2008 21:20:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6B63113C458 for ; Wed, 20 Feb 2008 21:20:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id BED5A1A4D7E; Wed, 20 Feb 2008 13:01:18 -0800 (PST) Date: Wed, 20 Feb 2008 13:01:18 -0800 From: Alfred Perlstein To: Chuck Swiger Message-ID: <20080220210118.GY99258@elvis.mu.org> References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-performance@freebsd.org" , Valerio Daelli Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 21:20:54 -0000 * Chuck Swiger [080220 10:35] wrote: > Hi-- > > On Feb 20, 2008, at 3:23 AM, Valerio Daelli wrote: > > 99904 total packets received > [ ... ] > > > > 61441 fragments received > > [ ... ] > > 34819 output datagrams fragmented > > 208914 fragments created > > Take a look at the level of packet fragmentation you are encountering; > yes, this is expected and things will work but there is extra latency > added when the IP stack has to reassemble packets before the data can > be delivered. Try setting the NFS rsize/wsize to 1024 or perhaps 1400 > and see whether that improves performance. > > Or, if your switch and NICs support it, see whether you can get Gb > Ethernet jumbo frames working so that you don't have to fragment for > 2K or 4K data packets.... TCP mounts do not have this problem. You can safely use 32k or higher sizes with TCP without fragmentation. -Alfred From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 21:30:14 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE28B16A402; Wed, 20 Feb 2008 21:30:14 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id C2A1E13C45E; Wed, 20 Feb 2008 21:30:14 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id C0C3722CFD76; Wed, 20 Feb 2008 13:30:14 -0800 (PST) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id AB8D228091; Wed, 20 Feb 2008 13:30:14 -0800 (PST) X-AuditID: 11807130-a7c41bb0000028a7-b4-47bc9be6ac6e Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay11.apple.com (Apple SCV relay) with ESMTP id 8D2902809C; Wed, 20 Feb 2008 13:30:14 -0800 (PST) Message-Id: From: Chuck Swiger To: Alfred Perlstein In-Reply-To: <20080220210118.GY99258@elvis.mu.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 13:30:13 -0800 References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> <20080220210118.GY99258@elvis.mu.org> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Cc: "freebsd-performance@freebsd.org" , Valerio Daelli Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 21:30:15 -0000 On Feb 20, 2008, at 1:01 PM, Alfred Perlstein wrote: >> Take a look at the level of packet fragmentation you are >> encountering; >> yes, this is expected and things will work but there is extra latency >> added when the IP stack has to reassemble packets before the data can >> be delivered. Try setting the NFS rsize/wsize to 1024 or perhaps >> 1400 >> and see whether that improves performance. >> >> Or, if your switch and NICs support it, see whether you can get Gb >> Ethernet jumbo frames working so that you don't have to fragment for >> 2K or 4K data packets.... > > TCP mounts do not have this problem. You can safely use > 32k or higher sizes with TCP without fragmentation. Oh, sure. But there is a bit more overhead with TCP transport than UDP-- for local (switched) networks, UDP generally seems to be a win...TCP seems to be a better choice over a VPN or some similar kind of WAN. -- -Chuck From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 21:42:49 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 737CE16A404; Wed, 20 Feb 2008 21:42:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AE6A513C459; Wed, 20 Feb 2008 21:42:47 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BC9ED5.1010505@FreeBSD.org> Date: Wed, 20 Feb 2008 22:42:45 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Chuck Swiger References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> <20080220210118.GY99258@elvis.mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-performance@freebsd.org" , Alfred Perlstein , Valerio Daelli Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 21:42:49 -0000 Chuck Swiger wrote: > On Feb 20, 2008, at 1:01 PM, Alfred Perlstein wrote: >>> Take a look at the level of packet fragmentation you are encountering; >>> yes, this is expected and things will work but there is extra latency >>> added when the IP stack has to reassemble packets before the data can >>> be delivered. Try setting the NFS rsize/wsize to 1024 or perhaps 1400 >>> and see whether that improves performance. >>> >>> Or, if your switch and NICs support it, see whether you can get Gb >>> Ethernet jumbo frames working so that you don't have to fragment for >>> 2K or 4K data packets.... >> >> TCP mounts do not have this problem. You can safely use >> 32k or higher sizes with TCP without fragmentation. > > Oh, sure. But there is a bit more overhead with TCP transport than > UDP-- for local (switched) networks, UDP generally seems to be a > win...TCP seems to be a better choice over a VPN or some similar kind of > WAN. Actually this is no longer true. At modern LAN speeds (e.g. gige) you can transmit packets fast enough that two things happen: 1) UDP socket buffer overruns are common, leading to packet loss. 2) the 16-bit sequence numbers wrap *much* faster than the IP fragment lifetime (30 seconds). These combine to cause data corruption when fragmented packets are dropped and then reassembled with a later transmission of the same sequence number. TCP mounts should be used whenever possible thesedays (I flipped the default mode in 8.0 the other day). Kris From owner-freebsd-performance@FreeBSD.ORG Wed Feb 20 21:51:04 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4260416A410 for ; Wed, 20 Feb 2008 21:51:04 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by mx1.freebsd.org (Postfix) with ESMTP id 16F2513C4D1 for ; Wed, 20 Feb 2008 21:51:04 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from user-64-9-237-172.googlewifi.com (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 14EC633C59; Wed, 20 Feb 2008 13:51:03 -0800 (PST) Date: Wed, 20 Feb 2008 13:51:02 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Attila Nagy In-Reply-To: References: <475B0F3E.5070100@fsn.hu> <479DFE74.8030004@fsn.hu> <479F02A7.9020607@fsn.hu> <47A614E9.4030501@fsn.hu> <47A77A13.6010802@fsn.hu> <47B1D2F4.5070304@fsn.hu> <47B2DD62.6020507@fsn.hu> <47BAE0B3.4090004@fsn.hu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 21 Feb 2008 00:32:32 +0000 Cc: freebsd-performance@freebsd.org, bind-users@isc.org Subject: Re: max-cache-size doesn't work with 9.5.0b1 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 21:51:04 -0000 At Tue, 19 Feb 2008 20:30:07 -0700, JINMEI Tatuya wrote: > BTW, is this reproduceable on FreeBSD 6.x? If so, then I'd like to > see what happens if you specify some small value of datasize > (e.g. 512MB) and have named abort when malloc() fails with the "X" > _malloc_options. (This option doesn't seem to work for FreeBSD 7.x, > at least at the moment). Okay, I've fond handier workaround (that should work for 7.X). Please try the following steps: - create a symbolic link from "/etc/malloc.conf" to "X": # ln -s X /etc/malloc.conf - start named with a moderate limitation of virtual memory size, e.g. # /usr/bin/limits -v 384m $path_to_named/named Then the named process will eventually abort itself with a core dump due to malloc failure. Please show us the stack trace at that point. Hopefully it will reveal the malloc call that keeps consuming memory. Notes: - of course, this is a very radical way of diagnosing; you need to keep watching the process because it's "guaranteed" to be aborted. - the VM size must be carefully chosen so that malloc failure won't happen due to normal named processing. I think 384MB is reasonable enough according to the statistics you provided so far, but I'm not 100% sure about that. - it's better to keep my latest patch to adb.c and to run named with '-n 1' so that the mutex_init in adb.c won't trigger the malloc failure. - the global symbolic link from /etc/make.conf affects other processes. So, if you're running a different process than named that can consume a lot of memory or can cause malloc failure, we should find an alternative approach (there are some, but they are more complicated so let's discuss those only when they are really necessary). Again, thanks for your cooperation. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 05:11:56 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C0516A402 for ; Thu, 21 Feb 2008 05:11:56 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E90DB13C448 for ; Thu, 21 Feb 2008 05:11:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C32F81A4D7E; Wed, 20 Feb 2008 21:11:55 -0800 (PST) Date: Wed, 20 Feb 2008 21:11:55 -0800 From: Alfred Perlstein To: Kris Kennaway Message-ID: <20080221051155.GE99258@elvis.mu.org> References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> <20080220210118.GY99258@elvis.mu.org> <47BC9ED5.1010505@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BC9ED5.1010505@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-performance@freebsd.org" , Valerio Daelli Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 05:11:56 -0000 * Kris Kennaway [080220 13:42] wrote: > Chuck Swiger wrote: > >On Feb 20, 2008, at 1:01 PM, Alfred Perlstein wrote: > >>>Take a look at the level of packet fragmentation you are encountering; > >>>yes, this is expected and things will work but there is extra latency > >>>added when the IP stack has to reassemble packets before the data can > >>>be delivered. Try setting the NFS rsize/wsize to 1024 or perhaps 1400 > >>>and see whether that improves performance. > >>> > >>>Or, if your switch and NICs support it, see whether you can get Gb > >>>Ethernet jumbo frames working so that you don't have to fragment for > >>>2K or 4K data packets.... > >> > >>TCP mounts do not have this problem. You can safely use > >>32k or higher sizes with TCP without fragmentation. > > > >Oh, sure. But there is a bit more overhead with TCP transport than > >UDP-- for local (switched) networks, UDP generally seems to be a > >win...TCP seems to be a better choice over a VPN or some similar kind of > >WAN. > > Actually this is no longer true. At modern LAN speeds (e.g. gige) you > can transmit packets fast enough that two things happen: > > 1) UDP socket buffer overruns are common, leading to packet loss. > > 2) the 16-bit sequence numbers wrap *much* faster than the IP fragment > lifetime (30 seconds). > > These combine to cause data corruption when fragmented packets are > dropped and then reassembled with a later transmission of the same > sequence number. > > TCP mounts should be used whenever possible thesedays (I flipped the > default mode in 8.0 the other day). Additionally with smaller read/write sizes you must generate more RPCs, for instance using a tcp read size of 32k will allow the client to generate a single NFS_READ request for that 32k, however a UDP mount at 1.2k will need to generate appoximately 26 requests and the server will have to service that many requests as well. -- - Alfred Perlstein From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 08:29:04 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28BEC16A400 for ; Thu, 21 Feb 2008 08:29:04 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id C2E6013C469 for ; Thu, 21 Feb 2008 08:29:03 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so4289475waf.3 for ; Thu, 21 Feb 2008 00:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cQhvxLsVOEQEB+8YoMEaaXu7zhNEe4r2p20W3j6Ddh8=; b=AyV/PuJsoDTwbn3pPZ1pKvZ/7pnod3EdcEF0AJCeg+HiWnCCf2b088ZuJFsYEq1YSrQFPA7dOmOMsrdoxHB40KxvrcjmM9NjoSCzxgKsxfLFm/D4CjorY5Enl8GJKACjMBEl81Y9H8SyX5jc+niOdAsOdSuZ6vPHwRDAFViau/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZPk6NZUoUr3WMfYVeqewPhRvrIrhopFXw4ZR0UEZdqTR0aju1KK+CQuApKnarfifQLv9doKZb7nkqi+QOFYcbBcHRmefSw0F25GRCSuETGF7nTadF497Le3+RrvRn1i8WT47QgLBXUDj60zQpECdUBM33o3Fto/NAQaB18qLBa4= Received: by 10.114.95.1 with SMTP id s1mr178849wab.99.1203582542852; Thu, 21 Feb 2008 00:29:02 -0800 (PST) Received: by 10.114.113.14 with HTTP; Thu, 21 Feb 2008 00:29:02 -0800 (PST) Message-ID: <27dbfc8c0802210029w2232baccp3679d70a8db90637@mail.gmail.com> Date: Thu, 21 Feb 2008 09:29:02 +0100 From: "Valerio Daelli" To: "freebsd-performance@freebsd.org" In-Reply-To: <47BC5325.8070504@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <47BC25C5.1000300@freebsd.org> <27dbfc8c0802200705k482152d4h1bf6e63de24edf59@mail.gmail.com> <47BC5325.8070504@freebsd.org> Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 08:29:04 -0000 > Can you post it somewhere for me to download and look at? I'm not sure > my mail server will take a 30MB attachment :) > > Eric > > Hi I have done a test with rsync. These are the results: root@bsd7:/var/rsync RSYNC_PASSWORD='xxx' time rsync -av rsync://backup@nest/data/FILE . receiving file list ... done FILE sent 126 bytes received 1048704154 bytes 25893932.84 bytes/sec total size is 1048576000 speedup is 1.00 39.56 real 6.70 user 5.48 sys root@bsd7:/var/rsync RSYNC_PASSWORD='xxx' time rsync -av FILE rsync://backup@nest/data/FILE1 building file list ... done FILE sent 1048704085 bytes received 38 bytes 83896329.84 bytes/sec total size is 1048576000 speedup is 1.00 12.64 real 5.31 user 3.79 sys As you can see they are much faster than NFS. Then I have done a test with a Solaris 10 client and a Solaris 10 server: --- SOLARIS root@max 17:00:34:~ /usr/local/bin/iozone -r 2m -+q 1 -i 0 -n 2048 -g 8m -Raceb iozone.xls -f /mnt/nest.ifom-ieo-campus.it/iozone.solaris/iozone.tmp random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 2048 2048 38507 38278 4096 2048 54309 63908 8192 2048 60082 69817 They are quite fast as well. Valerio From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 09:57:09 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A306E16A408 for ; Thu, 21 Feb 2008 09:57:09 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC53213C44B; Thu, 21 Feb 2008 09:57:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BD4AF0.2030201@FreeBSD.org> Date: Thu, 21 Feb 2008 10:57:04 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Valerio Daelli References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <47BC25C5.1000300@freebsd.org> <27dbfc8c0802200705k482152d4h1bf6e63de24edf59@mail.gmail.com> <47BC5325.8070504@freebsd.org> <27dbfc8c0802210029w2232baccp3679d70a8db90637@mail.gmail.com> In-Reply-To: <27dbfc8c0802210029w2232baccp3679d70a8db90637@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-performance@freebsd.org" Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 09:57:09 -0000 Valerio Daelli wrote: > As you can see they are much faster than NFS. > Then I have done a test with a Solaris 10 client and a Solaris 10 server: > > --- > SOLARIS > > root@max 17:00:34:~ /usr/local/bin/iozone -r 2m -+q 1 -i 0 -n 2048 -g > 8m -Raceb iozone.xls -f > /mnt/nest.ifom-ieo-campus.it/iozone.solaris/iozone.tmp > random > random bkwd record stride > KB reclen write rewrite read reread read > write read rewrite read fwrite frewrite fread freread > 2048 2048 38507 38278 > 4096 2048 54309 63908 > 8192 2048 60082 69817 > What NFS parameters? Kris From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 10:05:12 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577C816A400 for ; Thu, 21 Feb 2008 10:05:12 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.243]) by mx1.freebsd.org (Postfix) with ESMTP id 00BA813C45D for ; Thu, 21 Feb 2008 10:05:11 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: by hs-out-0708.google.com with SMTP id h53so2509371hsh.11 for ; Thu, 21 Feb 2008 02:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LwNzEIjEWj4ixTS41O18aVZBPlS67ctyRF75W/sKz78=; b=ETMk5u9yBc8JqLlbZ8kkfqE1vpotTh3SQvtTGpJhOkmFj0qUGnRzOMNji58T8lfgCFGRP1B3srilmxfZSpNj9CB74sSOKNecpabm6y2f0tDDKqTej9DV+yVujRIe0n54cx7xXaJUdqhw91TKA/gRyqieAb8mMvgwj0FZkliVwGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ea+4yPed+Ar+o3x1/KCvJx4kDuD1gsIeuoPRK+f3OK1WYyewomoyZ4Y5UHYQ/BwmF0XnIHdOgbqxOxfwlCSwJk0NxH/U7BkECBtyd/JoLcPILtaGjBQ+Ca8f9NRvaTSmsAbE8mOzQJauv4FzHnbE1CtH4iFtACuTJKLlyoX/uVU= Received: by 10.114.125.2 with SMTP id x2mr7100977wac.119.1203588310228; Thu, 21 Feb 2008 02:05:10 -0800 (PST) Received: by 10.114.113.14 with HTTP; Thu, 21 Feb 2008 02:05:10 -0800 (PST) Message-ID: <27dbfc8c0802210205w60a51884q789cd10642474ad9@mail.gmail.com> Date: Thu, 21 Feb 2008 11:05:10 +0100 From: "Valerio Daelli" To: "Kris Kennaway" , "freebsd-performance@freebsd.org" In-Reply-To: <47BD4AF0.2030201@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <47BC25C5.1000300@freebsd.org> <27dbfc8c0802200705k482152d4h1bf6e63de24edf59@mail.gmail.com> <47BC5325.8070504@freebsd.org> <27dbfc8c0802210029w2232baccp3679d70a8db90637@mail.gmail.com> <47BD4AF0.2030201@FreeBSD.org> Cc: Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 10:05:12 -0000 On Thu, Feb 21, 2008 at 10:57 AM, Kris Kennaway wrote: > Valerio Daelli wrote: > > > As you can see they are much faster than NFS. > > Then I have done a test with a Solaris 10 client and a Solaris 10 server: > > > > --- > > SOLARIS > > > > root@max 17:00:34:~ /usr/local/bin/iozone -r 2m -+q 1 -i 0 -n 2048 -g > > 8m -Raceb iozone.xls -f > > /mnt/nest.ifom-ieo-campus.it/iozone.solaris/iozone.tmp > > random > > random bkwd record stride > > KB reclen write rewrite read reread read > > write read rewrite read fwrite frewrite fread freread > > 2048 2048 38507 38278 > > 4096 2048 54309 63908 > > 8192 2048 60082 69817 > > > What NFS parameters? > > Kris > Sorry: NFS via TCP /mnt/nest.ifom-ieo-campus.it on nest.ifom-ieo-campus.it:/data/export/hosts/bsd7.ifom-ieo-campus.it/ remote/read/write/setuid/devices/rsize=32768/wsize=32768/xattr/dev=4700003 on Thu Feb 21 11:01:04 2008 From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 10:48:00 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17F616A403 for ; Thu, 21 Feb 2008 10:48:00 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECDD13C45A; Thu, 21 Feb 2008 10:47:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BD56DC.5080305@FreeBSD.org> Date: Thu, 21 Feb 2008 11:47:56 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Valerio Daelli References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <47BC25C5.1000300@freebsd.org> <27dbfc8c0802200705k482152d4h1bf6e63de24edf59@mail.gmail.com> <47BC5325.8070504@freebsd.org> <27dbfc8c0802210029w2232baccp3679d70a8db90637@mail.gmail.com> <47BD4AF0.2030201@FreeBSD.org> <27dbfc8c0802210205w60a51884q789cd10642474ad9@mail.gmail.com> In-Reply-To: <27dbfc8c0802210205w60a51884q789cd10642474ad9@mail.gmail.com> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-performance@freebsd.org" Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 10:48:00 -0000 Valerio Daelli wrote: > On Thu, Feb 21, 2008 at 10:57 AM, Kris Kennaway wrote: >> Valerio Daelli wrote: >> >> > As you can see they are much faster than NFS. >> > Then I have done a test with a Solaris 10 client and a Solaris 10 server: >> > >> > --- >> > SOLARIS >> > >> > root@max 17:00:34:~ /usr/local/bin/iozone -r 2m -+q 1 -i 0 -n 2048 -g >> > 8m -Raceb iozone.xls -f >> > /mnt/nest.ifom-ieo-campus.it/iozone.solaris/iozone.tmp >> > random >> > random bkwd record stride >> > KB reclen write rewrite read reread read >> > write read rewrite read fwrite frewrite fread freread >> > 2048 2048 38507 38278 >> > 4096 2048 54309 63908 >> > 8192 2048 60082 69817 >> > >> What NFS parameters? >> >> Kris >> > > Sorry: > > NFS via TCP > /mnt/nest.ifom-ieo-campus.it on > nest.ifom-ieo-campus.it:/data/export/hosts/bsd7.ifom-ieo-campus.it/ > remote/read/write/setuid/devices/rsize=32768/wsize=32768/xattr/dev=4700003 > on Thu Feb 21 11:01:04 2008 Thanks, and can you remind me what your FreeBSD performance numbers are with TCP + 32k rsize/wsize? Kris From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 11:19:32 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CCEE16A49E for ; Thu, 21 Feb 2008 11:19:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 1F70D13C4DD for ; Thu, 21 Feb 2008 11:19:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com ([62.64.120.202]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JS9Sc-000Kzz-Lg for freebsd-performance@freebsd.org; Thu, 21 Feb 2008 13:19:30 +0200 Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JS8LI-000BSx-Ll; Thu, 21 Feb 2008 12:07:55 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1KHLtoq090914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 19:21:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m1KHMIBe076857; Wed, 20 Feb 2008 19:22:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1KHMG2F076836; Wed, 20 Feb 2008 19:22:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Feb 2008 19:22:16 +0200 From: Kostik Belousov To: Brett Bump Message-ID: <20080220172216.GM57756@deviant.kiev.zoral.com.ua> References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PZF5AtDGY1pYDA8B" Content-Disposition: inline In-Reply-To: <20080219145105.C96725@mail.rsts.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 8a658898c353158d5b622bcbe36a9e12 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2271 [Feb 20 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-Delayed: more then 1h on anti-4.kiev.sovam.com Cc: Kris Kennaway , freebsd-performance@freebsd.org, Mike Tancsa Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 11:19:32 -0000 --PZF5AtDGY1pYDA8B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2008 at 03:02:44PM -0700, Brett Bump wrote: >=20 > Oops! >=20 > ../../../ufs/ufs/ufs_quota.c: In function `chkdq': > ../../../ufs/ufs/ufs_quota.c:168: error: `do_check' undeclared (first use= in this function) > ../../../ufs/ufs/ufs_quota.c:168: error: (Each undeclared identifier is r= eported only once > ../../../ufs/ufs/ufs_quota.c:168: error: for each function it appears in.) > ../../../ufs/ufs/ufs_quota.c:174: error: `warn' undeclared (first use in = this function) > ../../../ufs/ufs/ufs_quota.c:178: error: too many arguments to function `= chkdqchg' > ../../../ufs/ufs/ufs_quota.c: In function `chkdqchg': > ../../../ufs/ufs/ufs_quota.c:230: error: number of arguments doesn't matc= h prototype > ../../../ufs/ufs/ufs_quota.c:75: error: prototype declaration > ../../../ufs/ufs/ufs_quota.c: In function `chkiq': > ../../../ufs/ufs/ufs_quota.c:330: error: too many arguments to function `= chkiqchg' > ../../../ufs/ufs/ufs_quota.c: In function `chkiqchg': > ../../../ufs/ufs/ufs_quota.c:412: error: `warn' undeclared (first use in = this function) > ../../../ufs/ufs/ufs_quota.c: In function `quotaon': > ../../../ufs/ufs/ufs_quota.c:522: warning: implicit declaration of functi= on `quotaoff1' > ../../../ufs/ufs/ufs_quota.c:522: warning: nested extern declaration of `= quotaoff1' > ../../../ufs/ufs/ufs_quota.c:583: warning: implicit declaration of functi= on `quotaoff_inchange' > ../../../ufs/ufs/ufs_quota.c:583: warning: nested extern declaration of `= quotaoff_inchange' > ../../../ufs/ufs/ufs_quota.c: At top level: > ../../../ufs/ufs/ufs_quota.c:599: warning: function declaration isn't a p= rototype > ../../../ufs/ufs/ufs_quota.c:599: warning: static declaration of 'quotaof= f1' follows non-static declaration > ../../../ufs/ufs/ufs_quota.c:522: warning: previous implicit declaration = of 'quotaoff1' was here > ../../../ufs/ufs/ufs_quota.c:680: warning: function declaration isn't a p= rototype > ../../../ufs/ufs/ufs_quota.c: In function `dqget': > ../../../ufs/ufs/ufs_quota.c:1130: error: `vfslocked' undeclared (first u= se in this function) > ../../../ufs/ufs/ufs_quota.c:1134: error: `dqvplocked' undeclared (first = use in this function) > ../../../ufs/ufs/ufs_quota.c:1054: warning: unused variable `td' > ../../../ufs/ufs/ufs_quota.c: At top level: > ../../../ufs/ufs/ufs_quota.c:1022: warning: 'dqhashfind' defined but not = used > *** Error code 1 >=20 > This was after applying the patch and disabling quotas. I cannot reproduce it locally. With patch applied, it compiles both GENERIC and GENERIC with options QUOTA added just fine. Check for partially applied patch. --PZF5AtDGY1pYDA8B Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke8YcgACgkQC3+MBN1Mb4hIaQCfeupm7S6rtwu1EC6cHb8FHEoG 4ZUAnjvGg2JvSEf1+siuytpCY1V0KUus =ozPx -----END PGP SIGNATURE----- --PZF5AtDGY1pYDA8B-- From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 11:20:06 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D6916A400; Thu, 21 Feb 2008 11:20:06 +0000 (UTC) (envelope-from bbump@rsts.org) Received: from mail.rsts.org (host-82-161-107-208.midco.net [208.107.161.82]) by mx1.freebsd.org (Postfix) with ESMTP id 24A1A13C4E1; Thu, 21 Feb 2008 11:20:05 +0000 (UTC) (envelope-from bbump@rsts.org) Received: from mail.rsts.org (localhost [127.0.0.1]) by mail.rsts.org (8.13.6/8.12.11) with ESMTP id m1LBK4sk002821; Thu, 21 Feb 2008 04:20:04 -0700 (MST) (envelope-from bbump@rsts.org) Received: from localhost (bbump@localhost) by mail.rsts.org (8.13.6/8.12.11/Submit) with ESMTP id m1LBK4LZ002818; Thu, 21 Feb 2008 04:20:04 -0700 (MST) (envelope-from bbump@rsts.org) X-Authentication-Warning: mail.rsts.org: bbump owned process doing -bs Date: Thu, 21 Feb 2008 04:20:04 -0700 (MST) From: Brett Bump To: Kostik Belousov In-Reply-To: <20080220172216.GM57756@deviant.kiev.zoral.com.ua> Message-ID: <20080221030314.Q2297@mail.rsts.org> References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kris Kennaway , freebsd-performance@freebsd.org, Mike Tancsa Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 11:20:06 -0000 On Wed, 20 Feb 2008, Kostik Belousov wrote: > I cannot reproduce it locally. With patch applied, it compiles both > GENERIC and GENERIC with options QUOTA added just fine. > > Check for partially applied patch. > Thanks Kostik. You can double check me on sizes, but it would appear that all files in the patch were touched, and I double checked my sources with: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are identical (this is still a fresh install, I did not run cvsup). -bash-2.05b$ grep RCS quotas-RELENG_6-20070623-1455.patch RCS file: /usr/local/arch/ncvs/src/sys/kern/vfs_syscalls.c,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/quota.h,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_inode.c,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_lookup.c,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_quota.c,v RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v -bash-2.05b$ cd /usr/src/sys -bash-2.05b$ ls -l kern/vfs_syscalls.c ufs/ffs/ffs_softdep.c ufs/ffs/ffs_vfsops.c ufs/ufs/quota.h ufs/ufs/ufs_inode.c ufs/ufs/ufs_lookup.c ufs/ufs/ufs_quota.c ufs/ufs/ufs_vnops.c -rw-r--r-- 1 root wheel 109156 Feb 19 14:32 kern/vfs_syscalls.c -rw-r--r-- 1 root wheel 186964 Feb 19 14:33 ufs/ffs/ffs_softdep.c -rw-r--r-- 1 root wheel 47272 Feb 19 14:33 ufs/ffs/ffs_vfsops.c -rw-r--r-- 1 root wheel 7923 Feb 19 14:34 ufs/ufs/quota.h -rw-r--r-- 1 root wheel 6364 Feb 19 14:34 ufs/ufs/ufs_inode.c -rw-r--r-- 1 root wheel 36499 Feb 19 14:34 ufs/ufs/ufs_lookup.c -rw-r--r-- 1 root wheel 31107 Feb 19 14:34 ufs/ufs/ufs_quota.c -rw-r--r-- 1 root wheel 62960 Feb 19 14:34 ufs/ufs/ufs_vnops.c The only patch barking a problem would appear to be ufs_quota.c: -------------------------- |Index: ufs/ufs/ufs_quota.c |=================================================================== |RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_quota.c,v |retrieving revision 1.74.2.6 |diff -u -r1.74.2.6 ufs_quota.c |--- ufs/ufs/ufs_quota.c 1 Feb 2007 04:45:43 -0000 1.74.2.6 |+++ ufs/ufs/ufs_quota.c 25 Jun 2007 14:52:48 -0000 -------------------------- Patching file ufs_quota.c using Plan A... Hunk #1 failed at 72. Hunk #2 succeeded at 114 (offset -5 lines). Hunk #3 succeeded at 122 (offset -5 lines). Hunk #4 failed at 142. Hunk #5 succeeded at 158 (offset -13 lines). Hunk #6 succeeded at 175 (offset -5 lines). Hunk #7 succeeded at 214 (offset -13 lines). Hunk #8 succeeded at 236 (offset -5 lines). Hunk #9 succeeded at 244 (offset -13 lines). Hunk #10 succeeded at 271 (offset -5 lines). Hunk #11 succeeded at 296 (offset -13 lines). Hunk #12 succeeded at 317 with fuzz 1 (offset -4 lines). Hunk #13 succeeded at 318 (offset -13 lines). Hunk #14 succeeded at 376 (offset -4 lines). Hunk #15 failed at 390. Hunk #16 succeeded at 397 (offset -13 lines). Hunk #17 succeeded at 425 (offset -4 lines). Hunk #18 failed at 471. Hunk #19 succeeded at 490 (offset -19 lines). Hunk #20 succeeded at 567 (offset -4 lines). Hunk #21 succeeded at 589 (offset -19 lines). Hunk #22 succeeded at 631 (offset -4 lines). Hunk #23 succeeded at 660 (offset -19 lines). Hunk #24 succeeded at 791 (offset -4 lines). Hunk #25 succeeded at 809 (offset -19 lines). Hunk #26 succeeded at 864 (offset -4 lines). Hunk #27 succeeded at 878 (offset -19 lines). Hunk #28 succeeded at 920 (offset -4 lines). Hunk #29 succeeded at 927 (offset -19 lines). Hunk #30 succeeded at 974 (offset -4 lines). Hunk #31 succeeded at 984 (offset -19 lines). Hunk #32 succeeded at 1018 (offset -4 lines). Hunk #33 succeeded at 1019 (offset -19 lines). Hunk #34 failed at 1063. Hunk #35 succeeded at 1197 (offset -9 lines). Hunk #36 succeeded at 1209 (offset -19 lines). Hunk #37 succeeded at 1261 (offset -9 lines). Hunk #38 succeeded at 1281 (offset -19 lines). Hunk #39 succeeded at 1323 (offset -9 lines). Hunk #40 succeeded at 1365 (offset -19 lines). Hunk #41 succeeded at 1410 (offset -9 lines). Hunk #42 succeeded at 1412 (offset -19 lines). 5 out of 42 hunks failed--saving rejects to ufs_quota.c.rej done The contents of ufs_quota.c.rej contain: -bash-2.05b$ cat ufs_quota.c.rej *************** *** 72,83 **** */ static char *quotatypes[] = INITQFNAMES; - static int chkdqchg(struct inode *, ufs2_daddr_t, struct ucred *, int); - static int chkiqchg(struct inode *, int, struct ucred *, int); static int dqget(struct vnode *, - u_long, struct ufsmount *, int, struct dquot **); static int dqsync(struct vnode *, struct dquot *); static void dqflush(struct vnode *); #ifdef DIAGNOSTIC static void dqref(struct dquot *); --- 72,85 ---- */ static char *quotatypes[] = INITQFNAMES; + static int chkdqchg(struct inode *, ufs2_daddr_t, struct ucred *, int, int *); + static int chkiqchg(struct inode *, int, struct ucred *, int, int *); static int dqget(struct vnode *, + u_long, struct ufsmount *, int, struct dquot **); static int dqsync(struct vnode *, struct dquot *); static void dqflush(struct vnode *); + static int quotaoff1(struct thread *td, struct mount *mp, int type); + static int quotaoff_inchange(struct thread *td, struct mount *mp, int type); #ifdef DIAGNOSTIC static void dqref(struct dquot *); *************** *** 142,148 **** struct dquot *dq; ufs2_daddr_t ncurblocks; struct vnode *vp = ITOV(ip); - int i, error; /* * Disk quotas must be turned off for system files. Currently --- 142,148 ---- struct dquot *dq; ufs2_daddr_t ncurblocks; struct vnode *vp = ITOV(ip); + int i, error, warn, do_check; /* * Disk quotas must be turned off for system files. Currently *************** *** 335,345 **** * Issue an error message if appropriate. */ static int - chkiqchg(ip, change, cred, type) struct inode *ip; int change; struct ucred *cred; int type; { struct dquot *dq = ip->i_dquot[type]; ino_t ncurinodes = dq->dq_curinodes + change; --- 390,401 ---- * Issue an error message if appropriate. */ static int + chkiqchg(ip, change, cred, type, warn) struct inode *ip; int change; struct ucred *cred; int type; + int *warn; { struct dquot *dq = ip->i_dquot[type]; ino_t ncurinodes = dq->dq_curinodes + change; *************** *** 411,425 **** */ if ((int)ip->i_uid < 0 || (int)ip->i_gid < 0) return; for (i = 0; i < MAXQUOTAS; i++) { if (ump->um_quotas[i] == NULLVP || (ump->um_qflags[i] & (QTF_OPENING|QTF_CLOSING))) continue; if (ip->i_dquot[i] == NODQUOT) { vprint("chkdquot: missing dquot", ITOV(ip)); panic("chkdquot: missing dquot"); } } } #endif --- 471,489 ---- */ if ((int)ip->i_uid < 0 || (int)ip->i_gid < 0) return; + + UFS_LOCK(ump); for (i = 0; i < MAXQUOTAS; i++) { if (ump->um_quotas[i] == NULLVP || (ump->um_qflags[i] & (QTF_OPENING|QTF_CLOSING))) continue; if (ip->i_dquot[i] == NODQUOT) { + UFS_UNLOCK(ump); vprint("chkdquot: missing dquot", ITOV(ip)); panic("chkdquot: missing dquot"); } } + UFS_UNLOCK(ump); } #endif *************** *** 851,905 **** struct dquot **dqp; { struct thread *td = curthread; /* XXX */ - struct dquot *dq; struct dqhash *dqh; struct vnode *dqvp; struct iovec aiov; struct uio auio; - int error; /* XXX: Disallow negative id values to prevent the * creation of 100GB+ quota data files. */ if ((int)id < 0) return (EINVAL); dqvp = ump->um_quotas[type]; if (dqvp == NULLVP || (ump->um_qflags[type] & QTF_CLOSING)) { *dqp = NODQUOT; return (EINVAL); } /* * Check the cache first. */ dqh = DQHASH(dqvp, id); - LIST_FOREACH(dq, dqh, dq_hash) { - if (dq->dq_id != id || - dq->dq_ump->um_quotas[dq->dq_type] != dqvp) - continue; /* - * Cache hit with no references. Take - * the structure off the free list. */ - if (dq->dq_cnt == 0) - TAILQ_REMOVE(&dqfreelist, dq, dq_freelist); - DQREF(dq); - *dqp = dq; - return (0); } /* - * Not in cache, allocate a new one. */ if (TAILQ_FIRST(&dqfreelist) == NODQUOT && numdquot < MAXQUOTAS * desiredvnodes) desireddquot += DQUOTINC; if (numdquot < desireddquot) { - dq = (struct dquot *)malloc(sizeof *dq, M_DQUOT, - M_WAITOK | M_ZERO); numdquot++; } else { if ((dq = TAILQ_FIRST(&dqfreelist)) == NULL) { tablefull("dquot"); *dqp = NODQUOT; return (EUSERS); } if (dq->dq_cnt || (dq->dq_flags & DQ_MOD)) --- 1063,1184 ---- struct dquot **dqp; { struct thread *td = curthread; /* XXX */ + struct dquot *dq, *dq1; struct dqhash *dqh; struct vnode *dqvp; struct iovec aiov; struct uio auio; + int vfslocked, dqvplocked, error; + + #ifdef DEBUG_VFS_LOCKS + if (vp != NULLVP) + ASSERT_VOP_ELOCKED(vp, "dqget"); + #endif + + if (vp != NULLVP && *dqp != NODQUOT) { + return (0); + } /* XXX: Disallow negative id values to prevent the * creation of 100GB+ quota data files. */ if ((int)id < 0) return (EINVAL); + + UFS_LOCK(ump); dqvp = ump->um_quotas[type]; if (dqvp == NULLVP || (ump->um_qflags[type] & QTF_CLOSING)) { *dqp = NODQUOT; + UFS_UNLOCK(ump); return (EINVAL); } + vref(dqvp); + UFS_UNLOCK(ump); + error = 0; + dqvplocked = 0; + /* * Check the cache first. */ dqh = DQHASH(dqvp, id); + DQH_LOCK(); + dq = dqhashfind(dqh, id, dqvp); + if (dq != NULL) { + DQH_UNLOCK(); + hfound: DQI_LOCK(dq); + DQI_WAIT(dq, PINOD+1, "dqget"); + DQI_UNLOCK(dq); + if (dq->dq_ump == NULL) { + dqrele(vp, dq); + dq = NODQUOT; + error = EIO; + } + *dqp = dq; + vfslocked = VFS_LOCK_GIANT(dqvp->v_mount); + if (dqvplocked) + vput(dqvp); + else + vrele(dqvp); + VFS_UNLOCK_GIANT(vfslocked); + return (error); + } + + /* + * Quota vnode lock is before DQ_LOCK. Acquire dqvp lock there + * since new dq will appear on the hash chain DQ_LOCKed. + */ + if (vp != dqvp) { + DQH_UNLOCK(); + vn_lock(dqvp, LK_SHARED | LK_RETRY, td); + dqvplocked = 1; + DQH_LOCK(); /* + * Recheck the cache after sleep for quota vnode lock. */ + dq = dqhashfind(dqh, id, dqvp); + if (dq != NULL) { + DQH_UNLOCK(); + goto hfound; + } } + /* + * Not in cache, allocate a new one or take it from the + * free list. */ if (TAILQ_FIRST(&dqfreelist) == NODQUOT && numdquot < MAXQUOTAS * desiredvnodes) desireddquot += DQUOTINC; if (numdquot < desireddquot) { numdquot++; + DQH_UNLOCK(); + dq1 = (struct dquot *)malloc(sizeof *dq, M_DQUOT, + M_WAITOK | M_ZERO); + mtx_init(&dq1->dq_lock, "dqlock", NULL, MTX_DEF); + DQH_LOCK(); + /* + * Recheck the cache after sleep for memory. + */ + dq = dqhashfind(dqh, id, dqvp); + if (dq != NULL) { + numdquot--; + DQH_UNLOCK(); + mtx_destroy(&dq1->dq_lock); + free(dq1, M_DQUOT); + goto hfound; + } + dq = dq1; } else { if ((dq = TAILQ_FIRST(&dqfreelist)) == NULL) { + DQH_UNLOCK(); tablefull("dquot"); *dqp = NODQUOT; + vfslocked = VFS_LOCK_GIANT(dqvp->v_mount); + if (dqvplocked) + vput(dqvp); + else + vrele(dqvp); + VFS_UNLOCK_GIANT(vfslocked); return (EUSERS); } if (dq->dq_cnt || (dq->dq_flags & DQ_MOD)) Brett From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 12:13:33 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC9316A401; Thu, 21 Feb 2008 12:13:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFFF13C45A; Thu, 21 Feb 2008 12:13:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSAIp-000Lce-1d; Thu, 21 Feb 2008 14:13:31 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1LCD0Mf020816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:13:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m1LCDNtN031995; Thu, 21 Feb 2008 14:13:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1LCDMnP031859; Thu, 21 Feb 2008 14:13:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Feb 2008 14:13:22 +0200 From: Kostik Belousov To: Brett Bump Message-ID: <20080221121322.GO57756@deviant.kiev.zoral.com.ua> References: <20080214114759.R75215@mail.rsts.org> <47B49A16.1080103@FreeBSD.org> <20080214131026.Y75492@mail.rsts.org> <200802151440.m1FEeGVr084431@lava.sentex.ca> <20080215085714.K79197@mail.rsts.org> <47B5F7BF.9050608@FreeBSD.org> <20080219145105.C96725@mail.rsts.org> <20080220172216.GM57756@deviant.kiev.zoral.com.ua> <20080221030314.Q2297@mail.rsts.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DtaVePVv+QmL/oEO" Content-Disposition: inline In-Reply-To: <20080221030314.Q2297@mail.rsts.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: bb9f355b5be917825c280d06cf0e20ab X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2272 [Feb 21 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Kris Kennaway , freebsd-performance@freebsd.org, Mike Tancsa Subject: Re: System perforamance 4.x vs. 5.x and 6.x X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 12:13:33 -0000 --DtaVePVv+QmL/oEO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 04:20:04AM -0700, Brett Bump wrote: >=20 > On Wed, 20 Feb 2008, Kostik Belousov wrote: >=20 > > I cannot reproduce it locally. With patch applied, it compiles both > > GENERIC and GENERIC with options QUOTA added just fine. > > > > Check for partially applied patch. > > >=20 > Thanks Kostik. You can double check me on sizes, but it would appear that > all files in the patch were touched, and I double checked my sources with: > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src which are The patch is against RELENG_6, not against RELENG_6_2. I see no point in backporting it to RELENG_6_2. BTW, I backported two fixes, one for another deadlock with snapshots and quotas, another for "ffs_blkfree: block already freed" panic and followed up fsck: softdep inconsistency error. New combined patch (against RELENG_6) is at http://people.freebsd.org/~kib/quotagiant/quotas-RELENG_6-20080221-1202.pat= ch --DtaVePVv+QmL/oEO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke9auIACgkQC3+MBN1Mb4i+NQCfW8eeEQ9yMqIkwSRxX5nkLL1/ KPoAn1Hhu+v2DLKgc2paXw5rRqkRWXgI =gruY -----END PGP SIGNATURE----- --DtaVePVv+QmL/oEO-- From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 14:10:06 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99BB416A4E1 for ; Thu, 21 Feb 2008 14:10:06 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3104213C45B for ; Thu, 21 Feb 2008 14:10:04 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JSC7e-0002gM-RA for freebsd-performance@freebsd.org; Thu, 21 Feb 2008 14:10:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 14:10:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 14:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: Vadim Goncharov Date: Thu, 21 Feb 2008 12:18:04 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 904 Message-ID: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: All User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: [curious] interface aliases changing performance X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:10:06 -0000 Hi! After looking at humotous quoting about a man trying to ban unused addresses in his network by putting 65535 ifcong_XXX_aliasYYY lines to rc.conf, I decided to check this performance issue on a 6.2-RELEASE (GENERIC) and compare it with Linux. Below are results from two machines. First, I've found that both FreeBSD and Linux clearly use linked-list insertion to tail of queue, because time was growing as O(N^2). Then, Linux deleted it slowly at first, then faster (is it using LIFO?..). But Linux with iproute2 was 6 times faster on addition (FreeBSD did it ONE HOUR!), and even more faster on deletion. Why?.. FreeBSD (addition only): $ cat /usr/local/etc/rc.d/evil_ifconfig.sh #!/bin/sh i=0 starttime=$(date +%s) while [ $i -lt 65534 ]; do ipa=$(($i % 256)) net=$(($i / 256)) /sbin/ifconfig re0 192.168.$net.$ipa/32 alias [ $ipa -eq 0 ] && echo $0: starting net $net @ $((`date +%s` - $starttime)) sec | tee -a /root/evil_ifconfig.log i=$(($i + 1)) done $ head -n 20 /var/run/dmesg.boot Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2813.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf47 Stepping = 7 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 1073676288 (1023 MB) avail memory = 1041485824 (993 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 $ cat /root/evil_ifconfig.log /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 0 @ 0 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 1 @ 6 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 2 @ 12 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 3 @ 17 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 4 @ 23 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 5 @ 29 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 6 @ 35 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 7 @ 42 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 8 @ 48 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 9 @ 54 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 10 @ 60 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 11 @ 67 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 12 @ 73 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 13 @ 80 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 14 @ 86 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 15 @ 93 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 16 @ 100 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 17 @ 106 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 18 @ 113 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 19 @ 120 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 20 @ 127 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 21 @ 135 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 22 @ 142 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 23 @ 149 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 24 @ 156 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 25 @ 164 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 26 @ 171 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 27 @ 179 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 28 @ 186 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 29 @ 194 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 30 @ 202 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 31 @ 209 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 32 @ 217 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 33 @ 225 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 34 @ 233 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 35 @ 241 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 36 @ 249 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 37 @ 257 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 38 @ 266 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 39 @ 274 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 40 @ 282 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 41 @ 291 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 42 @ 299 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 43 @ 308 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 44 @ 316 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 45 @ 325 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 46 @ 334 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 47 @ 343 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 48 @ 351 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 49 @ 360 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 50 @ 369 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 51 @ 378 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 52 @ 387 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 53 @ 397 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 54 @ 406 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 55 @ 415 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 56 @ 424 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 57 @ 434 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 58 @ 443 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 59 @ 453 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 60 @ 463 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 61 @ 472 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 62 @ 482 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 63 @ 492 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 64 @ 502 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 65 @ 512 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 66 @ 522 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 67 @ 532 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 68 @ 542 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 69 @ 552 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 70 @ 562 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 71 @ 572 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 72 @ 583 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 73 @ 593 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 74 @ 604 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 75 @ 614 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 76 @ 625 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 77 @ 636 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 78 @ 646 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 79 @ 657 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 80 @ 668 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 81 @ 679 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 82 @ 690 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 83 @ 701 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 84 @ 712 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 85 @ 724 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 86 @ 735 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 87 @ 746 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 88 @ 758 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 89 @ 769 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 90 @ 780 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 91 @ 792 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 92 @ 804 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 93 @ 815 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 94 @ 827 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 95 @ 839 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 96 @ 851 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 97 @ 863 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 98 @ 875 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 99 @ 887 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 100 @ 899 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 101 @ 911 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 102 @ 924 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 103 @ 936 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 104 @ 948 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 105 @ 961 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 106 @ 973 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 107 @ 986 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 108 @ 999 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 109 @ 1011 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 110 @ 1024 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 111 @ 1037 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 112 @ 1050 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 113 @ 1063 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 114 @ 1076 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 115 @ 1089 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 116 @ 1102 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 117 @ 1115 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 118 @ 1129 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 119 @ 1142 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 120 @ 1155 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 121 @ 1169 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 122 @ 1182 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 123 @ 1196 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 124 @ 1209 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 125 @ 1223 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 126 @ 1237 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 127 @ 1251 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 128 @ 1264 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 129 @ 1278 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 130 @ 1292 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 131 @ 1307 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 132 @ 1321 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 133 @ 1335 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 134 @ 1349 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 135 @ 1363 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 136 @ 1378 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 137 @ 1392 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 138 @ 1407 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 139 @ 1421 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 140 @ 1436 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 141 @ 1451 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 142 @ 1465 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 143 @ 1480 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 144 @ 1495 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 145 @ 1510 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 146 @ 1525 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 147 @ 1540 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 148 @ 1555 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 149 @ 1570 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 150 @ 1586 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 151 @ 1601 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 152 @ 1616 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 153 @ 1632 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 154 @ 1647 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 155 @ 1663 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 156 @ 1678 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 157 @ 1694 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 158 @ 1710 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 159 @ 1725 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 160 @ 1741 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 161 @ 1757 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 162 @ 1773 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 163 @ 1789 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 164 @ 1805 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 165 @ 1821 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 166 @ 1838 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 167 @ 1854 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 168 @ 1870 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 169 @ 1887 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 170 @ 1903 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 171 @ 1920 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 172 @ 1936 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 173 @ 1953 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 174 @ 1970 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 175 @ 1986 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 176 @ 2003 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 177 @ 2020 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 178 @ 2037 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 179 @ 2054 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 180 @ 2071 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 181 @ 2088 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 182 @ 2106 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 183 @ 2123 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 184 @ 2140 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 185 @ 2158 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 186 @ 2175 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 187 @ 2193 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 188 @ 2211 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 189 @ 2228 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 190 @ 2246 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 191 @ 2264 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 192 @ 2282 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 193 @ 2300 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 194 @ 2317 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 195 @ 2336 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 196 @ 2354 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 197 @ 2372 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 198 @ 2390 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 199 @ 2408 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 200 @ 2427 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 201 @ 2445 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 202 @ 2464 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 203 @ 2482 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 204 @ 2501 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 205 @ 2519 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 206 @ 2538 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 207 @ 2557 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 208 @ 2576 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 209 @ 2595 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 210 @ 2614 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 211 @ 2633 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 212 @ 2652 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 213 @ 2671 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 214 @ 2691 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 215 @ 2710 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 216 @ 2729 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 217 @ 2749 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 218 @ 2768 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 219 @ 2788 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 220 @ 2807 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 221 @ 2827 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 222 @ 2847 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 223 @ 2866 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 224 @ 2886 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 225 @ 2906 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 226 @ 2926 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 227 @ 2946 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 228 @ 2966 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 229 @ 2986 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 230 @ 3007 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 231 @ 3027 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 232 @ 3047 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 233 @ 3068 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 234 @ 3088 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 235 @ 3109 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 236 @ 3129 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 237 @ 3150 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 238 @ 3171 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 239 @ 3192 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 240 @ 3212 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 241 @ 3233 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 242 @ 3254 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 243 @ 3275 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 244 @ 3296 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 245 @ 3317 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 246 @ 3339 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 247 @ 3360 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 248 @ 3381 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 249 @ 3403 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 250 @ 3424 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 251 @ 3446 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 252 @ 3468 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 253 @ 3492 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 254 @ 3513 sec /usr/local/etc/rc.d/evil_ifconfig.sh: starting net 255 @ 3535 sec The same on Linux: $ cat /root/evil_ifconfig.sh #!/bin/sh i=0 starttime=$(date +%s) while [ $i -lt 65534 ]; do ipa=$(($i % 256)) net=$(($i / 256)) ip a a 172.18.$net.$ipa/32 dev eth0 [ $ipa -eq 0 ] && echo $0: starting net $net @ $((`date +%s` - $starttime)) sec | tee -a /root/evil_ifconfig.log i=$(($i + 1)) done $ cat /proc/cpuinfo # 4 processor machine, showing one node processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5150 @ 2.66GHz stepping : 6 cpu MHz : 2660.033 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 5328.25 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: $ free total used free shared buffers cached Mem: 8179404 513200 7666204 0 75896 190356 -/+ buffers/cache: 246948 7932456 Swap: 2104472 0 2104472 $ uname -a Linux node-7 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux $ cat /root/eveil_ifconfig.log ./evil_ifconfig.sh: starting net 0 @ 0 sec ./evil_ifconfig.sh: starting net 1 @ 0 sec ./evil_ifconfig.sh: starting net 2 @ 1 sec ./evil_ifconfig.sh: starting net 3 @ 1 sec ./evil_ifconfig.sh: starting net 4 @ 1 sec ./evil_ifconfig.sh: starting net 5 @ 1 sec ./evil_ifconfig.sh: starting net 6 @ 1 sec ./evil_ifconfig.sh: starting net 7 @ 2 sec ./evil_ifconfig.sh: starting net 8 @ 2 sec ./evil_ifconfig.sh: starting net 9 @ 2 sec ./evil_ifconfig.sh: starting net 10 @ 2 sec ./evil_ifconfig.sh: starting net 11 @ 3 sec ./evil_ifconfig.sh: starting net 12 @ 3 sec ./evil_ifconfig.sh: starting net 13 @ 3 sec ./evil_ifconfig.sh: starting net 14 @ 3 sec ./evil_ifconfig.sh: starting net 15 @ 3 sec ./evil_ifconfig.sh: starting net 16 @ 4 sec ./evil_ifconfig.sh: starting net 17 @ 4 sec ./evil_ifconfig.sh: starting net 18 @ 4 sec ./evil_ifconfig.sh: starting net 19 @ 5 sec ./evil_ifconfig.sh: starting net 20 @ 5 sec ./evil_ifconfig.sh: starting net 21 @ 5 sec ./evil_ifconfig.sh: starting net 22 @ 5 sec ./evil_ifconfig.sh: starting net 23 @ 6 sec ./evil_ifconfig.sh: starting net 24 @ 6 sec ./evil_ifconfig.sh: starting net 25 @ 6 sec ./evil_ifconfig.sh: starting net 26 @ 7 sec ./evil_ifconfig.sh: starting net 27 @ 7 sec ./evil_ifconfig.sh: starting net 28 @ 8 sec ./evil_ifconfig.sh: starting net 29 @ 8 sec ./evil_ifconfig.sh: starting net 30 @ 9 sec ./evil_ifconfig.sh: starting net 31 @ 9 sec ./evil_ifconfig.sh: starting net 32 @ 10 sec ./evil_ifconfig.sh: starting net 33 @ 10 sec ./evil_ifconfig.sh: starting net 34 @ 11 sec ./evil_ifconfig.sh: starting net 35 @ 11 sec ./evil_ifconfig.sh: starting net 36 @ 12 sec ./evil_ifconfig.sh: starting net 37 @ 13 sec ./evil_ifconfig.sh: starting net 38 @ 13 sec ./evil_ifconfig.sh: starting net 39 @ 14 sec ./evil_ifconfig.sh: starting net 40 @ 15 sec ./evil_ifconfig.sh: starting net 41 @ 15 sec ./evil_ifconfig.sh: starting net 42 @ 16 sec ./evil_ifconfig.sh: starting net 43 @ 17 sec ./evil_ifconfig.sh: starting net 44 @ 18 sec ./evil_ifconfig.sh: starting net 45 @ 19 sec ./evil_ifconfig.sh: starting net 46 @ 19 sec ./evil_ifconfig.sh: starting net 47 @ 20 sec ./evil_ifconfig.sh: starting net 48 @ 21 sec ./evil_ifconfig.sh: starting net 49 @ 22 sec ./evil_ifconfig.sh: starting net 50 @ 23 sec ./evil_ifconfig.sh: starting net 51 @ 24 sec ./evil_ifconfig.sh: starting net 52 @ 25 sec ./evil_ifconfig.sh: starting net 53 @ 26 sec ./evil_ifconfig.sh: starting net 54 @ 27 sec ./evil_ifconfig.sh: starting net 55 @ 28 sec ./evil_ifconfig.sh: starting net 56 @ 29 sec ./evil_ifconfig.sh: starting net 57 @ 30 sec ./evil_ifconfig.sh: starting net 58 @ 31 sec ./evil_ifconfig.sh: starting net 59 @ 33 sec ./evil_ifconfig.sh: starting net 60 @ 34 sec ./evil_ifconfig.sh: starting net 61 @ 35 sec ./evil_ifconfig.sh: starting net 62 @ 36 sec ./evil_ifconfig.sh: starting net 63 @ 37 sec ./evil_ifconfig.sh: starting net 64 @ 39 sec ./evil_ifconfig.sh: starting net 65 @ 40 sec ./evil_ifconfig.sh: starting net 66 @ 41 sec ./evil_ifconfig.sh: starting net 67 @ 43 sec ./evil_ifconfig.sh: starting net 68 @ 44 sec ./evil_ifconfig.sh: starting net 69 @ 45 sec ./evil_ifconfig.sh: starting net 70 @ 47 sec ./evil_ifconfig.sh: starting net 71 @ 48 sec ./evil_ifconfig.sh: starting net 72 @ 49 sec ./evil_ifconfig.sh: starting net 73 @ 51 sec ./evil_ifconfig.sh: starting net 74 @ 52 sec ./evil_ifconfig.sh: starting net 75 @ 54 sec ./evil_ifconfig.sh: starting net 76 @ 55 sec ./evil_ifconfig.sh: starting net 77 @ 57 sec ./evil_ifconfig.sh: starting net 78 @ 58 sec ./evil_ifconfig.sh: starting net 79 @ 60 sec ./evil_ifconfig.sh: starting net 80 @ 62 sec ./evil_ifconfig.sh: starting net 81 @ 63 sec ./evil_ifconfig.sh: starting net 82 @ 65 sec ./evil_ifconfig.sh: starting net 83 @ 66 sec ./evil_ifconfig.sh: starting net 84 @ 68 sec ./evil_ifconfig.sh: starting net 85 @ 70 sec ./evil_ifconfig.sh: starting net 86 @ 71 sec ./evil_ifconfig.sh: starting net 87 @ 73 sec ./evil_ifconfig.sh: starting net 88 @ 75 sec ./evil_ifconfig.sh: starting net 89 @ 77 sec ./evil_ifconfig.sh: starting net 90 @ 78 sec ./evil_ifconfig.sh: starting net 91 @ 80 sec ./evil_ifconfig.sh: starting net 92 @ 82 sec ./evil_ifconfig.sh: starting net 93 @ 84 sec ./evil_ifconfig.sh: starting net 94 @ 86 sec ./evil_ifconfig.sh: starting net 95 @ 88 sec ./evil_ifconfig.sh: starting net 96 @ 89 sec ./evil_ifconfig.sh: starting net 97 @ 91 sec ./evil_ifconfig.sh: starting net 98 @ 93 sec ./evil_ifconfig.sh: starting net 99 @ 95 sec ./evil_ifconfig.sh: starting net 100 @ 97 sec ./evil_ifconfig.sh: starting net 101 @ 99 sec ./evil_ifconfig.sh: starting net 102 @ 101 sec ./evil_ifconfig.sh: starting net 103 @ 103 sec ./evil_ifconfig.sh: starting net 104 @ 105 sec ./evil_ifconfig.sh: starting net 105 @ 107 sec ./evil_ifconfig.sh: starting net 106 @ 109 sec ./evil_ifconfig.sh: starting net 107 @ 111 sec ./evil_ifconfig.sh: starting net 108 @ 113 sec ./evil_ifconfig.sh: starting net 109 @ 116 sec ./evil_ifconfig.sh: starting net 110 @ 118 sec ./evil_ifconfig.sh: starting net 111 @ 120 sec ./evil_ifconfig.sh: starting net 112 @ 122 sec ./evil_ifconfig.sh: starting net 113 @ 124 sec ./evil_ifconfig.sh: starting net 114 @ 126 sec ./evil_ifconfig.sh: starting net 115 @ 129 sec ./evil_ifconfig.sh: starting net 116 @ 131 sec ./evil_ifconfig.sh: starting net 117 @ 133 sec ./evil_ifconfig.sh: starting net 118 @ 136 sec ./evil_ifconfig.sh: starting net 119 @ 138 sec ./evil_ifconfig.sh: starting net 120 @ 140 sec ./evil_ifconfig.sh: starting net 121 @ 143 sec ./evil_ifconfig.sh: starting net 122 @ 145 sec ./evil_ifconfig.sh: starting net 123 @ 147 sec ./evil_ifconfig.sh: starting net 124 @ 150 sec ./evil_ifconfig.sh: starting net 125 @ 152 sec ./evil_ifconfig.sh: starting net 126 @ 155 sec ./evil_ifconfig.sh: starting net 127 @ 157 sec ./evil_ifconfig.sh: starting net 128 @ 159 sec ./evil_ifconfig.sh: starting net 129 @ 162 sec ./evil_ifconfig.sh: starting net 130 @ 164 sec ./evil_ifconfig.sh: starting net 131 @ 167 sec ./evil_ifconfig.sh: starting net 132 @ 169 sec ./evil_ifconfig.sh: starting net 133 @ 172 sec ./evil_ifconfig.sh: starting net 134 @ 175 sec ./evil_ifconfig.sh: starting net 135 @ 177 sec ./evil_ifconfig.sh: starting net 136 @ 180 sec ./evil_ifconfig.sh: starting net 137 @ 182 sec ./evil_ifconfig.sh: starting net 138 @ 185 sec ./evil_ifconfig.sh: starting net 139 @ 188 sec ./evil_ifconfig.sh: starting net 140 @ 191 sec ./evil_ifconfig.sh: starting net 141 @ 193 sec ./evil_ifconfig.sh: starting net 142 @ 196 sec ./evil_ifconfig.sh: starting net 143 @ 199 sec ./evil_ifconfig.sh: starting net 144 @ 201 sec ./evil_ifconfig.sh: starting net 145 @ 204 sec ./evil_ifconfig.sh: starting net 146 @ 207 sec ./evil_ifconfig.sh: starting net 147 @ 210 sec ./evil_ifconfig.sh: starting net 148 @ 213 sec ./evil_ifconfig.sh: starting net 149 @ 216 sec ./evil_ifconfig.sh: starting net 150 @ 218 sec ./evil_ifconfig.sh: starting net 151 @ 221 sec ./evil_ifconfig.sh: starting net 152 @ 224 sec ./evil_ifconfig.sh: starting net 153 @ 227 sec ./evil_ifconfig.sh: starting net 154 @ 230 sec ./evil_ifconfig.sh: starting net 155 @ 233 sec ./evil_ifconfig.sh: starting net 156 @ 236 sec ./evil_ifconfig.sh: starting net 157 @ 239 sec ./evil_ifconfig.sh: starting net 158 @ 242 sec ./evil_ifconfig.sh: starting net 159 @ 245 sec ./evil_ifconfig.sh: starting net 160 @ 248 sec ./evil_ifconfig.sh: starting net 161 @ 251 sec ./evil_ifconfig.sh: starting net 162 @ 254 sec ./evil_ifconfig.sh: starting net 163 @ 258 sec ./evil_ifconfig.sh: starting net 164 @ 261 sec ./evil_ifconfig.sh: starting net 165 @ 264 sec ./evil_ifconfig.sh: starting net 166 @ 267 sec ./evil_ifconfig.sh: starting net 167 @ 270 sec ./evil_ifconfig.sh: starting net 168 @ 273 sec ./evil_ifconfig.sh: starting net 169 @ 277 sec ./evil_ifconfig.sh: starting net 170 @ 280 sec ./evil_ifconfig.sh: starting net 171 @ 283 sec ./evil_ifconfig.sh: starting net 172 @ 286 sec ./evil_ifconfig.sh: starting net 173 @ 290 sec ./evil_ifconfig.sh: starting net 174 @ 293 sec ./evil_ifconfig.sh: starting net 175 @ 296 sec ./evil_ifconfig.sh: starting net 176 @ 300 sec ./evil_ifconfig.sh: starting net 177 @ 303 sec ./evil_ifconfig.sh: starting net 178 @ 306 sec ./evil_ifconfig.sh: starting net 179 @ 310 sec ./evil_ifconfig.sh: starting net 180 @ 313 sec ./evil_ifconfig.sh: starting net 181 @ 317 sec ./evil_ifconfig.sh: starting net 182 @ 320 sec ./evil_ifconfig.sh: starting net 183 @ 324 sec ./evil_ifconfig.sh: starting net 184 @ 327 sec ./evil_ifconfig.sh: starting net 185 @ 331 sec ./evil_ifconfig.sh: starting net 186 @ 334 sec ./evil_ifconfig.sh: starting net 187 @ 338 sec ./evil_ifconfig.sh: starting net 188 @ 341 sec ./evil_ifconfig.sh: starting net 189 @ 345 sec ./evil_ifconfig.sh: starting net 190 @ 349 sec ./evil_ifconfig.sh: starting net 191 @ 352 sec ./evil_ifconfig.sh: starting net 192 @ 356 sec ./evil_ifconfig.sh: starting net 193 @ 360 sec ./evil_ifconfig.sh: starting net 194 @ 363 sec ./evil_ifconfig.sh: starting net 195 @ 367 sec ./evil_ifconfig.sh: starting net 196 @ 371 sec ./evil_ifconfig.sh: starting net 197 @ 374 sec ./evil_ifconfig.sh: starting net 198 @ 378 sec ./evil_ifconfig.sh: starting net 199 @ 382 sec ./evil_ifconfig.sh: starting net 200 @ 386 sec ./evil_ifconfig.sh: starting net 201 @ 389 sec ./evil_ifconfig.sh: starting net 202 @ 393 sec ./evil_ifconfig.sh: starting net 203 @ 397 sec ./evil_ifconfig.sh: starting net 204 @ 401 sec ./evil_ifconfig.sh: starting net 205 @ 405 sec ./evil_ifconfig.sh: starting net 206 @ 409 sec ./evil_ifconfig.sh: starting net 207 @ 413 sec ./evil_ifconfig.sh: starting net 208 @ 417 sec ./evil_ifconfig.sh: starting net 209 @ 421 sec ./evil_ifconfig.sh: starting net 210 @ 425 sec ./evil_ifconfig.sh: starting net 211 @ 428 sec ./evil_ifconfig.sh: starting net 212 @ 432 sec ./evil_ifconfig.sh: starting net 213 @ 436 sec ./evil_ifconfig.sh: starting net 214 @ 441 sec ./evil_ifconfig.sh: starting net 215 @ 445 sec ./evil_ifconfig.sh: starting net 216 @ 449 sec ./evil_ifconfig.sh: starting net 217 @ 453 sec ./evil_ifconfig.sh: starting net 218 @ 457 sec ./evil_ifconfig.sh: starting net 219 @ 461 sec ./evil_ifconfig.sh: starting net 220 @ 465 sec ./evil_ifconfig.sh: starting net 221 @ 469 sec ./evil_ifconfig.sh: starting net 222 @ 473 sec ./evil_ifconfig.sh: starting net 223 @ 477 sec ./evil_ifconfig.sh: starting net 224 @ 482 sec ./evil_ifconfig.sh: starting net 225 @ 486 sec ./evil_ifconfig.sh: starting net 226 @ 490 sec ./evil_ifconfig.sh: starting net 227 @ 494 sec ./evil_ifconfig.sh: starting net 228 @ 498 sec ./evil_ifconfig.sh: starting net 229 @ 503 sec ./evil_ifconfig.sh: starting net 230 @ 507 sec ./evil_ifconfig.sh: starting net 231 @ 511 sec ./evil_ifconfig.sh: starting net 232 @ 516 sec ./evil_ifconfig.sh: starting net 233 @ 520 sec ./evil_ifconfig.sh: starting net 234 @ 524 sec ./evil_ifconfig.sh: starting net 235 @ 529 sec ./evil_ifconfig.sh: starting net 236 @ 533 sec ./evil_ifconfig.sh: starting net 237 @ 537 sec ./evil_ifconfig.sh: starting net 238 @ 542 sec ./evil_ifconfig.sh: starting net 239 @ 546 sec ./evil_ifconfig.sh: starting net 240 @ 551 sec ./evil_ifconfig.sh: starting net 241 @ 555 sec ./evil_ifconfig.sh: starting net 242 @ 559 sec ./evil_ifconfig.sh: starting net 243 @ 564 sec ./evil_ifconfig.sh: starting net 244 @ 568 sec ./evil_ifconfig.sh: starting net 245 @ 573 sec ./evil_ifconfig.sh: starting net 246 @ 578 sec ./evil_ifconfig.sh: starting net 247 @ 582 sec ./evil_ifconfig.sh: starting net 248 @ 587 sec ./evil_ifconfig.sh: starting net 249 @ 591 sec ./evil_ifconfig.sh: starting net 250 @ 596 sec ./evil_ifconfig.sh: starting net 251 @ 601 sec ./evil_ifconfig.sh: starting net 252 @ 605 sec ./evil_ifconfig.sh: starting net 253 @ 610 sec ./evil_ifconfig.sh: starting net 254 @ 615 sec ./evil_ifconfig.sh: starting net 255 @ 619 sec ./evil_ifconfig.sh 27,29s user 599,00s system 100% cpu 10:23,74 total Deleting in Linux (modified only one letter, so output looks the same except times): $ cat evil_ifconfig.sh #!/bin/sh i=0 starttime=$(date +%s) while [ $i -lt 65534 ]; do ipa=$(($i % 256)) net=$(($i / 256)) ip a d 172.18.$net.$ipa/32 dev eth0 [ $ipa -eq 0 ] && echo $0: starting net $net @ $((`date +%s` - $starttime)) sec | tee -a /root/evil_ifconfig.log i=$(($i + 1)) done $ ./evil_ifconfig.sh ./evil_ifconfig.sh: starting net 0 @ 0 sec ./evil_ifconfig.sh: starting net 1 @ 4 sec ./evil_ifconfig.sh: starting net 2 @ 8 sec ./evil_ifconfig.sh: starting net 3 @ 12 sec ./evil_ifconfig.sh: starting net 4 @ 16 sec ./evil_ifconfig.sh: starting net 5 @ 19 sec ./evil_ifconfig.sh: starting net 6 @ 23 sec ./evil_ifconfig.sh: starting net 7 @ 27 sec ./evil_ifconfig.sh: starting net 8 @ 31 sec ./evil_ifconfig.sh: starting net 9 @ 34 sec ./evil_ifconfig.sh: starting net 10 @ 38 sec ./evil_ifconfig.sh: starting net 11 @ 42 sec ./evil_ifconfig.sh: starting net 12 @ 46 sec ./evil_ifconfig.sh: starting net 13 @ 49 sec ./evil_ifconfig.sh: starting net 14 @ 53 sec ./evil_ifconfig.sh: starting net 15 @ 57 sec ./evil_ifconfig.sh: starting net 16 @ 60 sec ./evil_ifconfig.sh: starting net 17 @ 64 sec ./evil_ifconfig.sh: starting net 18 @ 68 sec ./evil_ifconfig.sh: starting net 19 @ 71 sec ./evil_ifconfig.sh: starting net 20 @ 75 sec ./evil_ifconfig.sh: starting net 21 @ 78 sec ./evil_ifconfig.sh: starting net 22 @ 82 sec ./evil_ifconfig.sh: starting net 23 @ 85 sec ./evil_ifconfig.sh: starting net 24 @ 89 sec ./evil_ifconfig.sh: starting net 25 @ 92 sec ./evil_ifconfig.sh: starting net 26 @ 96 sec ./evil_ifconfig.sh: starting net 27 @ 99 sec ./evil_ifconfig.sh: starting net 28 @ 103 sec ./evil_ifconfig.sh: starting net 29 @ 106 sec ./evil_ifconfig.sh: starting net 30 @ 109 sec ./evil_ifconfig.sh: starting net 31 @ 113 sec ./evil_ifconfig.sh: starting net 32 @ 116 sec ./evil_ifconfig.sh: starting net 33 @ 119 sec ./evil_ifconfig.sh: starting net 34 @ 123 sec ./evil_ifconfig.sh: starting net 35 @ 126 sec ./evil_ifconfig.sh: starting net 36 @ 129 sec ./evil_ifconfig.sh: starting net 37 @ 133 sec ./evil_ifconfig.sh: starting net 38 @ 136 sec ./evil_ifconfig.sh: starting net 39 @ 139 sec ./evil_ifconfig.sh: starting net 40 @ 142 sec ./evil_ifconfig.sh: starting net 41 @ 145 sec ./evil_ifconfig.sh: starting net 42 @ 149 sec ./evil_ifconfig.sh: starting net 43 @ 152 sec ./evil_ifconfig.sh: starting net 44 @ 155 sec ./evil_ifconfig.sh: starting net 45 @ 158 sec ./evil_ifconfig.sh: starting net 46 @ 161 sec ./evil_ifconfig.sh: starting net 47 @ 164 sec ./evil_ifconfig.sh: starting net 48 @ 167 sec ./evil_ifconfig.sh: starting net 49 @ 170 sec ./evil_ifconfig.sh: starting net 50 @ 173 sec ./evil_ifconfig.sh: starting net 51 @ 176 sec ./evil_ifconfig.sh: starting net 52 @ 179 sec ./evil_ifconfig.sh: starting net 53 @ 182 sec ./evil_ifconfig.sh: starting net 54 @ 185 sec ./evil_ifconfig.sh: starting net 55 @ 188 sec ./evil_ifconfig.sh: starting net 56 @ 191 sec ./evil_ifconfig.sh: starting net 57 @ 194 sec ./evil_ifconfig.sh: starting net 58 @ 197 sec ./evil_ifconfig.sh: starting net 59 @ 200 sec ./evil_ifconfig.sh: starting net 60 @ 202 sec ./evil_ifconfig.sh: starting net 61 @ 205 sec ./evil_ifconfig.sh: starting net 62 @ 208 sec ./evil_ifconfig.sh: starting net 63 @ 211 sec ./evil_ifconfig.sh: starting net 64 @ 214 sec ./evil_ifconfig.sh: starting net 65 @ 216 sec ./evil_ifconfig.sh: starting net 66 @ 219 sec ./evil_ifconfig.sh: starting net 67 @ 222 sec ./evil_ifconfig.sh: starting net 68 @ 224 sec ./evil_ifconfig.sh: starting net 69 @ 227 sec ./evil_ifconfig.sh: starting net 70 @ 230 sec ./evil_ifconfig.sh: starting net 71 @ 232 sec ./evil_ifconfig.sh: starting net 72 @ 235 sec ./evil_ifconfig.sh: starting net 73 @ 237 sec ./evil_ifconfig.sh: starting net 74 @ 240 sec ./evil_ifconfig.sh: starting net 75 @ 243 sec ./evil_ifconfig.sh: starting net 76 @ 245 sec ./evil_ifconfig.sh: starting net 77 @ 248 sec ./evil_ifconfig.sh: starting net 78 @ 250 sec ./evil_ifconfig.sh: starting net 79 @ 253 sec ./evil_ifconfig.sh: starting net 80 @ 255 sec ./evil_ifconfig.sh: starting net 81 @ 257 sec ./evil_ifconfig.sh: starting net 82 @ 260 sec ./evil_ifconfig.sh: starting net 83 @ 262 sec ./evil_ifconfig.sh: starting net 84 @ 265 sec ./evil_ifconfig.sh: starting net 85 @ 267 sec ./evil_ifconfig.sh: starting net 86 @ 269 sec ./evil_ifconfig.sh: starting net 87 @ 272 sec ./evil_ifconfig.sh: starting net 88 @ 274 sec ./evil_ifconfig.sh: starting net 89 @ 276 sec ./evil_ifconfig.sh: starting net 90 @ 278 sec ./evil_ifconfig.sh: starting net 91 @ 281 sec ./evil_ifconfig.sh: starting net 92 @ 283 sec ./evil_ifconfig.sh: starting net 93 @ 285 sec ./evil_ifconfig.sh: starting net 94 @ 287 sec ./evil_ifconfig.sh: starting net 95 @ 289 sec ./evil_ifconfig.sh: starting net 96 @ 292 sec ./evil_ifconfig.sh: starting net 97 @ 294 sec ./evil_ifconfig.sh: starting net 98 @ 296 sec ./evil_ifconfig.sh: starting net 99 @ 298 sec ./evil_ifconfig.sh: starting net 100 @ 300 sec ./evil_ifconfig.sh: starting net 101 @ 302 sec ./evil_ifconfig.sh: starting net 102 @ 304 sec ./evil_ifconfig.sh: starting net 103 @ 306 sec ./evil_ifconfig.sh: starting net 104 @ 308 sec ./evil_ifconfig.sh: starting net 105 @ 310 sec ./evil_ifconfig.sh: starting net 106 @ 312 sec ./evil_ifconfig.sh: starting net 107 @ 314 sec ./evil_ifconfig.sh: starting net 108 @ 316 sec ./evil_ifconfig.sh: starting net 109 @ 318 sec ./evil_ifconfig.sh: starting net 110 @ 320 sec ./evil_ifconfig.sh: starting net 111 @ 322 sec ./evil_ifconfig.sh: starting net 112 @ 323 sec ./evil_ifconfig.sh: starting net 113 @ 325 sec ./evil_ifconfig.sh: starting net 114 @ 327 sec ./evil_ifconfig.sh: starting net 115 @ 329 sec ./evil_ifconfig.sh: starting net 116 @ 331 sec ./evil_ifconfig.sh: starting net 117 @ 332 sec ./evil_ifconfig.sh: starting net 118 @ 334 sec ./evil_ifconfig.sh: starting net 119 @ 336 sec ./evil_ifconfig.sh: starting net 120 @ 337 sec ./evil_ifconfig.sh: starting net 121 @ 339 sec ./evil_ifconfig.sh: starting net 122 @ 341 sec ./evil_ifconfig.sh: starting net 123 @ 342 sec ./evil_ifconfig.sh: starting net 124 @ 344 sec ./evil_ifconfig.sh: starting net 125 @ 345 sec ./evil_ifconfig.sh: starting net 126 @ 347 sec ./evil_ifconfig.sh: starting net 127 @ 348 sec ./evil_ifconfig.sh: starting net 128 @ 350 sec ./evil_ifconfig.sh: starting net 129 @ 351 sec ./evil_ifconfig.sh: starting net 130 @ 352 sec ./evil_ifconfig.sh: starting net 131 @ 354 sec ./evil_ifconfig.sh: starting net 132 @ 355 sec ./evil_ifconfig.sh: starting net 133 @ 356 sec ./evil_ifconfig.sh: starting net 134 @ 357 sec ./evil_ifconfig.sh: starting net 135 @ 359 sec ./evil_ifconfig.sh: starting net 136 @ 360 sec ./evil_ifconfig.sh: starting net 137 @ 361 sec ./evil_ifconfig.sh: starting net 138 @ 362 sec ./evil_ifconfig.sh: starting net 139 @ 363 sec ./evil_ifconfig.sh: starting net 140 @ 364 sec ./evil_ifconfig.sh: starting net 141 @ 366 sec ./evil_ifconfig.sh: starting net 142 @ 367 sec ./evil_ifconfig.sh: starting net 143 @ 368 sec ./evil_ifconfig.sh: starting net 144 @ 369 sec ./evil_ifconfig.sh: starting net 145 @ 370 sec ./evil_ifconfig.sh: starting net 146 @ 371 sec ./evil_ifconfig.sh: starting net 147 @ 372 sec ./evil_ifconfig.sh: starting net 148 @ 373 sec ./evil_ifconfig.sh: starting net 149 @ 374 sec ./evil_ifconfig.sh: starting net 150 @ 375 sec ./evil_ifconfig.sh: starting net 151 @ 375 sec ./evil_ifconfig.sh: starting net 152 @ 376 sec ./evil_ifconfig.sh: starting net 153 @ 377 sec ./evil_ifconfig.sh: starting net 154 @ 378 sec ./evil_ifconfig.sh: starting net 155 @ 379 sec ./evil_ifconfig.sh: starting net 156 @ 380 sec ./evil_ifconfig.sh: starting net 157 @ 381 sec ./evil_ifconfig.sh: starting net 158 @ 381 sec ./evil_ifconfig.sh: starting net 159 @ 382 sec ./evil_ifconfig.sh: starting net 160 @ 383 sec ./evil_ifconfig.sh: starting net 161 @ 384 sec ./evil_ifconfig.sh: starting net 162 @ 384 sec ./evil_ifconfig.sh: starting net 163 @ 385 sec ./evil_ifconfig.sh: starting net 164 @ 386 sec ./evil_ifconfig.sh: starting net 165 @ 386 sec ./evil_ifconfig.sh: starting net 166 @ 387 sec ./evil_ifconfig.sh: starting net 167 @ 388 sec ./evil_ifconfig.sh: starting net 168 @ 388 sec ./evil_ifconfig.sh: starting net 169 @ 389 sec ./evil_ifconfig.sh: starting net 170 @ 390 sec ./evil_ifconfig.sh: starting net 171 @ 390 sec ./evil_ifconfig.sh: starting net 172 @ 391 sec ./evil_ifconfig.sh: starting net 173 @ 391 sec ./evil_ifconfig.sh: starting net 174 @ 392 sec ./evil_ifconfig.sh: starting net 175 @ 392 sec ./evil_ifconfig.sh: starting net 176 @ 393 sec ./evil_ifconfig.sh: starting net 177 @ 393 sec ./evil_ifconfig.sh: starting net 178 @ 394 sec ./evil_ifconfig.sh: starting net 179 @ 394 sec ./evil_ifconfig.sh: starting net 180 @ 395 sec ./evil_ifconfig.sh: starting net 181 @ 395 sec ./evil_ifconfig.sh: starting net 182 @ 396 sec ./evil_ifconfig.sh: starting net 183 @ 396 sec ./evil_ifconfig.sh: starting net 184 @ 397 sec ./evil_ifconfig.sh: starting net 185 @ 397 sec ./evil_ifconfig.sh: starting net 186 @ 398 sec ./evil_ifconfig.sh: starting net 187 @ 398 sec ./evil_ifconfig.sh: starting net 188 @ 399 sec ./evil_ifconfig.sh: starting net 189 @ 399 sec ./evil_ifconfig.sh: starting net 190 @ 399 sec ./evil_ifconfig.sh: starting net 191 @ 400 sec ./evil_ifconfig.sh: starting net 192 @ 400 sec ./evil_ifconfig.sh: starting net 193 @ 400 sec ./evil_ifconfig.sh: starting net 194 @ 401 sec ./evil_ifconfig.sh: starting net 195 @ 401 sec ./evil_ifconfig.sh: starting net 196 @ 402 sec ./evil_ifconfig.sh: starting net 197 @ 402 sec ./evil_ifconfig.sh: starting net 198 @ 402 sec ./evil_ifconfig.sh: starting net 199 @ 403 sec ./evil_ifconfig.sh: starting net 200 @ 403 sec ./evil_ifconfig.sh: starting net 201 @ 403 sec ./evil_ifconfig.sh: starting net 202 @ 403 sec ./evil_ifconfig.sh: starting net 203 @ 404 sec ./evil_ifconfig.sh: starting net 204 @ 404 sec ./evil_ifconfig.sh: starting net 205 @ 404 sec ./evil_ifconfig.sh: starting net 206 @ 405 sec ./evil_ifconfig.sh: starting net 207 @ 405 sec ./evil_ifconfig.sh: starting net 208 @ 405 sec ./evil_ifconfig.sh: starting net 209 @ 406 sec ./evil_ifconfig.sh: starting net 210 @ 406 sec ./evil_ifconfig.sh: starting net 211 @ 406 sec ./evil_ifconfig.sh: starting net 212 @ 406 sec ./evil_ifconfig.sh: starting net 213 @ 407 sec ./evil_ifconfig.sh: starting net 214 @ 407 sec ./evil_ifconfig.sh: starting net 215 @ 407 sec ./evil_ifconfig.sh: starting net 216 @ 407 sec ./evil_ifconfig.sh: starting net 217 @ 408 sec ./evil_ifconfig.sh: starting net 218 @ 408 sec ./evil_ifconfig.sh: starting net 219 @ 408 sec ./evil_ifconfig.sh: starting net 220 @ 409 sec ./evil_ifconfig.sh: starting net 221 @ 409 sec ./evil_ifconfig.sh: starting net 222 @ 409 sec ./evil_ifconfig.sh: starting net 223 @ 409 sec ./evil_ifconfig.sh: starting net 224 @ 410 sec ./evil_ifconfig.sh: starting net 225 @ 410 sec ./evil_ifconfig.sh: starting net 226 @ 410 sec ./evil_ifconfig.sh: starting net 227 @ 410 sec ./evil_ifconfig.sh: starting net 228 @ 411 sec ./evil_ifconfig.sh: starting net 229 @ 411 sec ./evil_ifconfig.sh: starting net 230 @ 411 sec ./evil_ifconfig.sh: starting net 231 @ 411 sec ./evil_ifconfig.sh: starting net 232 @ 412 sec ./evil_ifconfig.sh: starting net 233 @ 412 sec ./evil_ifconfig.sh: starting net 234 @ 412 sec ./evil_ifconfig.sh: starting net 235 @ 412 sec ./evil_ifconfig.sh: starting net 236 @ 413 sec ./evil_ifconfig.sh: starting net 237 @ 413 sec ./evil_ifconfig.sh: starting net 238 @ 413 sec ./evil_ifconfig.sh: starting net 239 @ 413 sec ./evil_ifconfig.sh: starting net 240 @ 413 sec ./evil_ifconfig.sh: starting net 241 @ 414 sec ./evil_ifconfig.sh: starting net 242 @ 414 sec ./evil_ifconfig.sh: starting net 243 @ 414 sec ./evil_ifconfig.sh: starting net 244 @ 414 sec ./evil_ifconfig.sh: starting net 245 @ 415 sec ./evil_ifconfig.sh: starting net 246 @ 415 sec ./evil_ifconfig.sh: starting net 247 @ 415 sec ./evil_ifconfig.sh: starting net 248 @ 415 sec ./evil_ifconfig.sh: starting net 249 @ 415 sec ./evil_ifconfig.sh: starting net 250 @ 416 sec ./evil_ifconfig.sh: starting net 251 @ 416 sec ./evil_ifconfig.sh: starting net 252 @ 416 sec ./evil_ifconfig.sh: starting net 253 @ 416 sec ./evil_ifconfig.sh: starting net 254 @ 416 sec ./evil_ifconfig.sh: starting net 255 @ 417 sec ./evil_ifconfig.sh 21,84s user 392,17s system 99% cpu 6:56,71 total -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 22:39:37 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0783816A404 for ; Thu, 21 Feb 2008 22:39:37 +0000 (UTC) (envelope-from bthielsen@safarivideonetworks.com) Received: from smtp.ltn.lvc.com (static-66-14-195-72.bdsl.verizon.net [66.14.195.72]) by mx1.freebsd.org (Postfix) with ESMTP id A360613C4F9 for ; Thu, 21 Feb 2008 22:39:36 +0000 (UTC) (envelope-from bthielsen@safarivideonetworks.com) Received: from localhost (localhost [127.0.0.1]) by macgyver.ltn.lvc.com (Postfix) with ESMTP id 5E5F26A0C30 for ; Thu, 21 Feb 2008 13:21:28 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at macgyver.ltn.lvc.com Received: from macgyver.ltn.lvc.com ([127.0.0.1]) by localhost (macgyver.ltn.lvc.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WsnpXs3NiYzz for ; Thu, 21 Feb 2008 13:21:23 -0500 (EST) Received: from heliax.ltn.lvc.com (heliax.ltn.lvc.com [10.10.101.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by macgyver.ltn.lvc.com (Postfix) with ESMTP id B980E6A0C2F for ; Thu, 21 Feb 2008 13:21:23 -0500 (EST) Message-Id: From: benjamin thielsen To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 13:21:23 -0500 X-Mailer: Apple Mail (2.919.2) Subject: performance degradation in 6.2 when adding a second quad core chip X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:39:37 -0000 hi folks- we've been experiencing some interesting behavior on single quad core computers as compared to dual quad core computers. it appears that adding a second processor to the system (leaving it otherwise untouched) actually decreases performance. we've got a small rudimentary test process, built in house, that does postgresql queries (selects) via http requests (apache2/php5). here is a small data set from what we've seen so far: a user is one iteration of a curl statement and values listed in the cpu columns are average time before the page returns, in seconds. users 1 cpu 2 cpu ------------------------------- 60 2.48 2.18 80 3.34 2.72 100 4.18 5.34 120 9.48 15.61 140 13.2 46.16 160 26.28 66.99 we're confident that nothing else has changed other than the addition of the chip, so i'm hoping for some insight on where we might look for clues. the above results used 6.2-RELEASE. we've started the same test using 7.0-RC2 and are seeing similar response times with both processors in place. next on our list is doing a single processor iteration of the 7.0-RC2 test to corroborate that data, followed by a local test to query pg more directly, removing apache and friends from the equation, in hopes of getting some clarity. below are the basics of this configuration - this is a new list for me, so i've been conservative, but i'm happy to provide as much detail as is helpful. computer: dell poweredge 2900 xeon quad core 2 ghz / 1333 mhz bus speed / 2 x 6mb l2 cache 4 gb 667 mhz memory all of the software has been installed via ports, the 6.2 kernel is a custom kernel with (i believe) mostly rudimentary changes and support for the perc6 disk controller (that became available in 7) added, and the 7.0 kernel contains the same changes as the 6.2 kernel, excluding the custom perc6 support. thanks! -ben From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 22:50:01 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 413BD16A408 for ; Thu, 21 Feb 2008 22:50:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF1A013C447; Thu, 21 Feb 2008 22:49:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BE0016.6020407@FreeBSD.org> Date: Thu, 21 Feb 2008 23:49:58 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: benjamin thielsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: performance degradation in 6.2 when adding a second quad core chip X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:50:01 -0000 benjamin thielsen wrote: > hi folks- > > we've been experiencing some interesting behavior on single quad core > computers as compared to dual quad core computers. Yes, this can happen when you run into concurrency bottlenecks in the application or in the kernel. > it appears that adding a second processor to the system (leaving it > otherwise untouched) actually decreases performance. we've got a small > rudimentary test process, built in house, that does postgresql queries > (selects) via http requests (apache2/php5). 7.0 will perform much better than 6.x on SMP workloads in general, however TCP I/O is not yet at the point where it can make efficient use of many processors (there has been a lot of work on TCP in 7.0, but it is not yet at the stage where a performance payoff will be seen with more than about 4 CPUs). This is one of the projects that we will be working on this year, so you can expect future releases to have improved concurrent TCP performance. There may be other issues, so if you like you can enable LOCK_PROFILING and obtain a trace when your workload is running (see the manpage). You should also try the ULE scheduler on 7.0. Kris From owner-freebsd-performance@FreeBSD.ORG Fri Feb 22 10:16:41 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0FDB16A401 for ; Fri, 22 Feb 2008 10:16:41 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id B6FB213C461 for ; Fri, 22 Feb 2008 10:16:41 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1M9wqOZ023602; Fri, 22 Feb 2008 01:58:52 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1M9wq7v023601; Fri, 22 Feb 2008 01:58:52 -0800 (PST) (envelope-from obrien) Date: Fri, 22 Feb 2008 01:58:52 -0800 From: "David O'Brien" To: Chuck Swiger , "freebsd-performance@freebsd.org" Message-ID: <20080222095852.GB22890@dragon.NUXI.org> References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> <20080220210118.GY99258@elvis.mu.org> <47BC9ED5.1010505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BC9ED5.1010505@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 10:16:41 -0000 On Wed, Feb 20, 2008 at 10:42:45PM +0100, Kris Kennaway wrote: > Chuck Swiger wrote: > TCP mounts should be used whenever possible thesedays (I flipped the > default mode in 8.0 the other day). And I made TCP mounts the default for Amd over a year ago. NFS really has moved on to TCP these days. -- -- David (obrien@FreeBSD.org) From owner-freebsd-performance@FreeBSD.ORG Fri Feb 22 14:35:52 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0841C16A402 for ; Fri, 22 Feb 2008 14:35:52 +0000 (UTC) (envelope-from bthielsen@safarivideonetworks.com) Received: from smtp.ltn.lvc.com (static-66-14-195-72.bdsl.verizon.net [66.14.195.72]) by mx1.freebsd.org (Postfix) with ESMTP id B02E513C442 for ; Fri, 22 Feb 2008 14:35:51 +0000 (UTC) (envelope-from bthielsen@safarivideonetworks.com) Received: from localhost (localhost [127.0.0.1]) by macgyver.ltn.lvc.com (Postfix) with ESMTP id 56D196A0C34 for ; Fri, 22 Feb 2008 09:35:50 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at macgyver.ltn.lvc.com Received: from macgyver.ltn.lvc.com ([127.0.0.1]) by localhost (macgyver.ltn.lvc.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WYxS86DS5fkc for ; Fri, 22 Feb 2008 09:35:45 -0500 (EST) Received: from heliax.ltn.lvc.com (heliax.ltn.lvc.com [10.10.101.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by macgyver.ltn.lvc.com (Postfix) with ESMTP id 9A9376A0C33 for ; Fri, 22 Feb 2008 09:35:45 -0500 (EST) Message-Id: <2E9A88C1-067C-4C9C-A062-42203F47BF1C@safarivideonetworks.com> From: benjamin thielsen To: freebsd-performance@freebsd.org In-Reply-To: <47BE0016.6020407@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 09:35:45 -0500 References: <47BE0016.6020407@FreeBSD.org> X-Mailer: Apple Mail (2.919.2) Subject: Re: performance degradation in 6.2 when adding a second quad core chip X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 14:35:52 -0000 On Feb 21, 2008, at 17.49, Kris Kennaway wrote: > benjamin thielsen wrote: >> hi folks- >> we've been experiencing some interesting behavior on single quad >> core computers as compared to dual quad core computers. > > Yes, this can happen when you run into concurrency bottlenecks in > the application or in the kernel. > >> it appears that adding a second processor to the system (leaving it >> otherwise untouched) actually decreases performance. we've got a >> small rudimentary test process, built in house, that does >> postgresql queries (selects) via http requests (apache2/php5). > > 7.0 will perform much better than 6.x on SMP workloads in general, > however TCP I/O is not yet at the point where it can make efficient > use of many processors (there has been a lot of work on TCP in 7.0, > but it is not yet at the stage where a performance payoff will be > seen with more than about 4 CPUs). This is one of the projects that > we will be working on this year, so you can expect future releases > to have improved concurrent TCP performance. > > There may be other issues, so if you like you can enable > LOCK_PROFILING and obtain a trace when your workload is running (see > the manpage). You should also try the ULE scheduler on 7.0. i apologize - i neglected to mention that we are using ule on 7.0. what do you guys generally endorse/recommend for local(non-network) load/performance testing? -ben From owner-freebsd-performance@FreeBSD.ORG Fri Feb 22 16:55:01 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE2616A404 for ; Fri, 22 Feb 2008 16:55:01 +0000 (UTC) (envelope-from noisex@apollo.lv) Received: from smtp1.apollo.lv (smtp1.apollo.lv [80.232.168.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3737513C447 for ; Fri, 22 Feb 2008 16:55:00 +0000 (UTC) (envelope-from noisex@apollo.lv) X-Cloudmark-Score: 0.000000 [] X-Virusscan: Clamd Received: from [195.122.14.116] (HELO dreamwork) by smtp1.apollo.lv (CommuniGate Pro SMTP 5.1.12) with ESMTP id 326888310 for freebsd-performance@freebsd.org; Fri, 22 Feb 2008 17:54:57 +0200 From: "Noisex" To: References: <47BE0016.6020407@FreeBSD.org> <2E9A88C1-067C-4C9C-A062-42203F47BF1C@safarivideonetworks.com> In-Reply-To: <2E9A88C1-067C-4C9C-A062-42203F47BF1C@safarivideonetworks.com> Date: Fri, 22 Feb 2008 17:54:55 +0200 Message-ID: <00d201c8756b$44f3d4c0$cedb7e40$@lv> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ach1YFta0Tj7v6tkQoaaCWTmNypoZAABnLtQ Content-Language: lv Subject: RE: performance degradation in 6.2 when adding a second quad core chip X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 16:55:01 -0000 So Benjamin you want to tell, that adding additional CPU decrease the performance on 6.2? How did you made tests? I just want to know because in my plans to the next week is also add 2nd CPU (dual core) and some additional RAM to one of the my HP Proliant DL360 (generaly mysql db server) because due to heavy MySQL usage nearly to 100% or even more sometimes some of my customers are not very happy with service like that (long load time). Server: HP proliant G4P DL360, CPU 1x3Ghz dual core, RAM: 4Gb (on system i can see 3Gb :) ), SCSI 146Gbx2 (RAID 1+0 with smartarray controller p4600). OS: FreeBSD 6.2, SMP Current load of mysql process: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 70348 mysql 17 20 0 450M 234M kserel 1 111.4H 99.46% mysqld MySQL Version 5.0.51 i386 Uptime = 28 days 18 hrs 51 min 19 sec Avg. qps = 567 Total Questions = 469973918 Threads Connected = 4 however that may be: 1) on next week i will upgrade to 6.3 but i dont know will it give some performance or not but generaly i wait final relase of 7.0 with ULE sheduller. 2) i will add +4GB RAM 3) i will add 2nd CPU If it will not help, i will consider about mysql clustering...btw, is it ok/done on freebsd? p.s what you guys could recommend about enabled/disabled hyperthreading on intel? Will it increase performance or over the left decrease? -Gatis Rumbens -----Original Message----- From: owner-freebsd-performance@freebsd.org [mailto:owner-freebsd-performance@freebsd.org] On Behalf Of benjamin thielsen Sent: Friday, February 22, 2008 4:36 PM To: freebsd-performance@freebsd.org Subject: Re: performance degradation in 6.2 when adding a second quad core chip On Feb 21, 2008, at 17.49, Kris Kennaway wrote: > benjamin thielsen wrote: >> hi folks- >> we've been experiencing some interesting behavior on single quad >> core computers as compared to dual quad core computers. > > Yes, this can happen when you run into concurrency bottlenecks in > the application or in the kernel. > >> it appears that adding a second processor to the system (leaving it >> otherwise untouched) actually decreases performance. we've got a >> small rudimentary test process, built in house, that does >> postgresql queries (selects) via http requests (apache2/php5). > > 7.0 will perform much better than 6.x on SMP workloads in general, > however TCP I/O is not yet at the point where it can make efficient > use of many processors (there has been a lot of work on TCP in 7.0, > but it is not yet at the stage where a performance payoff will be > seen with more than about 4 CPUs). This is one of the projects that > we will be working on this year, so you can expect future releases > to have improved concurrent TCP performance. > > There may be other issues, so if you like you can enable > LOCK_PROFILING and obtain a trace when your workload is running (see > the manpage). You should also try the ULE scheduler on 7.0. i apologize - i neglected to mention that we are using ule on 7.0. what do you guys generally endorse/recommend for local(non-network) load/performance testing? -ben _______________________________________________ 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 22 17:37:42 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC39516A404 for ; Fri, 22 Feb 2008 17:37:42 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id CB10D13C448 for ; Fri, 22 Feb 2008 17:37:42 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 47DDC2303F51 for ; Fri, 22 Feb 2008 09:37:27 -0800 (PST) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 2F2C5464003 for ; Fri, 22 Feb 2008 09:37:27 -0800 (PST) X-AuditID: 11807135-a5a71bb000002275-56-47bf0857442c Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay12.apple.com (Apple SCV relay) with ESMTP id 164CC420002 for ; Fri, 22 Feb 2008 09:37:27 -0800 (PST) Message-Id: From: Chuck Swiger To: freebsd-performance@freebsd.org In-Reply-To: <20080222095852.GB22890@dragon.NUXI.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 09:37:26 -0800 References: <27dbfc8c0802190243y113d3059yd0c602850a4dbd6b@mail.gmail.com> <47BB33AD.1050005@FreeBSD.org> <27dbfc8c0802200323r13f69905l4940d0d5accd1eb1@mail.gmail.com> <9BCE1D41-EC1A-4FE6-8551-E725DBE5D3A8@mac.com> <20080220210118.GY99258@elvis.mu.org> <47BC9ED5.1010505@FreeBSD.org> <20080222095852.GB22890@dragon.NUXI.org> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Subject: Re: Bad performance of 7.0 nfs client with Solaris nfs server X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 17:37:42 -0000 On Feb 22, 2008, at 1:58 AM, David O'Brien wrote: > On Wed, Feb 20, 2008 at 10:42:45PM +0100, Kris Kennaway wrote: >> Chuck Swiger wrote: >> TCP mounts should be used whenever possible thesedays (I flipped the >> default mode in 8.0 the other day). > > And I made TCP mounts the default for Amd over a year ago. NFS really > has moved on to TCP these days. Thanks for the feedback, gentlemen. Hopefully it will also help the OP... -- -Chuck From owner-freebsd-performance@FreeBSD.ORG Fri Feb 22 19:09:12 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7840B16A405 for ; Fri, 22 Feb 2008 19:09:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CF0D013C478; Fri, 22 Feb 2008 19:09:11 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BF1DD6.90607@FreeBSD.org> Date: Fri, 22 Feb 2008 20:09:10 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Noisex References: <47BE0016.6020407@FreeBSD.org> <2E9A88C1-067C-4C9C-A062-42203F47BF1C@safarivideonetworks.com> <00d201c8756b$44f3d4c0$cedb7e40$@lv> In-Reply-To: <00d201c8756b$44f3d4c0$cedb7e40$@lv> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: performance degradation in 6.2 when adding a second quad core chip X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 19:09:12 -0000 Noisex wrote: > So Benjamin you want to tell, that adding additional CPU decrease the > performance on 6.2? How did you made tests? > I just want to know because in my plans to the next week is also add > 2nd CPU (dual core) and some additional RAM to one of the my HP Proliant > DL360 (generaly mysql db server) because due to heavy MySQL usage nearly to > 100% or even more sometimes some of my customers are not very happy with > service like that (long load time). > > Server: HP proliant G4P DL360, CPU 1x3Ghz dual core, RAM: 4Gb (on system i > can see 3Gb :) ), SCSI 146Gbx2 (RAID 1+0 with smartarray controller p4600). > OS: FreeBSD 6.2, SMP I wouldn't bother with 8 CPUs if you are running 6.x. As I mentioned, 7.0 SMP performance is much better. http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf > p.s what you guys could recommend about enabled/disabled hyperthreading on > intel? Will it increase performance or over the left decrease? It depends on your workload, it may or may not give a performance benefit. ULE tends to perform better than 4BSD though. Kris