ID:2356349
 
BYOND Version:511
Operating System:Windows 10 Home
Web Browser:Chrome 58.0.3029.110
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:


Expected Results:

Actual Results:

Does the problem occur:
Every time? Or how often?Yes, always.
In other games?
In other user accounts?yes
On other computers?yes

When does the problem NOT occur?
Never not occur
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Been happening recenly, once fixed but now back. I dont know which version it stopped then came back.
Workarounds:
Alright, this is my first time posting a bug so please bare with me. I am logged in. over 8 hours later or so, cpu rises at 55%-65%. basically, little by little, over time, the cpu rises over by 1% or so, then drops back to 0. i have no loops running so far I know of, I haved turned them all of from calling procs after log in. What can cause this weird issue? I have no MAJOR icons being loaded on the map. I'm idled, just sitting there, and cpu rises. Happens in both Dream Seeker from Dream Maker, and hosting with Dream Daemon. I have an icore 7 with 256 gb ssd. with a 1 tb hdd. I tested this sleeping over night, then wake up, bam, usage at 65%. And no procs has been called or any loops since I've been logged in.
I've had a similar issue. Could it be our code causing a memory leak or a Byond bug? I'm using the latest beta.
When you run the profiler, what do you see? Specifically, what does it look like early on, then a few hours later, then a few hours later, etc., using samples of maybe about a minute or two for each profile?

There have to have been proc calls somewhere in there. The server isn't going to make up work for itself, especially to such a high degree, so there must be more going on.
proc calls started before profiling start don't show up until they finish, so a sleeping while loop won't show.

You can find these by typing byond://?debug=status in the input bar

It will print a report of all connected clients and sleeping procs to output.
I took a much deeper look and more carefully and I found an infinite loop that I didn't know was there and technically was there for no reason. I must've accidently added that loop for health reasons but forgot about it. I'm glad I found that and removed. So far, that helped a lot with the usage. But I don't have the time to actually test it tonight cause I have to go to work, but afterwards, I will test again to see if that was the main issue I was having. I knew I had some infinite loop somewhere small. and MrStonedOne, thank you I will keep that in mind. @ lummox, I think I got this fixed. but will keep all informed. (nice name MrStonedOne)
In response to MrStonedOne
MrStonedOne wrote:
proc calls started before profiling start don't show up until they finish, so a sleeping while loop won't show.

You can find these by typing byond://?debug=status in the input bar

It will print a report of all connected clients and sleeping procs to output.

Where did you find that byond:// link? I can't find a reference anywhere
i ran strings on byondcore.dll
i dunno why i never added that to the red book, but it's also documented at the bottom of this post, with other variations:

http://www.byond.com/forum/?post=676227
I should add something to DD to show the status output.
In response to Lummox JR
Lummox JR wrote:
I should add something to DD to show the status output.

that'd be cool. I'm surprised I didn't have a feature request open for that already. (generally, it'd be cool to send client topics thru dream daemon as well, since what's what all the debug stuffs are)
you can do that, in fact you can call client.Topic("?debug=status") on a telnet client and it will print it out, this can be used to automate taking snapshot profiles as well using ?debug=profile
That small infinite loop I had going on earlier was the issue of that cpu usage rising. Apologies for this trouble, but I appreciate everyone's help =] I've test ran my source I've worked on for awhile for 2 hours and the cpu usage is fine now. Apologies for the trouble, but all this helps! I just need to remember what I worked on better.
we all learn something new every day eh?
Hey, I'm glad this came up. I can look into adding something in DD to improve diagnostics for game creators.
While your at it, a way to access this info (as well as profile info) from within the code would be nice, we could automate taking snapshots and logging them.

min/max/stdev as well as stats for how long was spent while world.tick_usage was > 100 would also be super helpful.

The downside is, adding min/max/stdev would increase the teardown time for each proc.

Also there's no accurate way to measure standard deviation, because it requires keeping a running tally of the square of the run time for each proc call instance. All of the current timing is based on linear recording which can be split up across resume-from-sleep, so alterations would have to be made to tally the total and then square it when ready. Plus, I'd have to figure out how spawn() should be handled, since it effectively forks a proc; because to get a square of the total run time for a call instance you'd have to combine the times for all "child" instances (and "fork" parentage isn't tracked), I don't think there's realistically any way to account for spawn() properly in terms of standard deviation.
min/max/overrun would work as well. if you give us incode access to the profile data, we could also track this ourselves and store/calculate the stdev of snapshots we take as a compromise