Date: Wed, 20 Feb 2002 02:33:09 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Dreamtime.net Inc." <clients@dreamtime.net> Cc: Vincent Janelle <random@carnagecopia.com>, freebsd-smp@FreeBSD.ORG Subject: Re: Systat and Ram Message-ID: <3C737B65.DF5FB115@mindspring.com> References: <AMEMLPOHFFIAJKMDAFDLKEAODOAA.clients@dreamtime.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C737B65.DF5FB115>