Not sure if this is relevant or not as I don’t know too much about Linux, and I recently changed from a Windows server to Linux and had problems with resources being taken up and every now and again the server would falter.
I found that as I was running VNCserver after staring it I had to log back in and type “killall vino-server” as it was causing one of the four CPU cores to max out at 100% and then move to another each being at 100%. After killing vino-server, everything now runs very smoothly. I may be completely on the wrong track here as a Linux noob, but just trying to help if I can. Regards Mick From: pilger Sent: Monday, April 07, 2014 8:34 PM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] Help with "Rubberband Effect" 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
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
