I’m not understanding how vprof is related to the console problems you 
described.  Would you mind clarifying?

If you’re reliably able to reproduce a spike, would it not be possible to turn 
on vprof spike mode, get a report, and then turn vprof off.  If the spikes are 
really huge, then just set the threshold really low.

From: hlds-boun...@list.valvesoftware.com 
[mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Kyle Sanderson
Sent: Monday, May 13, 2013 10:14 AM
To: Half-Life dedicated Win32 server mailing list
Subject: Re: [hlds] [hlds_linux] TF2 server performance spikes


The problem with vprof is SRCDS has become very verbose with bogus data table 
warnings and clients flooding server messages by running commands without args. 
There's con_logfile, but once that starts, it cannot be stopped. I had a 90MB~ 
log file after a couple hours, which isn't fun on an SSD.

vprof needs to write files/dumps automatically to disk in order to become 
useful for servers.

Thanks,
Kyle.
On 13 May 2013 10:09, "Fletcher Dunn" 
<fletch...@valvesoftware.com<mailto:fletch...@valvesoftware.com>> wrote:
Has anybody used vprof spike mode?  This sort of problem is pretty much exactly 
what it was designed to investigate.

E.g.

vprof_on
vprof_dump_spikes 20       // dump a vprof report if frame rate drops below 20

If the problem is caused by network traffic, using the -netspike command line 
argument can also be used to dig deeper into exactly what entity data is being 
sent.

If you have a report and you don't know how to interpret it, you can email it 
to me or post it here, I'm sure there are some people who can help analyze it.

-----Original Message-----
From: 
hlds_linux-boun...@list.valvesoftware.com<mailto:hlds_linux-boun...@list.valvesoftware.com>
 
[mailto:hlds_linux-boun...@list.valvesoftware.com<mailto:hlds_linux-boun...@list.valvesoftware.com>]
 On Behalf Of Bjorn Wielens
Sent: Monday, May 13, 2013 9:42 AM
To: Half-Life dedicated Win32 server mailing list; 
hlds_li...@list.valvesoftware.com<mailto:hlds_li...@list.valvesoftware.com>
Subject: Re: [hlds_linux] [hlds] TF2 server performance spikes

Correct, I was one of the folks discussing this in the last round of messages 
and we run on Linux. Since my last message about having disabled replays I 
still get occasional hiccups in a full server, but nowhere near as bad as 
before, owing to the lack of replay overhead.

I'd be happy to run diagnostics if they were available for Linux, but alas 
that's not the case.



________________________________
 From: Alex Kowald <abkow...@gmail.com<mailto:abkow...@gmail.com>>
To: Half-Life dedicated Win32 server mailing list 
<hlds@list.valvesoftware.com<mailto:hlds@list.valvesoftware.com>>
Sent: Monday, May 13, 2013 1:16:04 PM
Subject: Re: [hlds] TF2 server performance spikes



You are only accepting traces for windows servers correct? Some of the people 
that have complained are running linux. I have the issue myself on two 
independent servers. We get this new game studder after upgrading, leaving 
everything else the same.



On Mon, May 13, 2013 at 12:11 PM, Fletcher Dunn 
<fletch...@valvesoftware.com<mailto:fletch...@valvesoftware.com>> wrote:

I do have a theory about the cause of the CPU spikes.  I’ll release a build 
with the next mandatory update (which will probably be this afternoon) that I 
think could address the problem.  But since we are not reproducing the problem 
here, this is just a theory, not disciplined engineering.
>
>In order to conduct disciplined engineering, we need data from those who are 
>able to reproduce it.  Judging by the amount of discussion this problem has 
>generated and the relatively small amount of effort that is required in order 
>to get the data to us,  I’m really surprised we haven’t received more traces.
>
>I have given out vtrace keys to every person who has asked for one.  So far we 
>have received traces from exactly two (2) server operators.  One server 
>operator had processor affinities set, the other was running a high number of 
>instances per core, such that the average CPU utilization was high and there 
>was no headroom for more than one process to spike.
>
>
>_______________________________________________
>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_linux
_______________________________________________
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