I got a lot of responses to my questions. I'm summarizing them below.
Thanks to all those who took the time to respond.
First of all, here is a copy of the questions:
-------------- Start -------------------------
Hi,
I have two questions.
1.
We have a Sparcstation-1 with 8 Mb memory and 14 Mb swap space. I could not
bring up my program (with 31000 symbols, occupying 1359872 bytes on disk)
under dbx. dbx would quit saying "Not enough memory".
Recently we added an additional 16 Mb of memory to our system. When the system
boots it reports finding 24 Mb of memory, but the problem still remains.
When I try to run dbx, I have the following programs already running:
clocktool
mailtool
calculator
the console
two cmdtools running csh
vi, editing an 8k file.
I thought that this could have to do with the "pmeg" bug and tried to fix it
by making the variable nosched = 1 in /vmunix and rebooting. It did not make
any difference.
Could someone tell me what's going on ?
2.
To increase the swap space for the Sparcstation, I tried to swap over the
net, through NFS. I tried the following:
a. on the remote machine, create the swap file with the command
"mkfile 5M /files/swapfile"
The remote machine exported /files.
b. on the Sparcstation, make the following entry in /etc/fstab:
/net/remote_machine/files/swapfile swap swap rw 0 0
c. run the command "swapon -a" on the Sparcstation to use the
swap space on the remote machine.
Things seemed to work for a while, but eventually the Sparcstation crashed
with the message: "panic: error swapping in u area" (the actual message
could have been slightly different).
The question is, what is the proper way to swap through NFS ?
-------------------- End --------------------------
Summary:
--------
Question 1:
-----------
>>> You need to have at least as much swap space as physical memory, else your
>>> extra memory will not be used by unix. Increase your swap and all will be
>>> well.
--> the problem is not the physical memory, it's the swap space .
--> you must have at least as much swap space as phys. mem.
-->
--> We have 25MB swap with our 16MB SparcStations.
>>> Under real (ie., BSD) Unix, swap space is used as a real backing store,
>>> so the size of the swap space is the size of your virtual memory. If
>>> you've got 24 meg of physical memory but only 14 meg of swap, your
>>> machine is only going to use 14 meg. Your swap should *always* be >
>>> your physmem.
--> ... did you increase the swap space at the same time? If you
--> only have 14 MB of swap space then even if you have 128 MB of real memory
--> you only have 14 MB of virtual memory. The rest of the physical memory is
--> wasted.
>>> Your swap space is insufficient. We use 50 - 60 MB as a rule.
I increased the swap space to 30 Mbytes (by "mount"ing the remote swap file
rather than depending on the automounter) and things worked fine.
Question 2:
-----------
>>> Mount the /files directory directly -- in the above example it looks>
>>> like you're using the automounter. In the words of George Bush, that's
>>> Baaaaadd..Real Baaaaad. If no pages happen to be swapped (very
>>> possible if you've got 24Mb of memory), the automounter will unmount
>>> your swap area. OUCH!
An example from another response:
>>> We added swapspace to 'antares' on 'duttnph'. From /etc/exports on duttnph:
>>>
>>> /export/swap/antares2 -root=antares,access=antares
>>>
>>> On antares in /etc/fstab:
>>>
>>> duttnph:/export/swap/antares2 /mnt nfs rw 0 0
>>> /mnt swap swap rw 0 0
>>>
>>> Of course we had the mkfile before, and ran swapon -a. Works perfectly.
>>> Duttnph is a 4/280, antares a 4/110. All running 4.0.1.
So the problem was that I was relying on automount to do the
mounting. automount unmounts a filesystem if it's not used for x amount of
time.
pmeg bug:
---------
In question 1, I had mentioned the pmeg bug. Here are the related responses:
>>> The "pmeg bug" only makes performance go through the floor, it does not
>>> prevent things from running. Changing nosched only makes the computer
>>> turn off swapping.
--> The pmeg bug affects performance, but it doesn't cause programs to die.
--> Changing the nosched variable doesn't fix the pmeg problem.
Again, thanks for the help.
Hari
uunet!matrix!hari
Matrix Computer Systems, Inc.
7 1/2 Harris Rd.
Nashua NH 03062
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:00 CDT