From owner-freebsd-smp Wed Feb 20 2:33:34 2002 Delivered-To: freebsd-smp@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 1D47637B402 for ; Wed, 20 Feb 2002 02:33:27 -0800 (PST) Received: from pool0143.cvx22-bradley.dialup.earthlink.net ([209.179.198.143] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16dU3s-0002qF-00; Wed, 20 Feb 2002 02:33:20 -0800 Message-ID: <3C737B65.DF5FB115@mindspring.com> Date: Wed, 20 Feb 2002 02:33:09 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dreamtime.net Inc." Cc: Vincent Janelle , freebsd-smp@FreeBSD.ORG Subject: Re: Systat and Ram References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Dreamtime.net Inc." wrote: > Actually, we need to run anywhere from 30 to 300 httpd processes, 20-25 megs > each. We want to know how can we decide if we need more RAM based on > 'systat' output. 25M X 300 = 7.5G The question is whether these processes working sets overlap, or if this is the actual unique working set size. The numbers you want are: Total RAM - shared working set / number of processes This gives you the max per process unique working set size. I expect that the working sets will overlap. The answer to your question in this case is "No". You can't get this information from systat. But you can get it from vmstat. The numbers you want to look for are a direct effect, and a side effect: o Number of clean pages swapped in per sample interval o Number of dirty pages written to disk backing store The first number tells you how much you are thrashing, and the second number will tell you that it's getting bad, as soon as it goes non-zero, since it means you are in a paging resource overload situation (the LRU should reap clean pages to throw away before it reaps dirty pages to swap out). The only exception to this are pages dirtied during run-up, that are never dirtied again. You can see these as an early knee in the statistics. If your intent is to add an "idiot light" that lights up when your customer should upgrade their box, then you will have to write a special purpose program, so that your sample intervals are controlled (see the vmstat source code for this). On the other hand, if the intent is just scaling measurements, then you can probably get by with a check before run-up, a check after run-up, but before load, and then a short sampling interval during a load test phase (be sure you write the stats to a terminal rather than a file, so that you don't skew the measuremenets with your own disk I/O and page requirements any more than necessary). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message