From owner-freebsd-questions@FreeBSD.ORG Wed Mar 8 18:34:15 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0AAD16A420 for ; Wed, 8 Mar 2006 18:34:15 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D95243D72 for ; Wed, 8 Mar 2006 18:34:14 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 5F5495CB6; Wed, 8 Mar 2006 13:34:13 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64573-03; Wed, 8 Mar 2006 13:34:12 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 4A4675CB3; Wed, 8 Mar 2006 13:34:12 -0500 (EST) In-Reply-To: <002001c642d9$320fcab0$1b12c055@genie> References: <005b01c642bb$23e007c0$1b12c055@genie> <200603081756.36597.dgw@liwest.at> <002001c642d9$320fcab0$1b12c055@genie> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38745E82-AD24-4E84-B697-AA4D13794FB1@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 8 Mar 2006 13:34:11 -0500 To: Eugene X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: "freebsd-questions@freebsd.org List" Subject: Re: Strange memory problems 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, 08 Mar 2006 18:34:16 -0000 On Mar 8, 2006, at 12:52 PM, Eugene wrote: >>> With Apache stopped, it goes down to RSS=0.5GB and VSZ=0.6G -- >>> but Inactive >>> Memory remains above 2.5GB. >>> Is it a memory leak somewhere or what? >> >> That looks quite normal to me, apart from the zombie process. >> FreeBSD always >> attempts to occupy most of the RAM, because it's a very fast way >> of saving >> information, and after all a lot of RAM is of no use if there's >> nothing in >> it. So long as no other program needs it for more "important" >> information, >> there's nothing wrong with keeping a lot of "unimportant" stuff >> around in >> case it is needed again quickly. > > Ok, that's nice. However, I was concerned not so much with low Free > memory as with Act+Inact being 1.5-4 times greater than size of > running processes. What data is there, exactly? I don't think it > has more than 1GB of unsynced disk writes? No. It's caching all of the pages used by processes which have not needed to be paged out yet. The syncer process will regularly flush dirty pages to disk, so the amount of unsynced disk writes is going to be much smaller. > Also, a more general question: how do I estimate 'real' memory > load? Sum(RSS) + 0.5*DiskCache ? > For example, I would like to know (in advance) e.g. how many Apache > processes we can handle before memory becomes a problem. The instantaneous 'real' memory load is the Active column, plus the KVA (wired down memory) and the disk cache. You can divide the amount of (inactive + free) by the size of each apache httpd, and get an upper bound on the number of extra httpd's you can probably run. Paying attention to your page fault rate is a better way of tuning, however. > Do you think it would be nice if top(1) could give some > consolidated measure -- probably taking into account usage > statistics and/or response time? Top already attempts to give useful measurements. > Or at least two measures -- e.g. "How much memory can be allocated > off-hand without any disk I/O" You can allocate an almost unlimited amount of memory, so long as you don't actually write to it; FreeBSD uses VM overcommit extensively. > and "How much memory can be allocated so that swapped data would > not have to be re-read again in reasonable time"? That's the "inactive" entry in top, more or less. -- -Chuck