There's no clean way to capture the output from vprof at the time of this writing. Messages flyby on a production server console. The only way you're able to capture any sort of output from the vprof_generatereport command (or whatever the generic name is) is to use con_logfile. However, once con_logfile is enabled, the logging cannot be stopped until the server dies. I tried using vprof when CS:S was moved to Steam|, and got burned pretty quickly due to uptime. (I'm on Linux)
Thanks, Kyle. On Mon, May 13, 2013 at 10:16 AM, Fletcher Dunn <[email protected] > wrote: > 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:* [email protected] [mailto: > [email protected]] *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" <[email protected]> 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: [email protected] [mailto: > [email protected]] On Behalf Of Bjorn Wielens > Sent: Monday, May 13, 2013 9:42 AM > To: Half-Life dedicated Win32 server mailing list; > [email protected] > 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 <[email protected]> > To: Half-Life dedicated Win32 server mailing list < > [email protected]> > 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 < > [email protected]> 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 > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
