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 <pilger...@gmail.com <mailto:pilger...@gmail.com>> 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 <gumby_li...@mooh.org
    <mailto:gumby_li...@mooh.org>> 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
            <lists.va...@nuclearfallout.net
            <mailto:lists.va...@nuclearfallout.net>
            <mailto:lists.va...@nuclearfallout.net
            <mailto:lists.va...@nuclearfallout.net>>> 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

Reply via email to