Thanks for this suggestion, I did run this but without any idea what the
profile is supposed to look like I ended up looking at the individual
TF2 server instance CPU usage more closely and it's the MvM servers that
are chewing up notiecably more CPU than prior to the last (4 April) update.
A bunch of observations make me wonder if there was a change or bug
introduced in the MvM bot logic which may be related to the increase MvM
CPU usage.
As far as I can remember MvM bots were spawned on demand, and otherwise
never showed up in the 'status' output until they were actually in game.
Looking at 'status' today I see lots of bots like this:
# 60 "TFBot" BOT active
# 61 "(1)TFBot" BOT active
# 62 "(2)TFBot" BOT active
etc
In addition, I'm encountering this bug on my Wave 666 server.
https://github.com/ValveSoftware/Source-1-Games/issues/301
tl;dr bots seem to be taking up way more player slots than they should
be, leading to starvation of real player slots and the visible max
players dropping to 2.
From what I recall of how visible max players is supposed to work:
- 32 total slots required
- 22 slots required for bots
- 6 slots for players
- 4 slots left empty (spectators, some servers use these for 10p MvM)
So not only are the bots exceeding the allocated 22 slots, they're
chewing up the 4 normally empty spectator slots and then chewing up 4
additional player slots.
Are any MvM server operators seeing these changes?
This is all on a vanilla (non-MM/SM) server, the only config changes are
to the tf_mvm_missioncyclefile & mvm_coaltown.cfg to force 24x7 Wave 666.
I suspect the problem doesn't manifest itself on a "normal" MvM server
where the waves are much shorter and there is opportunity for things to
be "reset" regularly.
On 12/04/2013 4:52 AM, Ryan Kistner wrote:
Hey,
I would recommend running the vprof set of commands to diagnose where
frame time is going. Unfortunately without pre-update data there's not a
clear comparison. Run "vprof_on" to start the profiler, let the game run
for a while, then "vprof_off." You'll then run "vprof_generate_report"
for a data dump of frame time usage, as well as peaks.
You and others may want to run the vprof
On 4/11/2013 6:21 AM, Yun Huang Yong wrote:
Looking at another machine I have that also hosts 3 other servers
(1x24p and 2xMvM) it also has seen an increase in CPU usage. Across
all servers there's almost a doubling in CPU usage.
I tried to dig into whether it was a PvP or MvM thing and the CPU
increase is consistent across both types of servers.
I tried disabling replays on the servers that had it and that didn't
help.
I'm really at a loss. At the current usage the machines that
previously ran 3 servers each will only be able to handle 2 so I'll
need to spend +50% on new hardware, or shut down 2 servers.
Any suggestions on how to narrow down the cause?
Anyone from Valve that could comment on what might cause this?
It only started with the 3rd/4th April update.
On 10/04/2013 5:36 AM, ics wrote:
Yes, i see increased CPU usage per server after the update. I also see
some randomly occuring spikes on CPU at random. These were not there
before the update and they occur on 2 different machines.
-ics
Yun Huang Yong kirjoitti:
On 4/04/2013 10:08 AM, Eric Smith wrote:
- Improved performance of Linux dedicated server binaries
Has anyone seen an *increase* in CPU usage since the most recent
(3rd/4th April) update?
My players have been complaining of lag and upon investigation the
network is fine and it appears to be a CPU issue. I took a look at my
graphite graphs and found that there appears to be have been an
increase in CPU usage since the update:
https://dl.dropbox.com/u/8110989/tf2/cpu-usage-post-20130404.png
Note: due to server being in Australia the update was released in the
flat gap between 04/04 and 04/05 on the graph, being ~10am local time.
Running on Ubuntu 11.10 64 bit.
The server has been running for ~6 months with the same setup and
during the period shown the # of players has been roughly the same.
The machine runs 3 servers - 2x24p and 1xMvM.
Excuse the gaps in the data - the server is fine, there was network
issues with the graphite collector machine causing monitoring data to
be lost.
cheers,
yun
_______________________________________________
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_linux
_______________________________________________
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_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
