CPU Checker

ID:273102
 
Sep 7 2009, 8:13 pm
I was thinking about putting this in my project to help ensure it doesn't crash:
world
    New()
        ..()
        spawn()CPU_Check()


proc/CPU_Check()
    while(world.cpu<90)
        sleep(50)
    world<<"World Rebooting to prevent a crash!"
    world.Reboot()


I want to know if it is very efficience to do it this way/if there's a better way/if I should do it, or something like it, at all? Any other criticisms/opinions welcomed.
Sep 7 2009, 8:48 pm
I'm not entirely sure of a situation where you're cpu usage should drop because of a reboot in the manner your speaking of. This method seems more like a band-aid for poor world design.
Sep 7 2009, 8:55 pm
In response to Jotdaniel
Oh absolutely it is.
Im not actually encountering any need for this check, but I would rather be prepared than be caught with my pants down.


"I'm not entirely sure of a situation where you're cpu usage should drop because of a reboot in the manner your speaking of"

Are you trying to say, you don't see how a reboot would stop a CPU spike? Well in the long run, no it wouldn't. But it would cease any and all procs currently creating it, and it would reboot and not crash: Thus saving everyone's file, and not left offline for a day.
Sep 7 2009, 9:15 pm
In response to Saucepan Man
Saucepan Man wrote:
But it would cease any and all procs currently creating it, and it would reboot and not crash: Thus saving everyone's file, and not left offline for a day.

Rebooting every few minutes isn't any better than being offline for a day.
Sep 7 2009, 9:28 pm
In response to Kuraudo
Saving files is better than not saving files.

You both seem to be thinking ive done something horribly wrong with my code and am getting ridiculous CPU spikes, and as such, you're both being quite condescending.

Fact is, I've gone out of my way to see what naturally existing attacks etc. create the most lag. Then I've gone and coded a specific verb so that I can simulate over 2000 people doing it at the same time.
And even then I only just managed to make the CPU exceed 120.
It was only by cycling through 2000-odd mobs with a for() proc 5 times a second for 3-5 seconds that I got the game to run out of resources.
Task manager tells me it was trying to use 1.3GB or so memory.

I purposely didnt bother creating an infinite loop because I assumed they couldn't be beat?
Sep 9 2009, 11:54 am
In response to Saucepan Man
Well, in that case, it seems you either are planning a game more massive than any BYOND has ever seen, or this just simply isn't needed. I'm leaning towards isn't needed, or if you feel asbsolutely positive you needs something like this you might want to increase the time period between checks. Like that other guys said, rebooting every 5-10 seconds is not going to help. Its either going to go crazy, or probably never do anything at all.
Sep 9 2009, 2:00 pm
In response to Saucepan Man
I've had situations where cpu would hit 200% and I still have never had a crash from it.

Only major lag due to queue'd up procs.

Cpu has never been a source of crashing for my games.

Anyway all I did was use ".debug profile" thing to see the procs doing it and fixed them.
Sep 9 2009, 9:28 pm
Saucepan Man wrote:
I want to know if it is very efficience to do it this way/if there's a better way/if I should do it, or something like it, at all? Any other criticisms/opinions welcomed.

It's not a good way to do it at all. Your game risks being rebooted simply because it got busy for a short period of time.

My advice is to remove crap like that since it's only going to do more harm than good. It's the same as with Windows' tendancy to hide a BSOD by rebooting the computer once one occurs. The result is that users complain about their computers rebooting "for no reason".

Fix the underlying issue; the issue causing your game to crash all the time.

Note that on a dual-core machine world.cpu probably will never reach 90% ever (it can go up to a maximum of 50%, for a single core). Furthermore if I'd put in your snippet in a game like SS13 (which eats up a lot of CPU for its air system but works nevertheless) it's going to reboot even as the game is running, causing an infinite loop that is most definitely going to cause a crash rather than fix one.
Sep 10 2009, 10:36 pm
In response to Android Data
Android Data wrote:
My advice is to remove crap like that since it's only going to do more harm than good. It's the same as with Windows' tendancy to hide a BSOD by rebooting the computer once one occurs. The result is that users complain about their computers rebooting "for no reason".

Fix the underlying issue; the issue causing your game to crash all the time.

Note that on a dual-core machine world.cpu probably will never reach 90% ever (it can go up to a maximum of 50%, for a single core). Furthermore if I'd put in your snippet in a game like SS13 (which eats up a lot of CPU for its air system but works nevertheless) it's going to reboot even as the game is running, causing an infinite loop that is most definitely going to cause a crash rather than fix one.


There is no underlying issue. Everything runs just fine, it was simply "just in case" sort of idea.

On a side note, world.cpu can happily reach 90%, unless world.cpu isn't outputting a %??
I coded a lag inducing verb so as to sort of test the cpu breaking point... world.cpu reach 220+ before it started threataning to lock up. And the last reading I got was about 280.
I have a dual-core processor.
Sep 10 2009, 10:41 pm
In response to Dragonn
Profile crashes if the game crashes; defeats half the point of profiler existing!
I did have a CPU issue a while back - I thought it would be a good idea to save everyones playerfiles once in a while. I inadvertantly called a save-all-mobs-in-world proc within a for(mobs in world); that crashed the game from CPU usage.
Ive also purposefully created a verb to create lag and it crashed at a little over 280 cpu.

Sep 10 2009, 10:49 pm
In response to Jotdaniel
You're missing the point.

Reboot: All playerfiles are saved and hours of gametime is not gone to waste. Glass half full.

Crash: Hours of gameplay down the toilet. Peoples time and effort wasted. Disappointed/angry players. Glass dropped and smashed on the floor.

No, I'm not planning on making such a huge game. But thanks for your sarcasm anyway.
I'm just acknowledging that I can make mistakes. If one of those is a mistake that causes the game to crash, the player files can be saved while I diagnose the problem and fix it.

And in 99% of these cases, such an issue would be located in a line of code not often called: or else I would notice it immediately when I test it. So if such an issue is rare, so will the crashes.
e.g. only when a player uses a certain attack.
Band-aid solution: Don't use that attack.

I don't think I can explain myself in any simpler terms!
Sep 11 2009, 7:36 am
In response to Saucepan Man
And, at this point, I'm going to link to the reference entry and point out that world.cpu is not the CPU usage % you see on the task manager. Instead, it essentially means how much time it takes to process one tick. A value of 100 means it takes precisely one tick to process one tick. At anything 100 or less, there is zero visible effect, as all calculations are done before it's time to start the next tick. At values over 100, there is a noticeable slowdown, as each tick has to be delayed in order to finish operations being performed on the current tick.
Sep 11 2009, 8:39 am
In response to Garthor
And because of that the value is going to be affected by outside processes as well. If a high priority process for instance sucks up the cpu for 3/10ths of a second your program may not have been able to execute much if anything during that time so the cpu value will spike to 300 plus the amount of time it takes to finish the tick. So your program could be running great and something else might trigger that reboot code.
Sep 11 2009, 1:00 pm
In response to Garthor
OOOooOOoooooHhhhh, that makes more sense now, thanks.
Well I just found this snippet on my computer from waayyy back when. I think it was written by a guy called masterdan, I've just modified it a little bit.
Is this a good reboot/anti-crash/rescue proc?
var
    WORLDADDRESS=world.address
    WORLDPORT=world.port
proc/Crash_Check()
    var/server = world.Export("byond://[WORLDADDRESS]:[WORLDPORT]?ping")

    if(!server)
        shutdown(server)
        sleep(100)
        startup('SoL.dmb',WORLDPORT,"-logself","-trusted")
        world << "World restarted at [time2text(world.realtime, "Day, Month DD, YYYY")]"
        Crash_Check()
        ..()
    else spawn(600) Crash_Check()
Sep 11 2009, 5:44 pm
In response to Saucepan Man
The recursive call is stupid. All the calls to Crash_Check() should be removed and the whole thing should just be wrapped in one big while() loop.
Sep 11 2009, 6:43 pm
In response to Saucepan Man
Saucepan Man wrote:
You're missing the point.

Reboot: All playerfiles are saved and hours of gametime is not gone to waste. Glass half full.

Crash: Hours of gameplay down the toilet. Peoples time and effort wasted. Disappointed/angry players. Glass dropped and smashed on the floor.

No, I'm not planning on making such a huge game. But thanks for your sarcasm anyway.
I'm just acknowledging that I can make mistakes. If one of those is a mistake that causes the game to crash, the player files can be saved while I diagnose the problem and fix it.

And in 99% of these cases, such an issue would be located in a line of code not often called: or else I would notice it immediately when I test it. So if such an issue is rare, so will the crashes.
e.g. only when a player uses a certain attack.
Band-aid solution: Don't use that attack.

I don't think I can explain myself in any simpler terms!

100% CPU will not cause a crash. It will slow down the game, though. If you're really that worried about it, how about just saving everyone's data and increasing tick_lag (which makes the ticks longer so the game slows down, but at least it's consistent and it can always be decreased again)