[cod] Multiple Servers on one box and PB

Orr, Roland Cadet orr at cadetmail.uscga.edu
Fri May 14 00:17:05 EDT 2004


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20040514/ca5e0697/attachment.htm>


More information about the Cod mailing list