Date: Sun, 9 Jun 1996 19:17:19 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: taob@io.org (Brian Tao) Cc: dyson@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Memory leak or reporting problem in 2.2-960501-SNAP? Message-ID: <199606100017.TAA05432@dyson.iquest.net> In-Reply-To: <Pine.NEB.3.92.960609192111.8414B-100000@zap.io.org> from "Brian Tao" at Jun 9, 96 07:30:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, 9 Jun 1996, John S. Dyson wrote: > > > > The RSS refers to the pages mapped into the process, but those pages > > may or may not be "active." Active has to do with the in-memory > > priority (sort of). Whether or not a page is mapped has little to > > do with that. > > So what should I trust if I'm evaluating the memory load on a > server? 'ps' obviously does not account for all aspects of memory > usage. I always found the breakdown in 'top' to be quite useful, > except for this one instance showing 91M active with only ~50 httpd's > and ~20 ftpd's running. > There have been complaints from other people in this area. I am staying away from the VM system for a week or two (to let others into the playpen :-)). I have been thinking about a reliable way of showing memory loading. Generally, your system will be able to sustain a very slight amount of paging without a major performance hit (if you have placed swap on disk drives that don't have competing filesystem operations.) The problem is that the system will use as much memory as it has... So, if one measures their memory loading by looking at their active page stats, then all except the most lightly loaded systems will show essentially 100% loading. I might use some of my copious spare time, staying away from the playpen, to quickly write a rough version of the utility. There are alot of other things on my plate though. It is probably best to give the system (and other developers) a chance at the VM stuff right now, so the measurement process might be a good diversion. > > > 2.2-current is MUCH MUCH better in the VM arena than snap right now. > > I have been holding off anything but simple bug fixes in current, and > > I'll commit the proposed (maybe) fix for that tonight (Sun.) > > Quick questions here (and I guess this goes back to the -stable > vs. -current discussion elsewhere)... I'm running a 2.2-SNAP and not > the recently released 2.1-SNAP. To which snapshot are you referring? > 2.2 (current) -- I very seldom look at 2.1 (stable) (except for the cases where davidg is in a pickle, and needs another helping hand.) > > It has been very painful, but the VM code is better than it has ever > > been (except for perhaps a few lurking bugs.) > > Cool, and here I thought FreeBSD's VM was already pretty much > state-of-the-art in terms of speed and efficiency. :) Thanks. > We previously handled heavy loads very well, but we lagged the L-word (however it is spelled, with or without the G :-)) in certain aspects of single user performance. Now for forks/execs we are at parity or faster even under light load (from 2.1 to 2.2 we have speeded up forks by 3x and fork/execs by about 2x.) There is another group of people working on the code, where we should see another performance increase. I guess, no matter where one is, one can ALMOST ALWAYS do better. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606100017.TAA05432>