Like ics said, you can't necessarily go by the amount of memory the OS
says is "used". Once a process is given some amount of memory, Linux
earmarks that memory as "used". However, if it's not actually being
used and another process needs it, it will get reallocated.
The following is the output of the 'free' command on our L4D server
(this box is running 8 forked servers):
$ free -m
total used free shared buffers cached
Mem: 7909 5683 2225 0 219 4571
-/+ buffers/cache: 891 7017
Swap: 7663 0 7663
The line you want to look at in the output of 'free' is the second line
("+/- buffers/cache"). The first line indicates that the SRCDS
processes have asked for and been given ~5.5 GB of memory, but we can
see from the second line that they are actually using only ~890 MB
currently (the servers are empty).
If another process were to suddenly need 6 GB of memory, the OS would do
some reallocation and it would be fine. It would only cause a problem
if SRCDS was actually using all 5.5 GB and there really wasn't enough
memory left for the new process. Then it would start swapping and
things would quickly get messy.
- Dave
Ben wrote:
> I agree.
>
> L4D isn't as much of an issue as it appears to restart itself frequently
> when it goes from in-use to hibernating. But for other games like TF2,
> CSS etc. chucking a "0 5 * * * killall srcds_i486" into the crontab of
> the user running your games servers is useful, as long as the startup
> script restarts it, or run it in a simple perpetual while loop or
> something similar.
>
>
> Andrew Armstrong wrote:
>> I don't currently run any game servers on linux, but I know from experience
>> that game servers in general may sometimes leak some memory over time,
>> although your graph seems to indicate its leaking a lot very quick.
>>
>> We reboot our game servers daily (at around 5am) in order to just avoid any
>> memory leak issues, perhaps you should do the same (setup something to do it
>> for you of course!).
>>
>> If you are running any game plugins etc, try uninstalling them first, they
>> may be at fault.
>>
>> Also try reverting back to the stock standard srcds_run script to see if
>> your changes were at fault.
>>
>> Cheers,
>> Andrew
>>
>>
>>
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
--
Dave Parker
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
