Changed it to -10 to see if it gets better. Although I changed it to -20 while trying to solve the "hiccup", so the hiccup isn't related to it.
_pilger On 7 April 2014 16:29, Ross Bemrose <[email protected]> wrote: > I'm not sure it's a good idea to nice/renice srcds_linux to -20, as you're > literally telling the OS to give it every available CPU resource at the > expense of everything else. > > > On Mon, Apr 7, 2014 at 3:09 PM, pilger <[email protected]> wrote: > >> I took that screenshot when the server was at its peak of the full >> capacity. It doesn't get any more loaded than that. We never experienced >> the server's FPS dropping, though ("sv" field of the net_graph keeps pretty >> stable at 66.7). >> >> I'm not sure what you mean by running out of memory. If I understand >> right, I'm only using 536MB out of 1024MB. How can that be running out of >> memory? >> >> Here's the output of the free command: >> >>> total used free shared buffers cached >>> Mem: 1048576 1028516 20060 0 0 514344 >>> -/+ buffers/cache: 514172 534404 >>> Swap: 1572864 114332 1458532 >>> >> >> >> >> _pilger >> >> >> On 7 April 2014 15:58, ics <[email protected]> wrote: >> >>> First of all, you are running out of CPU. Second, you are also running >>> out of memory. System propably ate the other half of it. Check it with >>> command "free" and see how much you have in buffers and swap. >>> >>> -ics >>> >>> >>> pilger kirjoitti: >>> >>>> Not sure if this can be of any help, but this is what it looks like >>>> when it's full (28/28): >>>> Inline images 1 >>>> >>>> >>>> >>>> >>>> _pilger >>>> >>>> >>>> >>>> On 7 April 2014 11:50, pilger <[email protected] <mailto: >>>> [email protected]>> wrote: >>>> >>>> I've noticed the yellow bars mainly on the Mem field. Don't know >>>> if that might be related. Could it? >>>> >>>> About collectd, it seems very nice and a lot easier to visualize >>>> but you talked greek to me up there. Would you point me to some >>>> tutorial or show me some ropes on how to get it running so I can >>>> find the bottlenecks? Does it use a lot of resource!? >>>> >>>> >>>> _pilger >>>> >>>> >>>> On 7 April 2014 11:35, Yun Huang Yong <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Your concern about noisy VPS neighbours will show up as CPU >>>> steal - htop shows this as yellow bars by default. >>>> >>>> Disk latency could also be an issue. >>>> >>>> 66 tick means each tick has a time budget of around 15ms >>>> (1000/66). If disk latency exceeds 15ms you will get >>>> stuttering - I had this happen on servers in the past. >>>> >>>> e.g. >>>> https://dl.dropboxusercontent.com/u/8110989/2013/np1-disk- >>>> latency.png >>>> >>>> Stuttery server leading up to 08/03 (US style month/day, >>>> August last year). Host migrated my server to another less >>>> loaded machine, great for a few weeks then as that machine >>>> also became more heavily utilised (by other customers) it >>>> started to stutter again. >>>> >>>> FWIW I use collectd to gather these metrics on each host, >>>> feeding into a single collectd collector which then uses >>>> collectd's write_graphite plugin to write all the data into >>>> graphite for storage & graphing. collectd's default 10s >>>> polling is great for picking up transient issues, and >>>> graphite_web makes the visualisation easy. >>>> >>>> >>>> On 7/04/2014 10:26 PM, pilger wrote: >>>> >>>> Hey guys, thanks for the replies. >>>> >>>> * The RAM seems all right when I look at it with htop; >>>> * We tried CentOS but the network was behaving poorly >>>> with it so we >>>> >>>> switched to Debian x64 and it became a lot better; >>>> * net_splitpacket_maxrate was set to 50000 while the >>>> rates were from >>>> >>>> 30000 to 60000. I've now set the splitpacket to 100000 >>>> and the rates >>>> to 50000 to 100000 as you guys suggested. Gotta wait a >>>> bit for the >>>> server to get full so I can check if it worked; >>>> >>>> Wouldn't the htop or any other monitoring tool show >>>> something wrong even >>>> it being a VPS!? >>>> >>>> But, anyway, as I mentioned before, the problem occurs >>>> with the server >>>> practically empty. So I don't think it is related to CPU >>>> being >>>> overloaded... could I be wrong on this? Could my VPS >>>> neighbours be >>>> leeching on my CPU even it being supposedly reserved to my >>>> service? >>>> >>>> Thanks! >>>> >>>> >>>> >>>> _pilger >>>> >>>> >>>> On 7 April 2014 02:10, John >>>> <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] >>>> >>>> <mailto:[email protected]>>> wrote: >>>> >>>> Its not the RAM. Its packet loss from server side >>>> - you won't >>>> see it on net graph as its only client side. >>>> >>>> >>>> Packet loss should show in net_graph output either >>>> way. But, to be >>>> safe, certainly run MTR tests. >>>> >>>> >>>> I've had this happen to me lots of times. Been >>>> running servers >>>> since the 1.5 days. Ditch your host and also ditch >>>> Debian BS. >>>> >>>> >>>> Recent versions of Debian work well for game servers, >>>> so ditching it >>>> would not be necessary. >>>> >>>> You should confer with your host on the status of your >>>> hardware and >>>> whether a performance limitation is involved, such as >>>> I/O delays. >>>> You should also double-check server-side rates, >>>> including by making >>>> sure that net_splitpacket_maxrate is set sufficiently >>>> high (such as >>>> 100000). These symptoms seem along the lines of what I >>>> would expect >>>> from net_splitpacket_maxrate being low. >>>> >>>> >>>> Ask ant corporation or enterprise, all use CentOS. >>>> >>>> >>>> CentOS is marketed to enterprise and works well for such >>>> applications because of its older, stable, well-tested >>>> software >>>> packages and extended RHEL support for those older >>>> packages. For >>>> game servers, it is not ideal, since those older >>>> packages often lack >>>> useful features and performance tweaks. Debian is >>>> usually a better >>>> choice for game servers. >>>> >>>> >>>> If you're interested in hosting DDoS protected >>>> servers, email me >>>> - I can help you. >>>> >>>> >>>> Be very careful with hosts that claim to offer DDoS >>>> protection. >>>> There is an extremely limited number who do it right, >>>> and a very >>>> large number who do not. >>>> >>>> -John >>>> >>>> >>>> _________________________________________________ >>>> >>>> To unsubscribe, edit your list preferences, or view >>>> the list >>>> archives, please visit: >>>> https://list.valvesoftware.__com/cgi-bin/mailman/listinfo/_ >>>> _hlds >>>> <https://list.valvesoftware. >>>> com/cgi-bin/mailman/listinfo/hlds> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the >>>> list archives, please visit: >>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/ >>>> hlds >>>> >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list >>>> archives, please visit: >>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds >>>> >>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds >>> >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds >> >> > > > -- > Ross Bemrose > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
