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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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" <[email protected]> >>>> wrote: >>>> >>>>> Are you also on Ubuntu? >>>>> On Dec 9, 2015 5:48 PM, "Don Park" <[email protected]> wrote: >>>>> >>>>>> This is not the case for our deployment. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 10, 2015 at 7:40 AM, Absurd Minds < >>>>>> [email protected]> 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 >>>>>>> [email protected] >>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Csgo_servers mailing list >>>>>> [email protected] >>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>>>>> >>>>> >>>> _______________________________________________ >>>> Csgo_servers mailing list >>>> [email protected] >>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >>>> >>> >>> >> >> _______________________________________________ >> Csgo_servers mailing list >> [email protected] >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >> > > _______________________________________________ > Csgo_servers mailing list > [email protected] > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers >
_______________________________________________ Csgo_servers mailing list [email protected] https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
