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