ID:103423
 
BYOND Version:478
Operating System:Windows Server 2003 R2
Web Browser:Firefox 3.6.10
Applies to:Dream Daemon
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Since nobody was responding to my pager messages, you gets a bug report!

I'm having some failtastic CPU usage problems in HU2. The CPU usage just seems to get exponentially worse the more players that are online - and by the time it hits 100 players its pretty much at 100%. Compared to being at 0% with 25 players.
The main server of HU1, at the time of this posting, had about 70 players and is only using about 7% CPU. Which is an acceptable ratio.

From my in-game CPU monitoring systems:
HU1: Average CPU: 7% | Average Players: 69
HU2: Average CPU: 22% | Average Players: 63
The server of HU1 has also been online about 40x as long as the HU2 server.

BE has also been having some massive CPU problems lately, similar to HU2's, but exponentially worse at much lower player counts. I find this rather odd since I designed/tested/ran that game for several months, if not years, and the CPU usage was always intentionally low.

In HU2, this has the highest CPU usage(?):
mob/Stat()
if(statpanel("Server"))
stat("Host:","[world.host]")
stat("Version:","[GameVersion].0")
stat("Usage:","[world.cpu]%")
stat("Players:","[Players.len]")
stat("Up Time:","[Hours]:[Minutes]:[Seconds]")
stat("Server Link:","[world.internet_address]:[world:port]")

http://www.angelfire.com/hero/straygames/ByondBugs/ HighStatProfile.png
http://www.angelfire.com/hero/straygames/ByondBugs/ HighStatProfileAvg.png
Is there a chance that internal BYOND functions, which aren't being profiled, could be causing a problem?

Any suggestions to help diagnose/solve the problem?

The games mentioned should be the first 3 on this page http://www.byond.com/members/falacy

Unrelated note: I haven't had a single server crash since I started using the test version of 478, which was over a week ago. So, good job there.
Additional notes/previous forum post about the issue: http://www.byond.com/developer/forum/?id=757033&single=1
You've chosen the wrong sort criteria--realtime CPU usage is where you'll see the worst offenders.

I have found in the past that realtime CPU can be incorrect for some odd cases, so if you see a ridiculously high number it's probably not true, but looking at what you posted it's clear Stat() is not the problem. EnemyAI(), RefreshMiniMap(), PowerUp(), and Attack() are the worst ones that pop out in the first report. In the second there are other obvious contenders, like FocusTrainingProc() and SmartFollow(), with some of the above listed again.
Errr, I'm pretty sure the Real Time column is just that - the literal time the proc has been running for.
mob/verb/Test()
src<<"Testing"
for(var/i=1;i<=10;i++) sleep(1)
src<<"Test Over"
//Shows ~1 in the Real Time column for each execution

Are you saying its somehow a problem to have loops running for extended periods of time? Or is one and/or both of us just confused.
High realtime can show up during some CPU-intensitve operations, such as icon operations for instance. As I said it's not always accurate, but in general what you want to look at are the procs that show the highest real time. The numbers are high enough they could indicate something going on.
It appears! That all the things with high real times are either A. Intentionally long loops or B. Things with basic alert(s)/input(s). So I'm gonna blame it on B! Also, maybe winset(s).
I'm gonna have to disagree with your claim of Real Time being worth anything here. After looking in to it, all of the procs are either intentionally long, require input, and/or have matching Self CPU - which icon operations (as you mentioned) surely do.
Anything with a huge number of calls would be a prime target for optimization. You have many procs that are being called in excess of a million times, so any speed you can eke out of them is vital. Those presumably are being called several times every tick, and if you can minimize that you'll see much lower world.cpu levels. Calling any of those much less frequently would probably also help.

Ultimately I don't think you're looking at a bug here, but an optimization problem. I'm not sure what kind of time span that profile represents, but that's a lot of proc calls. Just in the one screenshot alone I see in excess of 12 or 13 million calls. It adds up.
Maaaaaybe I can try that
And that profile was from 6+ hours
What does world.cpu actually represent? "This is the percentage of a server tick that the server spends processing running procs."; Is this based on some sort of internal bottleneck? Because, it isn't stressing my actual/physical processor/CPU, its completely oblivious to other servers running on that same processor, and it seems to get exponentially worse based on player count - in certain games more-so than others...
My latest imaginary theory is that this is related to set instant=1, will be testing it in the next version of HU2
To clarify what this does, it prevents these commands from being queued up and lets them execute as much as they need to be, not just one command per tick. If you have verbs with this setting they may show up in the profiler if your theory is correct. The important thing is to make sure this setting is used judiciously.
I know what set instant does o.O I was asking what world.cpu does, if you were attempting to answer my question.
And I did have set instant on things that were spammed quite a bit (combat and movement), but they all had a simple if() at the beginning that should have killed them immediately. The instant setting is just so that you don't end up punching the air for 5 seconds after you stop tapping the key.
The world.cpu value basically tells what percentage of each tick is being used for server processing. That includes verbs, procs, and any of the internal work that has to be done.
But how is the % actually calculated?
world.cpu is a rolling average of percentages, where the percentage is calculated at each tick by taking the current CPU clock value and then taking its value again after all procs have executed. It's then divided by the actual time of a full tick.
Well, after monitoring the CPU usage more closely, it seems to go from like 5% to 75% instantly - with no suspicious activity in the profiler
Well, I made a quick log of the CPU/second. Gonna post it, not that it will help anything. You can see it goes from a pretty steady 20ish% (which is still a bit high IMO) to a steady 100+% almost instantly. And as I said, nothing suspicious shows in the profiler. This jump also occurs at a random time, so that doesn't help much either.
Time           Version  Players    CPU     UpTime
15:36:03 v57 96p 19% 0:38:5
15:36:03 v57 96p 25% 0:38:6
15:36:03 v57 96p 22% 0:38:7
15:36:03 v57 96p 20% 0:38:8
15:36:03 v57 96p 22% 0:38:9
15:36:03 v57 96p 24% 0:38:10
15:36:03 v57 96p 29% 0:38:11
15:36:03 v57 97p 30% 0:38:12
15:36:03 v57 97p 27% 0:38:13
15:36:03 v57 97p 25% 0:38:14
15:36:03 v57 97p 24% 0:38:15
15:36:03 v57 97p 24% 0:38:16
15:36:03 v57 97p 25% 0:38:17
15:36:03 v57 97p 23% 0:38:18
15:36:03 v57 97p 21% 0:38:19
15:36:03 v57 97p 24% 0:38:20
15:36:03 v57 97p 24% 0:38:21
15:36:03 v57 97p 22% 0:38:22
15:36:03 v57 97p 23% 0:38:23
15:36:28 v57 98p 23% 0:38:24
15:36:28 v57 98p 22% 0:38:25
15:36:28 v57 98p 23% 0:38:26
15:36:28 v57 98p 23% 0:38:27
15:36:28 v57 98p 23% 0:38:28
15:36:28 v57 98p 19% 0:38:29
15:36:28 v57 97p 21% 0:38:30
15:36:28 v57 98p 82% 0:38:31
15:36:54 v57 97p 9% 0:38:33
15:36:54 v57 97p 98% 0:38:34
15:36:54 v57 97p 54% 0:38:36
15:36:54 v57 96p 40% 0:38:37
15:36:54 v57 96p 133% 0:38:38
15:37:20 v57 95p 28% 0:38:39
15:37:20 v57 95p 66% 0:38:40
15:37:20 v57 94p 81% 0:38:41
15:37:20 v57 93p 9% 0:38:42
15:37:20 v57 93p 80% 0:38:43
15:37:45 v57 93p 75% 0:38:45
15:37:45 v57 91p 9% 0:38:46
15:37:45 v57 90p 80% 0:38:47
15:37:45 v57 90p 84% 0:38:48
15:38:11 v57 91p 9% 0:38:49
15:38:11 v57 91p 88% 0:38:50
15:38:11 v57 89p 20% 0:38:51
15:38:11 v57 89p 65% 0:38:53
15:38:11 v57 90p 114% 0:38:54
15:38:36 v57 92p 120% 0:38:55
15:38:36 v57 92p 54% 0:38:56
15:38:36 v57 92p 16% 0:38:57
15:38:36 v57 92p 91% 0:38:58
15:38:36 v57 92p 49% 0:39:0
15:39:02 v57 90p 22% 0:39:0
15:39:02 v57 89p 98% 0:39:1
15:39:02 v57 89p 80% 0:39:2
15:39:02 v57 89p 8% 0:39:4
15:39:02 v57 89p 63% 0:39:4
15:39:02 v57 89p 109% 0:39:5
15:39:02 v57 89p 98% 0:39:6
15:39:28 v57 87p 7% 0:39:8
15:39:28 v57 87p 71% 0:39:9
15:39:28 v57 87p 92% 0:39:10
15:39:28 v57 87p 18% 0:39:11
15:39:28 v57 87p 62% 0:39:12
15:39:28 v57 87p 112% 0:39:13
15:39:28 v57 87p 117% 0:39:14
15:39:28 v57 86p 115% 0:39:15
15:39:53 v57 86p 114% 0:39:16
15:39:53 v57 86p 113% 0:39:17
15:39:53 v57 86p 112% 0:39:18
15:39:53 v57 86p 116% 0:39:19
15:39:53 v57 86p 113% 0:39:20
15:39:53 v57 85p 111% 0:39:21
15:39:53 v57 85p 109% 0:39:22
15:39:53 v57 85p 105% 0:39:23
15:39:53 v57 85p 108% 0:39:24
15:39:53 v57 85p 112% 0:39:25
15:39:53 v57 85p 112% 0:39:26
15:39:53 v57 85p 108% 0:39:27
15:39:53 v57 85p 112% 0:39:28
15:39:53 v57 85p 109% 0:39:29
15:39:53 v57 85p 101% 0:39:30
15:39:53 v57 86p 106% 0:39:31
15:39:53 v57 86p 115% 0:39:32
15:39:53 v57 86p 112% 0:39:33
15:39:53 v57 85p 116% 0:39:34
15:39:53 v57 85p 113% 0:39:35
15:39:53 v57 85p 110% 0:39:36
15:40:19 v57 85p 110% 0:39:37
15:40:19 v57 85p 107% 0:39:38
15:40:19 v57 85p 111% 0:39:39
15:40:19 v57 85p 113% 0:39:40
15:40:19 v57 85p 111% 0:39:41
15:40:19 v57 85p 110% 0:39:42
15:40:19 v57 85p 109% 0:39:43
15:40:19 v57 85p 115% 0:39:44
15:40:19 v57 85p 120% 0:39:45
Oh, also worth noting. If I kick like 90% of the server (everyone AFK) once this jump occurs - the CPU usage will drop, but it will still remain at about a 1/1 relation, instead of dropping back down to the 1/10 it started at.
So if I kick 80 people, and end up with 20, the CPU usage will drop from 100% to 20%. But when running properly, 20 players=0% CPU, and 50 players=~5%
Something interesting I just noticed, though it may be completely unrelated. The CPU for Paradise City (according to Window's Task Manager) was reporting a pretty steady 25. Even after I shut down the world via a del Topic, the CPU didn't drop for the DD instance. Pretty much all of my other games bounce around near 0.
EDIT: Yup, seems unrelated, but still odd.
Page: 1 2