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 <pilger...@gmail.com> 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 <i...@ics-base.net> 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 <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
>>
>
>
> _______________________________________________
> 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
