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]>> 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

Reply via email to