mfriedel@slate.mines.colorado.edu (Friedel Michael) (04/15/91)
After I boot my NeXTstation I typed vm_stat which is supposed to list the status of the virtual memory. Here is the result: Mach Virtual Memory Statistics: (page size of 8192 bytes) Pages free: 62. Pages active: 263. Pages inactive: 970. Pages wired down: 133. "Translation faults": 9249. Pages copy-on-write: 1970. Pages zero filled: 954. Pages reactivated: 3767. Pageins: 792. Pageouts: 77. Object cache: 953 hits of 1116 lookups (85% hit rate) My system is 12meg (of which 11 meg are available, 1meg is reserved by the system at boot time for buffers, so it tells me). The swapfile has a size of 20971520 bytes after the machine is done booting. Now no matter how I twist my math, I can't come up with enough pages that justify a 20meg swapfile. So does anyone know to do the correct math, does vm_stat list incorrect statistics or does the system just forget about a few pages ? -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ No user serviceable part inside. Warranty void if opened modified or tampered with. No batteries included. *
benseb@nic.cerf.net (Booker Bense) (04/16/91)
In article <1991Apr15.153504.39750@slate.mines.colorado.edu> mfriedel@slate.mines.colorado.edu (Friedel Michael) writes: >After I boot my NeXTstation I typed vm_stat which is supposed to list >the status of the virtual memory. Here is the result: [ vm-stat stuff deleted ] > >My system is 12meg (of which 11 meg are available, 1meg is reserved >by the system at boot time for buffers, so it tells me). >The swapfile has a size of 20971520 bytes after the machine is done >booting. Now no matter how I twist my math, I can't come up with >enough pages that justify a 20meg swapfile. >So does anyone know to do the correct math, does vm_stat list incorrect >statistics or does the system just forget about a few pages ? > -RTFM %-)! if you have it %-(! , the swap file has a low water mark set in the file /etc/swaptab ( or something like that ). It's set so the swapfile is never shrunk to less than 20 MB. The rule of thumb is that the low water mark of the swap file should be twice the real memory. You can think of this a ``reserved space'' on your disk, so the system won't run out of swap space when it needs it. Now, for an 8 meg system 20 meg sounds a bit large. Since my 200 Meg disk is rather cramped, I'd like to ask the NeXTperts, if you think it'd be safe to set the low water mark lower ( like 16 meg ) . What kind of bad things happen to the OS when it runs out of swap disk? - Booker C. Bense prefered: benseb@grumpy.sdsc.edu "I think it's GOOD that everyone NeXT Mail: benseb@next.sdsc.edu becomes food " - Hobbes
zazula@uazhe0.physics.arizona.edu (RALPH ZAZULA) (04/17/91)
In article <332@nic.cerf.net>, benseb@nic.cerf.net (Booker Bense) writes... >In article <1991Apr15.153504.39750@slate.mines.colorado.edu> mfriedel@slate.mines.colorado.edu (Friedel Michael) writes: >>After I boot my NeXTstation I typed vm_stat which is supposed to list >>the status of the virtual memory. Here is the result: >[ vm-stat stuff deleted ] >> >>My system is 12meg (of which 11 meg are available, 1meg is reserved >>by the system at boot time for buffers, so it tells me). >>The swapfile has a size of 20971520 bytes after the machine is done >>booting. Now no matter how I twist my math, I can't come up with >>enough pages that justify a 20meg swapfile. >>So does anyone know to do the correct math, does vm_stat list incorrect >>statistics or does the system just forget about a few pages ? >> > > >-RTFM %-)! if you have it %-(! , the swap file has a low water mark >set in the file /etc/swaptab ( or something like that ). It's set so >the swapfile is never shrunk to less than 20 MB. The rule of thumb is >that the low water mark of the swap file should be twice the real >memory. You can think of this a ``reserved space'' on your disk, so >the system won't run out of swap space when it needs it. Actually, RTFMing didn't shed any light on this for me either. The command 'vm_stat' seems to be a misnomer. Maybe it should be 'rm_stat' for real-memory-statistics. If I add up the pages shown in a vm_stat, I get the 11 MEG that my machine (12 Meg) has available, give or take a few K. What *I* would like to know is the number of pages that are in use in the swapfile. This kind of information would allow one to monitor the amount of swapfile space that is in use and determine a good size for the thing. One thing I tried was summing the VSIZE column of a 'ps augx' display. This added up to 70Meg... Not quite the size of my 20Meg swapfile plus 12Meg RAM. I'm not quite sure what that meant... > > Now, for an 8 meg system 20 meg sounds a bit large. Since my 200 Meg >disk is rather cramped, I'd like to ask the NeXTperts, if you think >it'd be safe to set the low water mark lower ( like 16 meg ) . What >kind of bad things happen to the OS when it runs out of swap disk? > >- Booker C. Bense >prefered: benseb@grumpy.sdsc.edu "I think it's GOOD that everyone >NeXT Mail: benseb@next.sdsc.edu becomes food " - Hobbes Ralph |----------------------------------------------------------------------| | Ralph Zazula "Computer Addict!" | | University of Arizona --- Department of Physics | | UAZHEP::ZAZULA (DecNet/HEPNet) | | zazula@uazhe0.physics.arizona.edu (Internet) | |----------------------------------------------------------------------| | "You can twist perceptions, reality won't budge." - Neil Peart | |----------------------------------------------------------------------|
gerrit@sequent.com (04/18/91)
Several people ask why the swap file is larger than it seems to need to be and if it can be smaller than it is. First, it is statically allocated to the size specified in /etc/swaptab at boot. Sure, this number can be smaller; I often set it to 16 Meg on some smaller machines. If necessary (and possible!) the OS will allow the file to grow if your applications need more swap space. However, by staking out a claim to 16 or 20 Meg from the very beginning, you can lessen the chance that your application will be killed due to lack of swap space when your disk fills up. You could probably even make the size of the swap file as small as 12 meg without noticing any real differences for a while (I haven't tried this one though). The catch is that if you do any "real" work on the machine (i.e. using more than 4-5 NeXT Apps at a time), the swap file is quite likely to grow back to what it used to be. Something to try would be to set it to 8-10 Meg, run with your standard environment for a while and see how large the file is. Then you can pre-allocate the space to match your needs, be they 6 Meg or 80 Meg. Running out of swap space can cause all kinds of bad things to happen, so it is better to run out of disk space with a comfortable size swap file allocated. gerrit
louie@sayshell.umd.edu (Louis A. Mamakos) (04/18/91)
In article <1991Apr17.174031.28031@sequent.com> gerrit@sequent.com writes: >However, by staking out a claim to 16 or 20 Meg from >the very beginning, you can lessen the chance that your application will >be killed due to lack of swap space when your disk fills up. The other reason to pre-allocate the swapfile to be used for paging rather than having the file grow later on is performance. The pre-allocated swapfile will have its diskblock located "close" together so that multi-block transfers can be accomplished without having to seek to a different cylinder to fetch the next block. The Berkeley fast file system attempts to keep the blocks for a file close together, but when the disk begins to fill up, most of the bets are off (especially on the 105MB disk where minfree is set to 5% rather than default 10%; this is a space vs. time tradeoff). louie "You can tune a file system, but you can't tune a fish."
jwright@cfht.hawaii.edu (Jim Wright) (04/18/91)
When I upgraded to 24MB of RAM, I truncated the swap file. E.g., immediately
after rebooting (hence no application was using the swap file)
cat /dev/null > /private/vm/swapfile
shutdown -r now
It's been about 2 weeks, and it has yet to grow to 1MB. On startup I run
Workspace, Preferences, Webster, Digital Librarian, and three Terminal
windows. I also run a variety of other applications during a session.
Of course the swapfile may grow as needed, but until then I've got about
20MB of disk space back.
gerrit@sequent.com writes:
>Several people ask why the swap file is larger than it seems to need to
>be and if it can be smaller than it is. First, it is statically allocated
>to the size specified in /etc/swaptab at boot.
The way I read the documentation, at boot time the swap file is pruned
back to the "lowat" size if it is larger. During run time, the swap
file is not allowed to exceed the "hiwat" size. There is no "static
allocation" at boot time.
>However, by staking out a claim to 16 or 20 Meg from
>the very beginning, you can lessen the chance that your application will
>be killed due to lack of swap space when your disk fills up.
The minfree setting for the disk should cover your butt. User applications
should complain about "disk full" long before the operating system exhausts
all disk space.
>You could probably even make the size of the swap file as small as 12 meg
>without noticing any real differences for a while (I haven't tried this one
>though). The catch is that if you do any "real" work on the machine (i.e.
>using more than 4-5 NeXT Apps at a time), the swap file is quite likely to
>grow back to what it used to be.
If you've got enough memory, I'd recommend cutting back the swap file.
24MB RAM + 1MB swap is much faster than 8MB RAM + 20MB swap (especially
on optical!)
>Running out of swap space can cause all kinds of bad things to happen, so
>it is better to run out of disk space with a comfortable size swap file
>allocated.
I don't think running out of swap on the NeXT will be as much of a problem
as on other unix machines. The NeXT swaps to a file, which can grow to
fill the available space. Your applications will complain before you get
too far. On systems where there is a swap partition, once that partition
fills you're hosed. And you may not have much indication of when that is
happening, other than poor system performance.
In summary, I can't think of a reason not to prune the swap file. It should
give you an idea of what your real memory requirements are.
--
Jim Wright
jwright@cfht.hawaii.edu
Canada-France-Hawaii Telescope Corp.bennett@mp.cs.niu.edu (Scott Bennett) (04/22/91)
In article <1991Apr15.153504.39750@slate.mines.colorado.edu> mfriedel@slate.mines.colorado.edu (Friedel Michael) writes: >After I boot my NeXTstation I typed vm_stat which is supposed to list >the status of the virtual memory. Here is the result: > >Mach Virtual Memory Statistics: (page size of 8192 bytes) >Pages free: 62. >Pages active: 263. >Pages inactive: 970. >Pages wired down: 133. >"Translation faults": 9249. >Pages copy-on-write: 1970. >Pages zero filled: 954. >Pages reactivated: 3767. >Pageins: 792. >Pageouts: 77. >Object cache: 953 hits of 1116 lookups (85% hit rate) > >My system is 12meg (of which 11 meg are available, 1meg is reserved >by the system at boot time for buffers, so it tells me). >The swapfile has a size of 20971520 bytes after the machine is done >booting. Now no matter how I twist my math, I can't come up with >enough pages that justify a 20meg swapfile. You probably have lowat=20971520 either in /etc/swaptab or /etc/rc.swap (or wherever.) That means that once your swapping/paging area has grown to at least 20MB, it will never shrink to less than 20MB. If you start up several NeXTStep applications, the swapping/paging area can *easily* grow beyond 20MB. NeXTStep apps are not small. Some apps also tend to grow while they run. Try watching how big Mathematica is from time to time during one execution. >So does anyone know to do the correct math, does vm_stat list incorrect >statistics or does the system just forget about a few pages ? > No. The problem here is a literacy problem on the part of the author(s) of vm_stat. Data General is similarly illiterate w.r.t. their AOS/VS system and probably many other vendors' software teams would also fit the bill. The confusion arising from vm_stat's output is the failure to distinguish between "pages", which are the contents of a process's address space, and "page frames", which are blocks of physical memory into which pages are placed for use. A page can be "fixed" or "wired" (depending on your dialect:-) into a page frame, which prevents the page from being paged out to free the page frame that it occupies. So, the first line of data should be Page frames free: 62. The next two lines refer to the *usage* of pages, but only of pages currently in physical memory, i.e. in page frames. I suppose one could argue that they could be labeled validly as they are, but since they can be added together along with number of free page frames to get the number of page frames in your computer, I'd like to see them labeled as shown below. Note also that they do *not* provide similar information regarding the total number of *pages* in the system, which can change from moment to moment. The number of page *frames* in the system is number of 8KB blocks left over in your hardware after the kernel has grabbed everything that it needs for permanently resident stuff. Page frames active: 263. Page frames inactive: 970. This next one *is* correctly labeled, because it refers to the *pages*, though obviously a "wired down" page is in physical memory and must therefore be tying up a page frame. Note that a page frame is a fixed and permanent object (until the next boot, at least) and thus cannot be wired or unwired because it is space, not data, and can't go anywhere anyway. Pages wired down: 133. The remainder of the vm_stat output appears to be correctly labeled. Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************