<html>
<body>
<br>
sigh...<br><br>
Yes, it appears RH in their continued wisdom has changed vmstat.<br>
It was fine for 15 years! Every time someone wants to
complete<br>
his Masters thesis, they do something to something Linux. :-))<br><br>
si and so are for memory swapping, not only page swapping.<br>
These should always be zero, or you will notice the slow down.<br><br>
I am trying to leave some of the technical detail out for clarity<br>
at the risk not being complete...<br><br>
In general pi/po will indicate memory swaps when there is not
enough<br>
memory for currently executing processes, such that it must swap<br>
out one process for another to execute it. The scheduler attempts
to<br>
select a process that is using physical memory that has either not<br>
used the CPU in a long while, (Could be blocked waiting on I/o), or<br>
if in the scenario all processes are heavy, the one most recently<br>
allocated the CPU is swapped. (This is so, because the scheduler<br>
knows that the last process allocated the CPU will be last to be<br>
re-allocated the CPU). I hope this makes sense.<br><br>
For US, the users, if you regularly have anything other than 0 in<br>
there.... add more RAM.<br><br>
Now good news is they added a utility called "Top", which
I<br>
won't cover here as it has a lot of documentation, but is more<br>
complex than we need.<br><br>
There is a utility "free". This shows memory usage in a
way<br>
you will be able to see the amount of actual allocation.<br><br>
free -lt<br><br>
Now Redhat is a bit different than Unix in how it uses memory.<br>
(It's scheduler is not quite as smart one could say, or actually<br>
one could argue it is adaptive.)<br><br>
It will load the application multiple times in to physical memory<br>
for speed. This makes sense... It is "free" anyway....
But you can<br>
see the effect of "sharing" by doing a simple test:<br><br>
Run "free -lt"<br><br>
Start up an invocation of COD<br><br>
Run "free -lt"<br><br>
Note the amount of physical ram usage went up! Note the approx
amount<br>
by subtracting the later number from the first.<br><br>
Continue to start up invocations of COD. After each start, run "free
-lt"<br>
again.<br><br>
For the first few, you should see the physical memory usage go down<br>
the same amount after each start, as multiple copies of code pages<br>
are loaded in to physical ram.<br><br>
Continue to do this. At SOME POINT, depending on how much<br>
ram you have, you will notice after you start a new process, the<br>
amount of physical ram will NOT increase the same as it did in<br>
the case of the first 3 invocations of COD.<br><br>
Redhat is now SHARING code pages. The physical ram being<br>
allocated is for HEAP and STACK memory segments.<br><br>
Now here is a hint... if you want you COD to always be able to<br>
load code pages quickly, set the "Sticky" bit on the COD<br>
executable. (I won't detail here, but check man page of
"chmod")<br><br>
What this does is...the following:<br><br>
When you start up a program, Unix first copies the code to the<br>
swap space, then copies code pages in to ram. When running<br>
the application, if it runs out of code pages to run, it issues a<br>
interrupt for code via an I/O request, and blocks the process.<br>
When the code is loaded in ram, and the process is ready to<br>
execute again, the process is allocated the CPU and it runs...<br><br>
If you make the COD executable "sticky" it will remain in
the<br>
swap area. In addition, when you load 4 invocations of the<br>
executable, all four invocations will use the same swap image<br>
of the code.<br><br>
Just a note... there are some details I didn't cover here. So<br>
any kernel experts out there... chill, not everything needs<br>
to have the math with it!<br><br>
This is not to say that each invocation uses NO ram.<br>
It should be clear now that:<br><br>
1. In the beginning, it uses it if it is free.<br>
2. As ram becomes "filled", it will start to SHARE code
pages<br>
3. It must allocate REAL ram for it's DATA (Heap and Stack)<br><br>
Last note... you don't need to use COD to run the test above...<br>
simply use code like say "mozilla". Start up one at a
time...<br>
you will see the physical memory usage reduce on a 512Mb<br>
system by the 4th or 5th invocation.<br><br>
It works the same with Susi, Slackware, etc. but the utilities<br>
to see this, and some scheduler differences exist. In general<br>
however, 10 copies of COD will NOT need 10 times the ram<br>
as 1 copy.<br><br>
Doc D<br><br>
-----------------------------------------------------------------------------------------<br>
Mark J. DeFilippis, Ph. D
EE<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>defilm@acm.org<br>
<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>defilm@ieee.org<br><br>
<br><br>
<br><br>
<br><br>
At 07:15 PM 5/14/2004, Richard Harrison wrote:<br>
<blockquote type=cite class=cite cite>This is a direct copy from doing
'man vmstat' on my rh9 box. Hope it helps you.<br>
<br>
FIELD DESCRIPTIONS<br>
Procs<br>
r: The number of processes waiting
for run time.<br>
b: The number of processes in
uninterruptable sleep.<br>
w: The number of processes swapped
out but otherwise runnable. This<br>
field is
calculated, but Linux never desperation swaps.<br>
Memory<br>
swpd: the amount of virtual memory
used (kB).<br>
free: the amount of idle memory
(kB).<br>
buff: the amount of memory used as
buffers (kB).<br>
Swap<br>
si: Amount of memory swapped in from
disk (kB/s).<br>
so: Amount of memory swapped to disk
(kB/s).<br>
IO<br>
bi: Blocks sent to a block device
(blocks/s).<br>
bo: Blocks received from a block
device (blocks/s).<br>
System<br>
in: The number of interrupts per
second, including the clock.<br>
cs: The number of context switches
per second.<br>
CPU<br>
These are percentages of total CPU
time.<br>
us: user time<br>
sy: system time<br>
id: idle time<br>
<br><br>
<br>
<b><i>Michael Neikes <michael@neikes-net.de></i></b> wrote:<br>
<dl>
<dd><?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" /> <br><br>
<dd><font face="arial" size=2 color="#000080">Hi list,<br>
</font><br>
<dd><font face="arial" size=2 color="#000080"> <br>
</font><br>
<dd><font face="arial" size=2 color="#000080">perhaps there is a
misunderstanding because of my english knowlede.<br>
</font><br>
<dd><font face="arial" size=2 color="#000080">Perhaps it is also a
difference between MoH and CoD.<br>
</font><br>
<dd><font face="arial" size=2 color="#000080">I run vmstats and do only
see si and so (perhaps the s for suse!?), but I think it’s the same as pi
and po.<br>
</font><br>
<dd><font face="arial" size=2 color="#000080">I have got a zero in there,
so I am not swapping, right?<br>
</font><br>
<dd><font face="arial" size=2 color="#000080">“</font>doesnt take up any
more RAM<br>
<dd>to run multiple
installations”<font color="#800080">-></font><font color="#000080">
does not seems to work within MoH.<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">I run multiple
installations with all their pathes, etc.<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">e.g. every server
takes 10% of RAM.<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">When I run one
installation multiple times, I do also have multiple processess á 10% of
RAM,<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">So it seems they
are not “sharing” the same code of RAM.<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">Is it an issue
from MoH?<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080"> <br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">Sorry for a MoH
issue at this list.<br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080"> <br>
</font><br>
<dd><font face="Times New Roman, Times" color="#000080">Michael<br>
</font><br>
<dd><font face="arial" size=2 color="#000080"> <br>
<hr>
<div align="center"></font></div>
<dd><font face="tahoma" size=2>Von:</b> Orr, Roland Cadet
[<a href="mailto:orr@cadetmail.uscga.edu" eudora="autourl">mailto:orr@cadetmail.uscga.edu</a>]
<br>
<dd>Gesendet:</b> Freitag, 14. Mai 2004 06:17<br>
<dd>An:</b> <?xml:namespace prefix = st1 ns =
"urn:schemas-microsoft-com:office:smarttags"
/>cod@icculus.org<br>
<dd>Betreff:</b> RE: [cod] Multiple Servers on one box and PB<br>
</font><br>
<dd><font face="Times New Roman, Times"> <br>
</font><br>
<dd><font face="Courier New, Courier" size=2>fascinating!!! thank you for
that helpful insight!!! (feel free to send more emails on the intricate
innerworkings of linux)<br>
</font><br>
<dd><font face="tahoma" size=2>-----Original Message-----<br>
<dd>From:</b> Mark J. DeFilippis
[<a href="mailto:defilm@acm.org" eudora="autourl">mailto:defilm@acm.org</a>]<br>
<dd>Sent:</b> Thursday, May 13, 2004 10:45 PM<br>
<dd>To:</b> cod@icculus.org<br>
<dd>Subject:</b> Re: [cod] Multiple Servers on one box and PB<br>
</font><br>
<dd><font face="Times New Roman, Times">At 03:03 PM 5/10/2004, Andrew Urm
wrote:<br><br>
<dd>Additional server instances don't take up more RAM? Really? Or were
you saying something else?<br><br>
<dd>Andrew<br><br>
<dd>luke@techfreak.org wrote:<br><br>
<br>
<dd>Of course, there is a more 'elegant' way, but the guy is trying
to<br>
<dd>get his feet wet here. So, I suggested an easy method.<br>
<dd>Also, I have run test after test and it doesnt take up any more
RAM<br>
<dd>to run multiple installations, as opposed to using base_path. Or
are<br>
<dd>you taking about using disk space?<br>
<dd>Luke<br>
</font><br>
<font face="Times New Roman, Times"><br><br>
<dd>Additional instances do not take up more ram because the first
instance<br>
<dd>pulls the executable page code in to swap space in Unix/Linux. If
you<br>
<dd>have enough RAM, (and that is critical, or it Unix/Linux will need to
page<br>
<dd>swap, and there goes the lag game.. This falls on basic design theory
for<br>
<dd>Unix... You can never have enough ram. You always want to have enough
RAM<br>
<dd>to run your programs in ram, or you will page swap. Page swap =
slow,<br>
<dd>without getting in to the nasty details). How can I tell if I
am page swapping?<br><br>
<dd>run " vmstat". Check the man page for vmstat.
You will see a PI and PO,<br>
<dd>these should be zero. If not, you are swapping in pages of code to
execute.<br>
<dd>Add more ram, and you may have to relink the kernel, but most
Unix/Linux<br>
<dd>version support up to 4GB or more for 32 bit.<br><br>
<dd>The way it works is this.... Code for each game will execute in ram,
and<br>
<dd>share the page, but each will get their OWN data area's for Heap
and<br>
<dd>Stack.<br><br>
<dd>However, if one process (Game running) attempts to write to a
code<br>
<dd>page, Linux will do a "Copy on Fork()". This is viewable in
vmstat<br>
<dd>as well. Basically it means that "A copy using the shared
code attempted<br>
<dd>to modify it, so it make a separate copy for the process that
attempted to<br>
<dd>write to the code base".<br><br>
<dd>Since this does not happen in COD, or most processes for that
matter,<br>
<dd>they all share the same single image in Swap to load to ram, and
the<br>
<dd>same single image of code in RAM. If you were to put the
processes<br>
<dd>in debug, and look at the registers, you would see the code
segment<br>
<dd>registers are all the same, but the data pointer registers are all
different.<br><br>
<dd>Check out vmstat, and read the man page. It is worth your time.<br>
<dd>It will give you some good insight on how the resources are
allocated...<br><br>
<dd>Nice huh? Someday Windows will really work like that, or
maybe<br>
<dd>it will replace windows? {;-))<br><br>
<dd>MFrag<br>
<dd>{TRv}Team-Ravage<br>
<dd>aka. Mark J. DeFilippis, Ph. D EE<br><br>
<br><br>
</font>
<dd><tt><font face="Courier New, Courier" size=2>-------------------------------------------------------------------------------</font></tt><br>
<dd><tt>Mark J.
DeFilippis
defilm@acm.org</tt><font face="Courier New, Courier" size=2><br>
</font>
<dd><tt>
defilm@ieee.org</tt><font face="Courier New, Courier" size=2><br>
</font></blockquote>
<x-sigsep><p></x-sigsep>
</dl><tt>-------------------------------------------------------------------------------<br>
Mark J.
DeFilippis
defilm@acm.org<br>
defilm@ieee.org<br><br>
<br>
</body>
</html>