From owner-freebsd-questions@FreeBSD.ORG Wed Aug 22 11:26:02 2007 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98E2016A418; Wed, 22 Aug 2007 11:26:02 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 4687413C494; Wed, 22 Aug 2007 11:26:02 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1INnvS-000NHI-Sa; Wed, 22 Aug 2007 19:59:03 +0900 Message-ID: <46CC16F6.7020904@micom.mng.net> Date: Wed, 22 Aug 2007 18:59:02 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <835936.35104.qm@web34510.mail.mud.yahoo.com> <86r6lvalht.fsf@ds4.des.no> In-Reply-To: <86r6lvalht.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: questions@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: What is a "sane" setting for maxdsize when running amd64? it seems many normal suggestions do not apply. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2007 11:26:02 -0000 Dag-Erling Smørgrav wrote: > Chuck Swiger writes: > >> You should configure squid to use no more than about 60 - 70% of the >> available physical RAM-- ie, set the cache_mem parameter to about 2.5 >> or 3GB. >> > > Better yet, don't run Squid at all. Ok, then what do you recommend instead of Squid? thanks, Ganbold > It was designed for a computer > architecture that was already obsolete when Squid was first written. > > >> It wouldn't be unreasonable to limit datasize to 3 GB on such a >> machine, assuming that nothing you run will ever need to grow >> larger... >> > > ..actually, maxdsiz is meaningless in FreeBSD 7, because the new > allocator uses mmap(2) instead of brk(2) / sbrk(2), so malloc() counts > towards the resident set size (ulimit -m), not the data segment size > (ulimit -d). > > (unless, of course, your application has its own allocator, in which > case you can kiss performance goodbye) > > DES > -- Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms.