From owner-freebsd-net Fri Jul 17 15:09:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05172 for freebsd-net-outgoing; Fri, 17 Jul 1998 15:09:00 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05165; Fri, 17 Jul 1998 15:08:56 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA21596; Fri, 17 Jul 1998 15:07:37 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd021591; Fri Jul 17 22:07:36 1998 Message-ID: <35AFCB22.7DE14518@whistle.com> Date: Fri, 17 Jul 1998 15:07:30 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Mark Powell CC: dg@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: 2.2.6 net performance and panic with 1000's of sockets open References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Powell wrote: > > Been doing some stress testing of a web caching solutions, to > see which is the better of squid-1.NOVM.22 running under > 2.2.6-RELEASE or Novell's offering FastCache. My workstation > and the cache box, being tested, both have Intel EtherExpress > cards running at 100M into the same switch, so > they get as near the full bandwidth as possible. > I put FreeBSD on one disk > and Netware 4.11 on another and just swapped the drives around at boot > time to get the desired OS. > Thus any hardware difference was ruled out. > Knocked together a few small C programs. I noticed that the max > throughput of the FreeBSD box was a shade over 6M/sec whilst > the Netware box could manage up to nearly 9M/sec. I thought > Netware may have the edge, but by that much? I tried bumping > send/recvspace up to 64K one both boxes, but that only had a > very slight performance increase. Is there anything > else I could try? did you change the default mbuf size to 256 bytes in FreeBSD as suggested in the TUNING FREEBSD for SQUID section of the SQUID FAQ? add options "MSIZE=256" to the kernel config (from memory) there is a patch just committed in current to uipc_socket.c in the kernel (rev 1.141 I think it was) that supposedly fixes the same problem, but is presently suspect due to some strange erroro reports that have been drifting back. you can also mount the cache disks async or noatime. > Using another test program I found that FreeBSD would panic. > The program opened 1000 sockets to the squid box and requested > a file from the web through each. The machine would panic with > a page fault everytime I ran > this program. You mean the server right? I guess it needs more mbufs.. I can't rememeber in 2.2 wherther you can increase it independently of maxusers. > The squid box would display something like "out of > mbufs increase maxusers" and then panic a second or two later. > Sometimes my workstation, which was running the test program, > would also come down at the same time. I noticed if I killed > off all the unnecesary processes on > my workstation it wouldn't panic. A process waking up is finding > some of it's memory missing? Are there any other clues? > Both my workstation and the box under test are running up to date > 2.2.6-RELEASE with maxusers set to 256. "up to date", or "release".. make up your mind :-) 2.2.6 RELEASE is by definition frozen.. 2.2-stable is the version that includes bugfixes and is moving towards 2.2.7. how do you keep your sources up to date? > I followed the kernel debugging information from the handbook, > but gdb still moaned about not finding some memory. > Anyway here it is: > > /sys/compile/SQUID.TAG # gdb -k kernel.debug /var/crash/vmcore.3 the trace just showed tha the stack was trashed.. (i.e. no real useful info) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message