Synopsis of 4.03 Memory Managment Question
2007-12-25 7:13:00
performance problems with a 4/370. No one had a solution to my
problem. A few basically said no one has an answer to my problems. I
will give a brief synopsis of the responses below and then
follow that with the actual letters.
Several people suggested that we might have insufficient swap space,
less than 56 megabytes. The machine in question has about 300 megabytes
of swap space. I doubt this is the problem. Here is the result of
a "pstat -s":
nugodot.think.com {1} pstat -s
84344k allocated + 40056k reserved = 124400k used, 171256k available
Barry Boes wrote to say our problem is not swapping. He suggested
the problem is due to ethernet traffic. We disagree strongly
with that analysis. Barry, take another look at the output of
vmstat. Also note that average ethernet traffic in this machine
during the day is about 50 packets/sec in and 50 packets/sec out.
Not that much.
Conrad Huang has talked with Sun and says they say the answer to my
questions (Is there a way to limit the total amount of
memory available to memory mapped files? Is there
any way to see how much memory the mapped files
are using? Is there any way to get an inode number
for a file using a lot of memory?) is no. Thanks Conrad,
I expected that. Not that it makes me feel any better.
He also says there is a Usenix Conference article describing
the memory system. If I can find it, I will let you guys
know. If anyone has a copy, drop me a line.
Guy Harris also says there is no way to look at memory mapped
files. He gives a succinct explanation.
Mark Weiser sent a note about problems with the memory
manager when the maps are larger than 32MB. I do not
think this is the problem with this machine, but I will
look at it with this in mind.
The Letters
**************************************************************
>From boes@Corona.ITD.MsState.Edu Tue Jun 12 08:47:23 1990
From: Barry Boes <boes@Corona.ITD.MsState.Edu>
Before I even get into the explanation of what you're
seeing, I'll go ahead and tell you that your performance
degradation is definitely NOT in the system swapping. It
looks like you're swapping an average of maybe 2 pages
a second. That's such a small overhead as to not even be
measurable.
Now for the explanation. In order to increase the
speed of its swapping, sun set up it's swapper so that every
time a new page is written to memory, it is also written to
swap. This causes some swapping overhead in the beginning
that might not be necessary but is there to speed things up.
That will explain the infrequent swap outs that you see. Not
enough to make any measurable performance difference, but enough
to see. Why does it speed things up? Because since the page
was written to swap, if it is determined free by the system, it
is still stored until that page is needed for new swap data. If
the program that originally used that page decides after it has
been put on the free list that it wants it again, the kernel is
smart enough to retrieve it from the free list rather than go
to normal disk for it.
It looks to me by your vmstat that you are not either
CPU limited or swap limited. If I were you I would look for
the bottleneck in the ethernet traffic.
-Barry Boes phone : 601-325-2240
Computer Engineer e-mail : boes@ITD.MsState.Edu
The Institute for Technology Development
1 Research Boulevard
Starkville, MS 39759
>From larson@csd460a.erim.org Tue Jun 12 08:54:16 1990
Subject: 4.03 memory management
Sid,
Make sure that you have at least 58MB of swap space. SunOS will not use
physical memory for which it does not have swap space. Swap space should be
at least memory-size plus approximately 2MB.
If you do not have enough swap space allocated, a quick fix (or long term
for that matter) is to turn on swapping to a file on the partition of your
choice.
Good luck,
Eric (larson@csd460a.erim.org)
>From bill@cvs.rochester.edu Tue Jun 12 09:06:48 1990
From: Bill Vaughn <bill@cvs.rochester.edu>
Sid:
You need to check how much swap space you have allocated on the server
Status: RO
with 'pstat -T'. With 56Mb of memory you'll need to have at least that much
swap space on disk. Otherwise not all your memory will be used. It's a
strange way to setup virtual memory, but that's the way Sun did it. I still
haven't heard a clear explanation of why it has to be that way. But with only
8 and 16Mb machines, we've never experienced the problem.
Bill Vaughn
>From brossard@litsun.epfl.ch Tue Jun 12 10:10:12 1990
From: "(Alain Brossard)" <brossard@litsun.epfl.ch>
==================
I find that top (and xperfmon) don't always give the right
amount of free memory: used + free != total. This is true
both for 4.0.3 and 4.1 for Sun3's. For example if I start a program
that allocates 10MBytes of memory and writes to it, top will show
that used memory grows while the free amount stabilizes at about
200-300K. If I then kill my program, the amount of free memory showed
by top will grow to include all the memory used by my program and will
then take it into account. It looks like the memory has to be used
at least once before top can see it.
I'm also wondering why is the kernel swapping out programs when
there is more than 8 MBytes of unused memory. I'm not saying it is
writting out the programs to swap, it always does that I think, I'm
saying the amount of resident memory drops to 0 when there is no need
to do that.
If you get any usefull answers, please let me know.
Alain Brossard
>From kwthomas@nsslsun.gcn.uoknor.edu Tue Jun 12 11:22:33 1990
From: kwthomas@nsslsun.gcn.uoknor.edu (Kevin W. Thomas)
How much space do you have configured for swap? Swap must be at least as
large as memory. If the size of swap is less than the size of memory, then
not all of your memory will be used.
Kevin W. Thomas
National Severe Storms Laboratory
Norman, Oklahoma
From: conrad@zeno.mmwb.ucsf.EDU (Conrad Huang)
In comp.sys.sun.managers you write:
>We are using a 4/370 with 56 megabytes of memory as
>an X client server. When watching the system with
>vmstat -S, we see there is 20 megabytes of memory available.
>Top and ps show processes only using around 8 megabytes
>of memory. We figure the other 28 meg is used by memory mapped
>files. This would be okay, except the performance of
>the system is poor. Is there a way to limit the total amount of
>memory available to memory mapped files? Is there
>any way to see how much memory the mapped files
>are using? Is there any way to get an inode number
>for a file using a lot of memory?
The last time we tried to get this information from Sun, the answer
to all your questions in *no*. In fact, there is no way to know what
memory is used for at all, even for Sun. They had/have absolutely no
metering code at all in the kernel (and it's still *huge*).
>I have included the output of "vmstat -S 2" and "top -u".
>Note that vmstat shows 18 megabytes free and yet there is
>paging and swapping activity. Why this is happening with
>32% of memory available is not clear. Does anyone understand
>the Sun memory management scheme? Is this documented somewhere?
They said that there is a Usenix Conference article describing the
memory system and that perhaps our salesman can find it for us. Since
we had to figure out how our memory is being used, and there was no
way to do that, we just dropped the whole thing and prayed.
If you find out anything different than the above, please let me know
as we are still curious about why 8meg SparcStations page incessantly.
Thanks,
Conrad Huang
>From auspex!guy@uunet.UU.NET Tue Jun 12 15:20:27 1990
From: auspex!guy@uunet.UU.NET (Guy Harris)
> Is there a way to limit the total amount of memory available to
> memory mapped files?
No. See below....
> Is there any way to see how much memory the mapped files
> are using?
No. *ALL* of the page pool is being used either for mapped files or for
"anonymous pages" (i.e., pages backed by swap space - for example, stack
space, copy-on-write pages that have been copied, BSS pages that have
been demand-zeroed, S5 shared memory, etc.).
"read()", for example, in both the UFS and NFS file systems, is
implemented in the kernel by mapping regions of the file into the
kernel's address space and copying from that region into user space.
Shared libraries, and demand-paged executables, are also implemented by
mapping the executable or shared library file into the address space of
the process.
>From jrich@ucrmath.ucr.edu Tue Jun 12 15:49:19 1990
From: jrich@ucrmath.ucr.edu (john richardson)
How much swap space do you have?
There was a brief flurry recently, the upshot of it
being that UNIX must match every active memory page with
a swap page at boot time. If you have less swap than
physical memory, UNIX ignores the extra memory.
-------------------------------------------------------------------------------
John Richardson, System Administrator Internet: jrich@ucrmath.ucr.edu
Dept. of Math & Computer Science uucp: uunet!ucrmath.ucr.edu!jrich
Univ. of Calif., Riverside, CA 92521 phone: (714) 787-3236
>From dmorse@sun-valley.Stanford.EDU Tue Jun 12 21:49:57 1990
From: dmorse@sun-valley.Stanford.EDU (Dennis Morse)
How much swap space do have allocated on disk? You need at least as much
swap space as memory for all the memory to be used. With 56 Mbytes of
memory you should have at least 75 Mbytes of swap space on disk and a 100
would probably be better.
Dennis Morse Office: 415.723.1260
Aerospace Robotics Laboratory Lab: 415.723.3608
Department Aeronautics & Astronautics
Durand Building, Room 250
Stanford, CA 94305
E-mail: dmorse@sun-valley.stanford.edu
>From briggs.pa@Xerox.COM Wed Jun 13 20:28:07 1990
Sid,
I forwarded your question to someone who had experienced memory problems
here at PARC, and been tracking it down with Sun. Here's his response.
----- Begin Forwarded Messages -----
From: Mark Weiser <mark@arisia.Xerox.COM>
To: briggs@Xerox.COM
Yes, Sun's memory management is not good at all for lots of memory.
Our main trouble is that the memory mapping hardware on sparcstations
cannot map more than 32MB at once, and even if two processes are sharing
pages they need different maps. The result is tht the 32MB limit
is easily exceeded even on a 16 MB machine.
When it is exceeded, even slightly, SunOS does not behave well at all,
essentially thrashing in the kernel trying to keep the MMU filled.
The symptom of this is high % system time even for your cpu bound
processes.
But it does not show up as paging and swapping activity, so I am not
sure that is the same as Sid's troubles.
To answer his specific question, no, there is no way in 4.0.3 or 4.1 to
limit the amount of memory allocated to files. However, 4.1 is supposed
to do this more intelligently. 4.1 does NOT manage the MMU more
intelligently.
-mark
----- End Forwarded Messages -----
Comments
Got something to say?
You must be logged in to post a comment.
