| View previous topic :: View next topic |
| Author |
Message |
BloodyIron
Tux's lil' helper
Joined: 08 Jan 2008
Posts: 101
|
 Posted: Mon Sep 19, 2011 2:56 am Post subject: Gentoo on HyperV running SRCDS |
 |
|
Hey Folks,
I'm running a Gentoo VM on a HyperV box for the purpose of running a Team Fortress 2 server.
So the server is setup pretty much identically to multiple other servers I've setup except for the HyperV parts. In the earlier parts of setting it up I was using the non-legacy NIC however when I changed the MAC to static I was never able to get the non-legacy NIC working, so I have had to switch to a legacy NIC with dynamic MAC.
The problem is that the tf2 server after a while starts stuttering for all players on the server. I have not yet found a resolution for this beyond rebooting the whole VM, which isn't exactly the best solution. Sometimes it can take only 30 mins before I have to reboot the VM, sometime's it's longer.
I'm pretty sure it's not running out of RAM as htop reports (so far as I can tell) 50% usage. The VM has 1GB allocated.
Anyways, I'm not sure what I can do about this situation as I'm kind of baffled this is happening in the first place.
Any ideas?
_________________
Team3 for life. |
|
| Back to top |
|
 |
Yuu
Apprentice
Joined: 23 Dec 2008
Posts: 223
Location: France
|
| Posted: Mon Sep 19, 2011 5:20 pm Post subject: |
|
|
Hi BloodyIron,
how much CPU usage do you use when your server : is running fine and when it starts stuttering ? If you have a lot of players, you should consider reducing the maximum number of players.
You should also analyse your network interface before and when the lag appears. For this, you can use tcpdump and/or wireshark. And if you're running an headless server, use tcpdump with -w on the server, then download the .cap file and open-it with wireshark.
Good luck :]
_________________
Main laptop : T8300 cpu | 200 GB hard drive | 2 GB of ram | 8600M GT | Gentoo x86_64
Server : Celeron 220 cpu | 250 GB hard drive | 2 GB of ram | SiS 662 VGA | Gentoo x86_64 |
|
| Back to top |
|
|
BloodyIron
Tux's lil' helper
Joined: 08 Jan 2008
Posts: 101
|
| Posted: Mon Sep 19, 2011 5:45 pm Post subject: |
|
|
The CPU is nowhere near being fully utilized when this happens, it's not related to the number of players in any shape or form as it can happen when only one or two are on, or when it's completely full. I don't think it's a network issue as the VM is directly internet facing.
| Yuu wrote: | Hi BloodyIron,
how much CPU usage do you use when your server : is running fine and when it starts stuttering ? If you have a lot of players, you should consider reducing the maximum number of players.
You should also analyse your network interface before and when the lag appears. For this, you can use tcpdump and/or wireshark. And if you're running an headless server, use tcpdump with -w on the server, then download the .cap file and open-it with wireshark.
Good luck :] |
_________________
Team3 for life. |
|
| Back to top |
|
|
BloodyIron
Tux's lil' helper
Joined: 08 Jan 2008
Posts: 101
|
| Posted: Tue Sep 20, 2011 12:50 am Post subject: |
|
|
bump
_________________
Team3 for life. |
|
| Back to top |
|
|
BloodyIron
Tux's lil' helper
Joined: 08 Jan 2008
Posts: 101
|
| Posted: Tue Sep 20, 2011 11:01 pm Post subject: |
|
|
Really, nobody knows about this?
_________________
Team3 for life. |
|
| Back to top |
|
|
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
|
| Posted: Tue Sep 20, 2011 11:33 pm Post subject: |
|
|
| BloodyIron wrote: | | Really, nobody knows about this? |
HyperV isn't the most common 'round these parts. Don't know how many eyes that happen upon this thread are going to be all that familiar.
I personally can only really take stabs in the dark.
The networking thing - I wouldn't look there inasmuch as lost traffic, but it could well be the case a buggy network driver or some virtualization "glue" becomes unstable after a while, or under load unrelated to concurrency. Where *I* would start testing, is taking the game server software out of the equation (e.g. just stop whichever daemon), see if you can recreate the issue by generating a bit of sustained network load. I don't know if your game server uses TCP or UDP, but for testing TCP as a potential cause you could e.g. transfer a handful of relatively large files in rapid succession. For UDP I'm not sure.
If that yields nothing, I'd look more in the direction of the software itself. Doesn't have to be eating up gobs of memory or disk I/O or CPU to be wigging out.
Or, you could always try a lower latency kernel (e.g. zen-sources, rt-sources, pf-sources, ck-sources, with BFS and the other round of goodies)
All blind shots in the dark, this is somewhat of an esoteric case on a virtualization platform id wager not too many gentoo users use.
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
BloodyIron
Tux's lil' helper
Joined: 08 Jan 2008
Posts: 101
|
| Posted: Wed Sep 21, 2011 3:33 am Post subject: |
|
|
thx for the heads up, I've made some adjustments to the tf2 server itself, going to see if that changes anything.
failing that I'll see if the kernel has anything to do with it.
The problem is that it happens after a period longer than 30 minutes, so it would seem a bit of a pain to sustain bandwidth for such a long period, as I would likely want to test for upwards of 5-12 hours. Is there a utility you know of to do something to this effect?
| cach0rr0 wrote: | | BloodyIron wrote: | | Really, nobody knows about this? |
HyperV isn't the most common 'round these parts. Don't know how many eyes that happen upon this thread are going to be all that familiar.
I personally can only really take stabs in the dark.
The networking thing - I wouldn't look there inasmuch as lost traffic, but it could well be the case a buggy network driver or some virtualization "glue" becomes unstable after a while, or under load unrelated to concurrency. Where *I* would start testing, is taking the game server software out of the equation (e.g. just stop whichever daemon), see if you can recreate the issue by generating a bit of sustained network load. I don't know if your game server uses TCP or UDP, but for testing TCP as a potential cause you could e.g. transfer a handful of relatively large files in rapid succession. For UDP I'm not sure.
If that yields nothing, I'd look more in the direction of the software itself. Doesn't have to be eating up gobs of memory or disk I/O or CPU to be wigging out.
Or, you could always try a lower latency kernel (e.g. zen-sources, rt-sources, pf-sources, ck-sources, with BFS and the other round of goodies)
All blind shots in the dark, this is somewhat of an esoteric case on a virtualization platform id wager not too many gentoo users use. |
_________________
Team3 for life. |
|
| Back to top |
|
|
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
|
| Posted: Wed Sep 21, 2011 4:13 am Post subject: |
|
|
| BloodyIron wrote: | thx for the heads up, I've made some adjustments to the tf2 server itself, going to see if that changes anything.
failing that I'll see if the kernel has anything to do with it.
The problem is that it happens after a period longer than 30 minutes, so it would seem a bit of a pain to sustain bandwidth for such a long period, as I would likely want to test for upwards of 5-12 hours. Is there a utility you know of to do something to this effect?
|
got another internal box you can use to host a large file? (I say internal so you arent eating external bandwidth just for a test)
| Code: |
while true; do wget http://192.168.blah.blah/largefile.iso ; rm ./largefile.iso ; done
|
or if you have e.g. a /music directory with a crapton of files, talking like 30GB of music, do an scp -r to the server and see if you can get it to choke (hopefully you dont run out of disk on t he server first)
you get the idea. I would lean towards testing on a different physical piece of hardware, purely to make it seem as real as possible to the guest OS that it's fetching an externally hosted file, rule out the underlying host OS, etc.
dmesg is always your friend as well. No real educated way to tell you what to look for in its output, since we havent the foggiest idea even the vicinity of what might be causing it, pretty much `dmesg` once it starts acting up, and hope you get lucky.
Hopefully it can be easily repro'd with the tf2 server out of the picture, largely since troubleshooting a specific application on the fritz adds a whole other layer of complexity.
...i don't know if any of that makes sense, i really shouldnt be posting til ive had my nicotine hit.
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
