What hardware issue? I'm not using even close to my max resources. Do you have any suggestions of what to check? On Dec 9, 2015 8:08 PM, "Don Park" <st...@tbctactics.com> wrote:
> It first depends on what stats you're looking at. > > Are you looking at the network variance? So in terms of ping and such? > > Or are you looking at the tick variance? So the difference/variance > between server-side ticks and local/client-side ticks? > > My post before was assuming server tick variance because if it was a > network variance then you should probably be contacting your ISP or your > server's ISP instead of contacting this listserv. > > So assuming it's the server-side ticks or the server-client ticks (as in > the end that's the end result you get which factors into the "variance" > variable), one of the biggest issues contributing to it (again, assuming > your local/client-side hardware is more than enough to run CSGO at the > proper tickrate), is the hardware limitations. The change in variance can > have multiple factors, but the most common culprit is that the server-side > instance of CSGO that's running is lagging behind. If the server-side > instance of CSGO is lagging behind, then that usually means the server > hardware isn't up to speed or is overcommitted (as in too many tasks on the > same server). That would mean you'd either need to upgrade your server > hardware or find more capacity elsewhere. > > As a rule, if you're getting high tick variance, check to make sure it's > not a network issue (no packet loss, etc.). Network monitoring and > coordinating with your ISP is probably the easiest way to start. Either > that or just talk with your community members and see if they're seeing the > same issues (high tick variance without the network issues). > > If it's not the network, then move on to the server monitoring > information. See how much of your resources are being used up. See if you > have enough RAM, the load is reasonable. etc. Follow basic computer > troubleshooting problems. Remember if this is a VPS or a Cloud server > deployment, then theoretically you're also sharing the same node with > neighbors. I'd suggest trying it out on a different VPS or a different > deployment with the same configurations and diversify your trials (as same > people on the node could be overusing their fair share of the hardware). > > If everything is fine then I'd double check as more than likely it's > probably something you've missed. Could potentially be a rogue firewall > rule somewhere upstream or maybe some tweaks in the DDoS Protection system > if applicable (these would all be considered network issues though). > > I haven't heard of issues related to tick variance and the SRCDS instance > using the same amount of resources. It doesn't really work like that, > unless you intentionally code that in, which is counter-productive. > However, this would also mean it'd be the same across all other SRCDS > deployments that are updated, however our deployment is fine, so I'd > probably suggest it's a hardware issue on your end. > > > On Thu, Dec 10, 2015 at 9:25 AM, Absurd Minds <goabs...@absurdminds.net> > wrote: > >> I'm not really good with computers... How is usage relevant? To be it >> seems like you could have reduced performance with the same usage, but I >> don't really have a very in-depth understanding of this sort of thing. Do >> you mind explaining this? >> On Dec 9, 2015 6:51 PM, "Don Park" <st...@tbctactics.com> wrote: >> >>> Yikes. Seems I made a bit of a mistake there. >>> >>> 1. I forgot to mention, the dip on Wednesday near 00:00 was referencing >>> the memory usage graph. >>> >>> 2. Our average memory usage isn't that high. If you're familiar with >>> Linux, it allocates unused RAM as cache. If a program needs the RAM, linux >>> will then automatically free up the needed RAM for use. More reading can >>> be done here about this if you're interested: >>> http://www.linuxatemyram.com/ >>> >>> 3. Therefore, here's another graph of the exact same time period and >>> location from our other monitoring system: >>> http://i.imgur.com/VU2K4Wd.png . Again, the dip in the RAM usage is >>> our CSGO server update script running. >>> >>> >>> >>> >>> On Thu, Dec 10, 2015 at 8:42 AM, Don Park <st...@tbctactics.com> wrote: >>> >>>> We're on Ubuntu 14.04, with the 3.13.0-63-generic kernel. >>>> >>>> I've attached some graphs and information from our monitoring system. >>>> All of them are the past week's monitoring (data collection time step of a >>>> minute). I believe the data collection time-zone is for Las Vegas, whereas >>>> this specific instance is located in Singapore. So please mind the time >>>> difference. As to note, our deployment doesn't put any limitations on any >>>> SRCDS game server instances, and our hardware is underloaded to make sure >>>> that our game server instances always have room to grow. This is a >>>> dedicated server after all, so we know 100% what's going on hardware-wise. >>>> >>>> Processor Usage (Week): http://i.imgur.com/oGqbnUv.png >>>> Memory Usage (Week): http://i.imgur.com/yTiFfFO.png >>>> Load Average (Week): http://i.imgur.com/Z9cDgTf.png >>>> >>>> To put the graphs and data into perspective, our current deployment is >>>> a Dual L5620 (so two quad core processors clocked at 2.4 GHz with >>>> hyperthreading comes to a total of 16 threads) node with 24 GB RAM. For >>>> the CSGO servers, we've made a KVM within the server with 8 CPU cores and 8 >>>> GB RAM. This specific KVM deployment runs around 6 CSGO Servers. >>>> >>>> You can see the dip on Wednesday near 00:00, that was the time I ran >>>> the update scripts. using the last week's historical data as the >>>> "baseline" point, you can see (on the Processor Usage graph) that the >>>> average CPU usage is still within historical max-used limits, however does >>>> seem to be on the higher end of the spectrum. I'd like to assume this is >>>> basically just more people who got back and played CSGO to check out the >>>> new update. >>>> >>>> If you look at the Load Average graph, you can see the same spike here, >>>> except larger (as load average is cumulative (or the total "sum" of the >>>> load on all 8 cores), whereas the processor usage is distributed (or as >>>> just shows the % usage of each core)). However, it's in line with Friday's >>>> numbers (Friday of course being one of the more popular days with higher >>>> user peaks). >>>> >>>> Processor Usage (Month): http://i.imgur.com/kjEsQPU.png >>>> Load Average (Month): http://i.imgur.com/JuezJVz.png >>>> >>>> Now here are the past month's numbers. There's nothing out of the >>>> ordinary that I can tell happening server hardware-wise. >>>> >>>> Now related to in-game statistics, I don't have the numbers on me but >>>> no major changes in variance (network-wise nor tick-wise) has been >>>> experienced. I myself when playing on our servers haven't seen any major >>>> differences or changes in the tick variance, nor have I received reports of >>>> the variance or anything else is out of the ordinary... besides for >>>> complaints that the R8 Revolver completely breaks the game. >>>> >>>> Let me know if there's anything else I can share with you. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Dec 10, 2015 at 8:07 AM, Absurd Minds <goabs...@absurdminds.net >>>> > wrote: >>>> >>>>> I noticed it in the valve servers, which are also Ubuntu, but it's >>>>> hard to tell there because valve server performance is always so spotty. >>>>> On Dec 9, 2015 6:02 PM, "Absurd Minds" <goabs...@absurdminds.net> >>>>> wrote: >>>>> >>>>>> Are you also on Ubuntu? >>>>>> On Dec 9, 2015 5:48 PM, "Don Park" <st...@tbctactics.com> wrote: >>>>>> >>>>>>> This is not the case for our deployment. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 10, 2015 at 7:40 AM, Absurd Minds < >>>>>>> goabs...@absurdminds.net> wrote: >>>>>>> >>>>>>>> I've noticed on my servers that the variance is spiking quite a lot >>>>>>>> since yesterday's update. I've noticed this in other servers, too (but >>>>>>>> obviously I have no way of knowing if that's abnormal to their server). >>>>>>>> >>>>>>>> Im running Ubuntu. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Csgo_servers mailing list >>>>>>>> Csgo_servers@list.valvesoftware.com >>>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Csgo_servers mailing list >>>>>>> Csgo_servers@list.valvesoftware.com >>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Csgo_servers mailing list >>>>> Csgo_servers@list.valvesoftware.com >>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Csgo_servers mailing list >>> Csgo_servers@list.valvesoftware.com >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>> >> >> _______________________________________________ >> Csgo_servers mailing list >> Csgo_servers@list.valvesoftware.com >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >> > > > _______________________________________________ > Csgo_servers mailing list > Csgo_servers@list.valvesoftware.com > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >
_______________________________________________ Csgo_servers mailing list Csgo_servers@list.valvesoftware.com https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
