Yeah, if you're running it on Linux, you really don't need VNC most of the time. Just admin it with an SSH client (like PuTTy) and run the games as a "disconnected" background process using the "screen" utility. That way, you don't have to leave anything running on a local GUI-console at all.
On Mon, Apr 7, 2014 at 2:54 PM, Mick Carter <[email protected]>wrote: > 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 <[email protected]> > *Sent:* Monday, April 07, 2014 8:34 PM > *To:* Half-Life dedicated Win32 server mailing > list<[email protected]> > *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 > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
