[cod] Semi off topic: COD rentals

Mark J. DeFilippis defilm at acm.org
Fri Sep 24 22:59:46 EDT 2004


I had written much about this a while back. I will repeat a bit of
it here for the sake of those who wish to do this. Want to know why
you should do this, why it works and a bit on how it works...

Linking the binaries allows the CPU to share the same Code segment pages. 
Servers
will be allocated their own data segments for both Heap and Stack
(Which grow towards one another)... One of the reasons Ryan was able
to so quickly find that original prob back in 1.1.)

If there is a write attempt to the code segment, that server/user is given
their own copy. In the case of most of the shared libs in Linux, the code
is reentrant, and hence these writes don't happen.

One other recommendation, I am not certain if I made...

You can reduce the spikes you get when a server is restarted by
setting the "Sticky" bit on the executable.  (Do a man on "mode" command)
What this does is the first time the executable is loaded, the entire
executable is copies to SWAP space. Once copied to swap, executable
pages are copied in to ram to be executed.

The best way to keep a server at optimum is to never have to page.
However, under certain conditions, this does happen.  It the executable
is sticky, it remains in swap, and the page segment need only be
brought back in to memory from swap.

Also note, when a second and subsequent  user of the Sym Linked executable
starts his/her server, the executable IS NOT copied in to swap again, it uses
the one already in swap (hence the concept "sticky")... it sticks there.

Thus on new startup, A call is made to load the executable, however the
Kernel immediately updates the CS and ES code pointers to the shared
memory mbufs where the executable code exists, allocates a DS data
segment, and moves your process back to the scheduler for CPU as
your I/O is complete.

You skip the copy of the executable to SWAP.
You skip the copy of pages to Real RAM.
You execute off shared pages in memory already with your own set of executable
    registers CS, ES.  Get your data segment, and your server starts up.

Not only do you save ram, but start impact on the other servers due to I/O
DMA transfer setup, and context switching between system and user space,
but you spare the CPU spike as well.

Regards

Dr. D


At 05:08 PM 9/24/2004, you wrote:
>I just had that question recently also.  I did some research on the internet
>and a lot of peeps are doing symlinks.  I tried it with MOH:AA and it works
>beautifully, not sure if that's the "right" way to do it but it's pretty
>cool cause' you have one base install and symlinks in the other client
>folders.
>
>--
>NateDog
>
>
> > -----Original Message-----
> > From: John Kennington [mailto:john.kennington at buzzcard.gatech.edu]
> > Sent: Friday, September 24, 2004 3:04 PM
> > To: cod at icculus.org
> > Subject: RE: [cod] Semi off topic: COD rentals
> >
> > Depending on the number of cpus in the box, you can run 10 to 15 CoD
> > servers per
> > box.  So it is quite cost effective.
> >
> > John Kennington
> >
> > -----Original Message-----
> > From: Jafo [mailto:jafo at nowhere.ca]
> > Sent: Friday, September 24, 2004 3:58 PM
> > To: cod at icculus.org
> > Subject: [cod] Semi off topic: COD rentals
> >
> > Hello,
> >
> > If this isn't the forum for this question, please forgive me for asking
> > here.
> >
> > There seems like a lot of people on this list that run "server rental"
> > operations. Just curious how people are doing that cost effectively?
> > Obviously one can't run each customer's game server on seperate hardware.
> > Are people using some sort of "virtual linux" installs to run multiple
> > servers on one box with seperate IP addresses? If that is the case how
> > many servers would one dual 2.4 Xeon w/2gig RAM run?
> >
> > Thanks,
> > Jafo
> >

-------------------------------------------------------------------------------
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/20040924/f1ed03fa/attachment.htm>


More information about the Cod mailing list