ESET 4.0.437.0: scheduled scans=100% CPU=weekly user complaints

Hi,

We switched to ESET a while back, mainly because of the small footprint and good scores. We're finding one thorny issue, though, that we didn't have with our previous solution--every Tuesday at noon our scheduled system scans run on all the machines...and every Tuesday, starting at perhaps 12:05, we can count on receiving support calls that "my computer has slowed to a crawl." For some people with lots of files, even two hours later, the scan is still running. CPU is at 100%, with ekrn.exe sucking up all the resources.

We really need to throttle this process back--is there some way of setting the process priority in the config?

Thanks for any advice you can provide. We're hoping to continue using ESET, but this is getting untenable--user perception is very negative.

 

did you try the latest version 4.2.58 ? Is the AV set to scan network drives? Set the schedule for some less busy time of the day?

 

I haven't tried the latest version, but I probably shouldn't have been so specific with version, anyway--this has been a problem for us since ESET 3 That's why I haven't really expected a new version would help. I think the application is working correctly, but it's way more obtrusive than our previous AV app in its scan behavior--we'd really like this to be a background type of process, so that it's barely, if at all, noticed by the user (something like "scan when idle," or at least something to throttle the process down).

It's not scanning network drives, no. And unfortunately, we can't schedule for a less busy time of day--we were aiming for a time we thought at least some people would be at lunch; we can't do the scan later in the day, or in the evening, because most people turn off their machines (and we want them to) overnight, and we have laptop users who take theirs with them. If we scheduled it later in the day, laptop users might have a terrible time shutting down, and would complain that they can't leave (yes, this does happen with MS updates).

 

Couldn't it be that several scans are being run when you observe the issue? See the on-demand scanner log, running scans show "Scanning in progress" in the status column.

 

We used to run weekly scheduled scans like this, but realistically Nod32 does a good job of scanning everything in active memory and regularly accessed after definition updates so if it did find something, it was always some garbage sitting in the browser cache directory that wasn't actively running and didn't matter. I would consider changing your policy and scaling back the occurance of full-system scans to far less than every week. We only do it once every 6 months.

 

We do it every 3 months, for the same reason. We ask people to leave their computers switched on at night on one particular day, and schedule the scan for that evening.


Jim

 

I wouldn't advise running a full scan during the day. Besides NOD does a smart scan with each update so it really isn't necessary to do a full scan during the day when someone is working on their pc. I have full scans only scheduled to run overnight. So if a pc is left on at the end of the day it will run then.

 

Thanks--I guess we'll have to consider something like that. Still, it'd be good if ESET built some sort of process-priority setting capability into the program; we never had an issue with Symantec scans running in the middle of the day--users simply never noticed them, zero complaints.

 

We also switched from Symantec to ESET and also run a scan at 12:00pm on Fridays. We have received some complaints about it from users, however every complaint we have had has been in reference to the "Internet is slow". If your setup was like ours, the old Symantec we were using wasn't scanning web traffic at all, while ESET is. That seems to be the only complaint we get is when the scan engine is running, web pages clearly are slower to load. In that case we tell them to quit surfing the Internet, and go to lunch.

 

These problems with 100% CPU usage is not from now. Make a search on this forum, and you'll see people complaining since pretty much about 2 years, or even more.

I was hoping this has been solved; seems not, though.

This was the reason why I uninstalled it from my relative's system last year.

 

Scan tasks already run with a low priority by default (assuming you didn't override them)





As you can see, while the CPU prioritization has a base value of 6 (Normal), the scanning thread is dynamically reducing it's priority as other processes/threads compete for CPU time. Sluggish response during a scan is typically due to disk I/O saturation, NOT competition for CPU time and this is especially true when it is trying to unpack archive files. Windows resource scheduler doesn't appear to have the ability to dynamically adjust priority for I/O like it can for CPU time. Eset could in theory lower the I/O priority of the scanning thread, but if there is anything else throwing around lots of IOPS the scan task is never going to complete. Your best bet is to play with the archive scan limits and see if you can improve things that way.

 

Hello,

Could you tell me whether or not you have advanced heuristics enabled, or if it is even present in newest versions?
That seemed to be the culprit back then. But, having paid for a product with X capabilities and not being able to use them, then I stopped using it.

Edit: By the way, only a few moments back I realized that the 100% CPU usage is due to scheduled scans. If the problem I was relating to as been solved, then that's great news.
I apologize if someone got mislead by my previous comment. Sorry.

 

Advanced heuristics are enabled for file execution and the scheduled scan, not for all real-time scanning (default settings, basically). Conflicts are going to be highly dependent on what kind of software you are running. Some programs just do not react well to real-time scanning as they are rapidly accessing the file, modifying it, then releasing the lock and repeating. If a program is doing this with things on the file system, that is where you need exclusions.