|
Anaristos Sorcerer
Joined: 17 Jul 2007 Posts: 821 Location: California
|
Posted: Sun Sep 13, 2009 9:15 am
[310B] CMUD is compute-bound |
For the last few days I've been watching the CMUD processes. The main process is using between 23% and 66% of the CPU even when only the MUD tick is the only MUD output (ever 30 seconds) which is as close to being idle as one can be. The increase in CPU activity does not correlate to anything that I or the MUD is doing. The surges actually just occur. CMUD is obviously doing something that requires a lot of CPU cycles. Any idea what?
|
|
_________________ Sic itur ad astra. |
|
|
|
Tech GURU
Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Sun Sep 13, 2009 4:08 pm |
There could be a couple of things happening here.
You said the only output is the MUD tick, but depending on how many triggers you have (how you settings are organized) even the MUD tick can require some significant processing. Also consider if you have large and complex settings even a simple update can cascade into several updates for you many of your CMUD settings. As an example, let assume you have a prompt trigger to update HP and MP. It's not unreasonable that a value update there will trigger some gauge or button updates and maybe a few other variables. Those variables may have other settings and other settings dependent on those variables also now need updating. Then you have background threads that take care of things like logging and settings storage. These effects are even more pronounced when the settings editor is open.
All of that said the behavior does sound anomalous and should be looked into. First I would monitor the debugger (when you start noticing this behavior) to see what CMUD is actually doing. If you don't see anything there, I would try disabling all settings. If the behavior still occurs then we can be sure it's definitely related to the CMUD code.
Couple of other things to consider. When was the last time you did a restart of CMUD or perhaps even a reboot. I'm not suggesting that this should be the first and only remedy but I think we've all seen behavior from programs that computers that have been running for a really long time. |
|
_________________ Asati di tempari! |
|
|
|
Anaristos Sorcerer
Joined: 17 Jul 2007 Posts: 821 Location: California
|
Posted: Thu Sep 17, 2009 3:27 am |
Thanks for the suggestions, Tech. I haven't been able to see anything going on in re the MUD interaction so I don't have any idea what is causing this. One thing I've figured out, though, it that the behavior happens roughly around the same time of day everyday.
|
|
_________________ Sic itur ad astra. |
|
|
|
Liath Novice
Joined: 25 Aug 2009 Posts: 38
|
Posted: Mon Sep 21, 2009 4:45 pm |
Something that might be the solution... something I noticed with my computer now and again.
Do you have Nero Burning ROM (most of the latest builds do this)?
I noticed that the indexing program it installs seems to be munching on cycles... but the oddest thing is that its making *other* programs show the CPU%.
NMIndexingService was s culprit to me. Made certain programs (unsure why/how) go nuts when trying to read memory or the disk. Killing the service solved the problem for me.
I'd suggest opening a process monitor and seeing if there is a program that is open or active at these times that isn't during others. If you have Nero, turn off that stupid indexing service (I saw absolutely no use for it anyhow). |
|
|
|
|
|