Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000527SUMoBugpublic2008-03-29 09:142009-01-03 10:22
ReporterZer0 Voltage 
Assigned ToKyle_Katarn 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionreopened 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version1.8 
Summary0000527: 85-95% CPU Usage by SUMo.exe During a Scan or Check
DescriptionI never noticed before today because I normally don't do anything else while SUMo is running, but when SUMo performs either a scan or check the CPU usage for SUMo.exe drastically jumps to anywhere between 85% and 95% under Windows XP.

It's usually on the lower end during a scan and sometimes doesn't always stay above 85% during scans either (but not always). Deep scans will normally keep the CPU usage at the higher levels longer. In some cases, for reasons I can't explain, a scan will not cause a jump above 50% at all - even on a system where previous scans did cause a jump.

But during a check, SUMo.exe always jumps up right away to 85% or higher and then continues fluctuating between 85% and 95% until the check completes (at which point it immediately drops back to 0%).

Oddly enough, it's not as high under Vista. On the same system which dual boots between XP and Vista, I would see an 85-95% spike under XP but 75-85% under Vista (which is still incredibly high). This system has a 2.8 GHz P4 and 1 Gig of RAM and nothing else was running, so that's pretty significant.

Also odd is that SUMo.exe rarely goes above 20% when performing the database load during starting up. The huge spikes only happen during scans and checks. On my desktop where it takes 5-10 minutes to start, however, it does sometimes jump as high as 50% during that startup load and during the database reload which occurs after a scan completes (though it doesn't stay that high for the entire time).

I have reproduced this on multiple systems, but I assume the spikes might not be as bad on more powerful hardware with more system resources.

I also do not see this happen with any other software which does constant intense network and hard drive I/O - just SUMo.

The big problem here is that whenever SUMo does a scan or check, there can be cases where the system becomes unusable until SUMo completes. SUMo cannot just run in the background if a user needs to be doing anything else requiring significant (and possibly even normal) CPU resources.

During testing where I had other intensive programs running, I've actually been able to completely lock out a system. Nothing responded to the keyboard or mouse until the SUMo check completed.

When other high CPU processes are running, however, SUMo.exe doesn't usually hit the 85% mark because the OS splits the resources between it and those other running apps. So SUMo might stay below 85% if other processes are taking up significant CPU resources, but the total CPU usage will still hit 100% just because of the added excessive SUMo load (at which point a system can become unstable).
TagsNo tags attached.
Attached Files

- Relationships
related to 0000815acknowledgedKyle_Katarn 43% CPU usage during version checking 

-  Notes
(0000233)
Kyle_Katarn (administrator)
2008-03-29 10:59

 I'll try to reduce thread's priority
(0000234)
Zer0 Voltage (reporter)
2008-03-29 23:32

 Thanks!

Perhaps the priority can be made into an option?

Then people who want to run SUMo alone and manually can set it higher while those who want to use it at startup or as a background process can set it lower.
(0000238)
Orionizer (reporter)
2008-03-30 14:01

 Acknowledge here as well.

Also, I second the ability for a user defined thread priority...
(0000239)
Kyle_Katarn (administrator)
2008-03-30 18:04

 OK !
(0000266)
Kyle_Katarn (administrator)
2008-04-03 21:02

 Thread priority set to "Lowest"

Please tell me if behavior is improved
(0000269)
Zer0 Voltage (reporter)
2008-04-04 07:27

 Sorry to reopen this, but where is the code we should be testing?

I tried downloading from the beta location here:

ftp://ftp2.kcsoftwares.com/kcsoftwa/beta/sumo.exe [^]

But I still just get the previous 1.7.0.42 beta build.

Thanks!
(0000273)
Kyle_Katarn (administrator)
2008-04-04 19:59

 v1.8 BETA is about to be sent for Beta test... in a couple of minutes... ;-)
(0000276)
Zer0 Voltage (reporter)
2008-04-05 00:58

 Sorry, no luck. Exact same CPU overload problems with the v1.8.0.43 beta. Not even a single percent lower.
(0000284)
Kyle_Katarn (administrator)
2008-04-05 08:47

 Thread's priority isn't good enougth ...
Maybe a 100ms delay between 2 program check ?
(0000293)
Tux (reporter)
2008-04-08 17:41
edited on: 2008-04-08 17:43

 I rather wonder what you've changed that it doesn't work fine anymore. :-) ...

But I noticed that the current beta version's startup time has significantly been sped up.
(0000294)
Kyle_Katarn (administrator)
2008-04-08 20:21

 Great !
(0000297)
Zer0 Voltage (reporter)
2008-04-10 03:33

 I don't know what Tux is seeing, but the startup time for me isn't improved at all. Especially on the first start after a system reboot. Usually successive starts are very slightly faster.

With regard to the CPU load, I suppose it couldn't hurt to try the delay between program checks - but I don't know if that will help. I watch streaming video and run P2P apps all the time and they do far more intensive disk and network processing without any pauses yet still don't cause any CPU spikes.
(0000301)
Kyle_Katarn (administrator)
2008-04-11 19:44

 Successive starts are faster thanks to HDD / Windows cache of such data.

As said before my idea for perfo improvement is to assume nothing as changed since last execution and to scan on user's demand for changes.

Will be implemented soon, but a bit tricky ...
(0000466)
Kyle_Katarn (administrator)
2008-11-23 09:25

 Is it better now ?
(0000479)
Kyle_Katarn (administrator)
2009-01-03 10:22

 A potential root cause has been identified in the "Check" dialog timer management routine

- Issue History
Date Modified Username Field Change
2008-03-29 09:14 Zer0 Voltage New Issue
2008-03-29 10:59 Kyle_Katarn Note Added: 0000233
2008-03-29 10:59 Kyle_Katarn Assigned To => Kyle_Katarn
2008-03-29 10:59 Kyle_Katarn Status new => acknowledged
2008-03-29 23:32 Zer0 Voltage Note Added: 0000234
2008-03-30 14:01 Orionizer Note Added: 0000238
2008-03-30 18:04 Kyle_Katarn Note Added: 0000239
2008-04-03 21:02 Kyle_Katarn Status acknowledged => resolved
2008-04-03 21:02 Kyle_Katarn Fixed in Version => 2.8.1
2008-04-03 21:02 Kyle_Katarn Resolution open => fixed
2008-04-03 21:02 Kyle_Katarn Note Added: 0000266
2008-04-04 07:27 Zer0 Voltage Status resolved => feedback
2008-04-04 07:27 Zer0 Voltage Resolution fixed => reopened
2008-04-04 07:27 Zer0 Voltage Note Added: 0000269
2008-04-04 19:59 Kyle_Katarn Note Added: 0000273
2008-04-04 20:00 Kyle_Katarn Status feedback => resolved
2008-04-04 20:00 Kyle_Katarn Resolution reopened => fixed
2008-04-05 00:58 Zer0 Voltage Status resolved => feedback
2008-04-05 00:58 Zer0 Voltage Resolution fixed => reopened
2008-04-05 00:58 Zer0 Voltage Note Added: 0000276
2008-04-05 08:47 Kyle_Katarn Note Added: 0000284
2008-04-08 17:41 Tux Note Added: 0000293
2008-04-08 17:43 Tux Note Edited: 0000293
2008-04-08 20:21 Kyle_Katarn Note Added: 0000294
2008-04-10 03:33 Zer0 Voltage Note Added: 0000297
2008-04-11 19:44 Kyle_Katarn Note Added: 0000301
2008-10-08 20:27 Kyle_Katarn Relationship added related to 0000815
2008-11-23 09:25 Kyle_Katarn Note Added: 0000466
2008-11-23 09:26 Kyle_Katarn Status feedback => closed
2009-01-03 10:22 Kyle_Katarn Note Added: 0000479
2009-01-03 10:22 Kyle_Katarn Status closed => acknowledged

MantisBT 1.2.1[^]
Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker