[cod] Semi off topic: COD rentals
Jase
shoefly at sover.net
Sat Sep 25 23:31:20 EDT 2004
Ok, thanks for clarifying that. I understand now. I have done the sticky
thing on the executable :)
I dont run servers for rent just for myself and friends :)
Jase
Mark J. DeFilippis wrote:
>
> If you are executing the same executable and can use parameters on the
> command line that is
> fine. It is the same inode. The question I was answering was for a
> person who appeared to
> not understand why, if Linux is in fact a multiuser/multi-tasking OS,
> what difference does
> it make if I load from one file or many copies of the file.
>
> In the scenario you present... if you are executing the same file, it
> is the same
> inode. Make it sticky... and you have the same as the symlink scenario.
>
> For those admins that wish to have a separate executable in the user
> space (on perhaps a server where the admin choose to have the executable
> in the users space with his other files and configs) the symlink
> method works
> very well.
>
> If your servers are being spawned by calling the same executable, you
> in fact
> are correct, you get the same benefits. For added savings on load,
> make the executable
> sticky, and your golden.
>
> Dr. D
>
>
> At 03:51 PM 9/25/2004, you wrote:
>
>> But we execute the same binary in the same path for each server&? Why
>> the symlink?
>>
>>
>>
>> ------------------------------------
>>
>> Chris Adams
>>
>> Fragzzhost
>>
>>
>>
>> T (07005) 964 855
>>
>> F (07005) 964 857
>>
>> www.fragzzhost.com <http://www.fragzzhost.com>
>>
>>
>>
>> -----Original Message-----
>> *From:* Mark J. DeFilippis [mailto:defilm at acm.org]
>> *Sent:* 25 September 2004 20:33
>> *To:* cod at icculus.org
>> *Subject:* Re: [cod] Semi off topic: COD rentals
>>
>>
>>
>>
>> You are thinking application level. This is Kernel level.
>> I spent lots of time in my career developing real time embedded coding
>> in Unix/Linux kernels.
>>
>> Look at two linuxded files that are not sym linked. But use this:
>>
>> ls -li
>>
>> Note the left side has a value called an inode. An inode is a unique
>> identifier for that file. Notice that your two files have different
>> inodes?
>>
>> When the loader goes to load code for your two servers using those
>> files, each is copied in to swap (so your swap space is n servers *
>> sizeof executable)
>> The same is true of code segments.
>>
>> If you sym link the two executables (Note they must be on the same
>> filesystem to do so. If you symlink two files on different file systems,
>> obviously Linux will have to copy the file to the new file system, and it
>> will have a new inode number. (This is because each filesystem has
>> it's own superblock, which maps Inodes to file blocks, and file names.
>>
>> The filename if only for human consumption. All Linux cares about is
>> that
>> inode number.
>>
>> anyway... If you symlink the two server files, and now do a "ls -li",
>> notice the inode numbers are the same!
>>
>> When you execute the server (with sticky bit on) it is copied to swap,
>> then pages copied in to ram and executed. When the second server
>> is executed, even though the file has a different path, it has the same
>> Inode. The linux kernel looks up the inode, and notes this inode has
>> the sticky bit set, and in fact that it already exists in Swap. It copies
>> the pointers to the code segments as I previously mentioned, and
>> begins execution.
>>
>> You ask why?
>>
>> Because 10 servers your way will load 10 copies in to swap, 10
>> copies in to memory, etc. Using the method of symlinks, which
>> is really nothing more than a link in the super block. The super block
>> maintains all information about which disk blocks belong tio which
>> files. For your simlink the new file entry simply gets the same
>> inode id copied to the table. Same inode, same code... With
>> shared libraries in memory, for the 10 servers only 1 copy
>> exists in swap. Only 1 copy exists in memory.
>>
>> I hope this is more clear.
>>
>> Dr. D
>>
>>
>>
>> At 02:18 AM 9/25/2004, you wrote:
>>
>> Guess im a little confuused here, why would you symlink when cod (all
>> quake3 base games) support multiple users. using fs_basepath and
>> fs_homepath accomplishes the same thing as symlinking doesnt it?
>> Jase
>> NateDog wrote:
>>
>>
>> Woah......now there's a guy who knows his stuff! Awesome tips man! You
>> really explain things well. Much appreciated.
>>
>> --
>> NateDog
>>
>> ----- Original Message ----- From: Mark J. DeFilippis
>> To: cod at icculus.org
>> Sent: Friday, September 24, 2004 9:59 PM
>> Subject: RE: [cod] Semi off topic: COD rentals
>>
>>
>>
>> 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
>>
>>
>>
>> ----------------------------------------------------------------------------
>>
>> S2-------------------------------------------------------------------------------
>> Mark J. DeFilippis, Ph. D EE defilm at acm.org
>> defilm at ieee.org
>
> S2-------------------------------------------------------------------------------
> Mark J. DeFilippis, Ph. D EE defilm at acm.org
> defilm at ieee.org
>
>
More information about the Cod
mailing list