New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I also had a SRCDS Server (Gmod) and i used OpenVZ first, but it was lagging and crashing every day, then i took a XEN VPS and the problem was solved
My 32 slot CS:GO seems to eat about 400MB. CPU usage is around 60% of this E3-1270v2 and I don't think SRCDS is multithreaded. Using a tickrate of 128 though.
I still don't see how that changes anything. You could be on totally different nodes (OpenVZ and XEN nodes). Possibly one node was more loaded than the other.
Anyone know specifically the difference CPU management wise between XEN and OpenVZ?
Hmm, it's a completely vanilla server, setup via the wiki guide. Stock config too, nothing fancy. No mods either.
@Melita, the name of the map simply has "idle" in it, the server (and my friends/players who want to play there) actually play. The server.cfg is set to deal with real idlers.
Uh? What do you mean without the installed SRCDS? I use a similar start command, just through an init.d script.
Since the start. As noted, when I was put on a new/empty node, it ran fine for days. Though @CVPS_Kevin says that the node is still empty, so I'm just confused even more. Rebooting the container doesn't seem to make any difference.
I've tried both debian and centos, 32bit. Same issue happens regardless. I've long since added -debug to the commands but no crash log/dump is ever made. I've also enabled console logging, the logs just cut off suddenly when it goes "down". Often even mid-word.
I previously had a TF2 server running in 2011 on a 384/512 OVZ Quickweb LEB and that ran perfectly. Setup the exact same way as this one, following the wiki guide. Eh ._.
I've just rebooted the vps and started it up, I'd be surprised if this still reports online in a few hours.
Yes, I'm still afraid it's not a problem within VPS, especially after @CVPS_Kevin stated that your node is still empty.
Also, many valve mailing list also talks about this. Happens on both vanilla and non-vanilla server. Virtualization is not a culprit either. I've tried running it on my linux dedicated server with vanilla kernel, and it's still giving a same behavior.
Although strangely, it's happened less frequently with me (45 online server may gives 1 ~ 2 server hanging after 2 ~ 3 days). There might be some other factor playing (configuration, etc) which will trigger it more often.
You might try verify integrity of all your files by doing something like this (I'm a little skeptical whether this might fix it or not):
./steam -command update -game tf -verify_all -dir /your/pathOr you might want to run screen manually so you can reattach it later:
su youruser - script /dev/null screen -m -S tf2 cd /your/game/path/ ./srcds_linux -bla -bla -bla press CTRL+D exit exit exit^
You don't need 2 first command if you run srcds as root. If you're not running as root, make sure your files permission is correct by using chown and chmod commands.
To reattach, just use screen -R. If my suspicion is correct, you won't be able to type anything on srcds console when it's hanging out (only can CTRL+C or CTRL+D).
As stated by many others before,
These three directives just do not belong together. I'm sure that node won't be empty forever, so it's good to plan ahead.
I don't recommend VPS solution for game server such as TF2. I use dedis.
If you can stretch by a dollar, then you can take advantage of our $7 promo posted 6 months ago or so on LowEndBox.
I've ordered a batch of 4GB Sticks for our UK OVZ Servers, so we're going to be running 24GB per server. (Our business is based on overselling, but hopefully now with double the RAM we normally have per server it will loosen things up).
That's cool. I can do that too but he can't. This isn't an option.
1.5GB is at the high end, I'm not sure it'll even use 768 MB. But numbers like that aren't so important. What's important is that it runs
./steam -command update -game tf -verify_all -dir /your/path
-autoupdate keeps files in check. And even so, multiple times I've wiped and tried again with a fresh install, either for the heck of it or when trying a different distro. Invalid files is definitely not the cause.
I use this script to control starting/restarting etc srcds. I don't run as root, it's ran by the tf2server user. The Linux Server guide on the official TF2 wiki, and that init.d script (which starts the server identically to starting it directly anyway) are all I use. Complete vanilla.
Where are these mentions in mailing lists? Can you link anywhere? I've done much googling from all the headaches surrounding this but I guess I'm not using the right terms.
Okay, take this from me as I use to run on CVPS with the exact same setup.The simple answer is "DON'T!"
CVPS had some many issues with the speed of the IO that literally map changes took more then 2 hours. I finally got so fed up that I bought a dedicated server in Kansas.
The crashes you talk about might actually be the same thing.
But to be a little more help. This is a good method: http://stevenbenner.com/2010/11/how-to-set-up-a-team-fortress-2-dedicated-server-on-ubuntu/
You should install 64bit! and run this: apt-get install lib32gcc1 ia32-libs
You should also do a screen session. so screen and then run the server. That way you can't accidentally kill the server.
PM me if you need help, or talk to me here: http://forums.gaming-servers.net/
Hi Mun,
Very unfortunate to hear about your I/O problem you experienced with your service with us, how long ago was this? Do you have a ticket ID I can review, while I understand you may not be using our services anymore I'd like the opportunity to review this to ensure we take the appropriate measures required to prevent this from happening again to another customer. I am curious as we have a vast amount of customers running gameservers from Minecraft to TF2 to CS and many others without any problems at all, like a few of our customers have already attested for in this thread alone.
However - we've been making great improvements here at ChicagoVPS over the past few months including new proactive monitoring tools to ensure global node stability, better infrastructure, along with increased staffing levels to accommodate our growth... which means better support. We have many things in store for 2013 including further expansions as well
I would like to invite you back to ChicagoVPS to re-evaluate our services, feel free to PM me with your email on file and I will grant you a VPS free for 2 months so you can experience the changes we've been implementing over the past few months for yourself.
I'm afraid your assumption is incorrect, if you review my other post above in this thread you will see the node @Roph is on is still empty as we never unlocked the node yet...
We agreed to keep the node empty for him for a while to evaluate SRCDS on our environment, and again any benchmark @Roph chooses to run on his VPS can easily prove the node is empty.
Thanks Mun, I appreciate your time.
Best,
Kevin
Have you tried using other images or doing a reinstall? I had a problem like this last year (SRCDS TF2 hanging up), but that was on a 256 Ovz box that I was paying for $3.5/m
default image was a 32 bit debian, same problem you had, timeouts and I had to rerun the process to get it working again (but the game is lost) so I thought of trying ubuntu 32bit, and the problem was gone. Seriously. I dont know what happened but it worked. Wish I could give you proof but I have stopped playing and I dont have the box anymore (i let go of it just this december)
Then I'm afraid lag is the only option then ^^
-autoupdate doesn't do -verify_all by default. -verify_all will forces to check every files checksum, instead of relying on master update tables.
Try to delete/edit 1 ~ 2 files from your tf2 installation, and -autoupdate will missing it. -autoupdate will do -verify_all once new tf2 update is coming out (speaking of which, today there's a new tf2 update). I just want to eliminating the possibility of corrupted storage, that's all.
Btw, today there's a new tf2 update coming out. One of the changelog is this (no idea if its related or not):
About mailing list, it needs subscription, I suppose. Here's some thread from alliedmodders (notice it also mentions that this circumstances also happened in multiple OS environment, be it vanilla or not): https://forums.alliedmods.net/showthread.php?t=182999
Interesting quotes from some different poster on there:
-
-
-
-
-
-
I get your point here, though multiple times I've re-installed anew, basically the same end result as a verify_all. I've tried a few times on Debian (64 & 32 bit) and CentOS (32bit for now). Currently I'm still on CentOS 32 bit.
Thanks for that link by the way, bookmarked.
What's your reasoning behind this? SRCDS is not 64bit is it? I guess I'll try Ubuntu 64 bit soon enough. Right now I'm trying something that Luc (CVPS tech) suggested, I'll see how that goes.
SRCDS is 32 bit.
Their nodes are oversold.
Initially, your TF2 server keep crashing due to core or memory bottle neck.
After moving you to an empty node, its crashing because its a sourcemod related issue (tf2 patch).
Please update your metamod and sourcemod to the latest version, thank you.
Having the OS as 64bit helps even if the app is only 32bit.
I use no mods whatsoever. Vanilla SRCDS.
That's pretty odd.
Now installing on 64 bit ubuntu, let's see how it goes
What about Digital Ocean? I could provide you with 1 or 2 days.
64Bit has the great ability of allowing srcds to be more effective. Even if the RAM is lower you gain an extra high bandwidth bus to the CPU which is a massive benefit to srcds and pretty much anything else.
On a side note if you are rebuilding the server do as following.
as root:
apt-get update
apt-get install lib32gcc1 ia32-libs htop screen iftop (iftop is for network monitoring and great in case you need to figure out where a big spike of traffic is coming from, and htop is a nicer version of top)
adduser tf2 (fill out all the info)
as tf2:
login to tf2
wget http://www.steampowered.com/download/hldsupdatetool.bin
chmod +x hldsupdatetool.bin
./hldsupdatetool.bin (fill out yes at the bottom)
./steam ( you will need to do this multiple times until it just spits out the help function.)
screen
./steam -command update -game tf -dir . (due this in screen in case you loose connection to the server, this will install tf2 in your current directory, which in this case would be /home/tf2/, this will allow it to behave much more functionally in its own container.)
then do all your other configurations and test it out.
Same problem (if not even worse) on Ubuntu 64 bit. Meh.
And Mun, I'm not sure what your comment is intended to solve. I never have any trouble getting the server's files setup. It's just making sure it stays running / not hanging.
I'm thinking of just giving up. It just won't work on CVPS.
Can you PM me your config file. There is quite a bunch of things that can go wrong there.
Here you go, password excluded of course
Opps, found it
When I get home tonight I will rebuild the config, Just can't do it where I am at.
hostname "Server Name"
sv_tags "alltalk,more stuff,etc,"
sv_password ""
rcon_password "Secret Password"
sv_rcon_banpenalty 5
sv_rcon_maxfailures 10
mp_autoteambalance 0
mp_autoteambalance_delay 60
mp_autoteambalance_warning_delay 30
mp_teams_unbalance_limit 0
mp_enableroundwaittime 0
mp_bonusroundtime 20
mp_restartround 20
mp_stalemate_timelimit 120
mp_timelimit 120
mp_maxrounds 0
mp_winlimit 0
mp_forcecamera 0
mp_allowspectators 1
mp_friendlyfire 0
mp_footsteps 1
sv_cheats 0
sv_timeout 0
sv_maxspeed 360
sv_consistency 1
sv_visiblemaxplayers 25
decalfrequency 10
sv_alltalk 1
mp_chattime 10
sv_allowupload 1
sv_allowdownload 1
net_maxfilesize 99
sv_downloadurl "http://fasdl_address"
//this is where I think you went really wrong.
sv_minrate 20000
sv_maxrate 65000
decalfrequency 10
sv_maxupdaterate 66
sv_minupdaterate 40
sv_mincmdrate 40
sv_maxcmdrate 66
sv_client_predict 1
sv_client_min_interp_ratio 1
sv_client_max_interp_ratio 1
sv_client_cmdrate_difference 30
log on
sv_logbans 1
sv_logecho 0
sv_logfile 1
sv_log_onefile 1
sv_logsdir "logs"
sv_lan 0
sv_region 1
sv_contact Your info
sv_pausable 0
sv_pure 0
sv_pure_kick_clients 0
exec banned_user.cfg
exec banned_ip.cfg
//personal stuff
mapcyclefile "mapcycle.txt"
sv_allow_votes 0
So this is my config. (reduced)
This section below is key:
sv_minrate 20000
sv_maxrate 65000
decalfrequency 10
sv_maxupdaterate 66
sv_minupdaterate 40
sv_mincmdrate 40
sv_maxcmdrate 66
sv_client_predict 1
sv_client_min_interp_ratio 1
sv_client_max_interp_ratio 1
sv_client_cmdrate_difference 30
having minrate to 0 is bad, as you can make the server not send any traffic if it wanted, 20000 makes it always have to talk at some point.
the maxrate is also important in your case as you are running 32 players and with how low it is currently you would get constant buffer overflows.
leave the max and min the same from my setup.
I suggest for the time being you reduce the server to 24ish instead of 32. Tf2 was optimized and built for 24.
edit this config as needed and best of luck