A better solution by Eset is needed

I installed the new version of Eset NOD32 AV in clients, by upgrading from v3 to v4.

I was told, and it's something I also noticed in my system, that, despite there's no 100% CPU usage, even with advanced settings all on, sometimes there are CPU spikes that go near 100% (95% ~98%).

It's been said before, in this thread, to check with Promon, by Sysinternals, to check what file/process/folder was making ekrn.exe causing this spikes.

Well, not all users are that capable of understanding a thing of what it is shown to them. It's the reality of life.
My IT department also won't monitor each system to find out what is causing the spike. Nor should we have to.

It's not up to the users or us, to find out what is the problem.

So, and this is a suggestion I believe should be considered - Why doesn't Eset implement the same sort of monitoring tool into your products, and make it report when it finds a file/process/folder that's causing a spike?

This would make things a lot easier to figure out what is causing what, for users and IT departments.

I also tried to disabled advanced heuristics, and I honestly, still witness those spikes once in a while.

This is a problem that's been haunting Eset since last year, and practically a year.
Telling the user that turning advanced settings will cause system perform slower, is no solution. Then, just don't implement such features. Otherwise, users will be paying for something they won't be using, otherwise they'll have high CPU usage.

The solution, and it's my most honest opinion, lies on Eset implement a monitoring process into EAV and ESS and report what's causing CPU spike at one given moment.

Thanks

Regards

 

AMEN, why should we be spending hours of our time scavenning through our data for the "funky file"? That might be ok in days where 40 Gig HD were the tops but no with multi Terabyte arrays that is hardly a simple task and I have better things to do with my time...unless of course ESET decides to pay the users for finding files then I am game.
I am billing $45 per hour, PM if interested.

 

But v4 now displays what file/url is being scanned by its associated scanner so you don't have to use process monitor to track down a conflict by hand

 

Even a better reason why ESET should include an "DEBUG MODE" that you can run to see which files takes the longest...after all "v4 now displays what file/url is being scanned by its associated scanner ." Most of the job is already done so now just take it a step further.


I know I sound like I might be bashing ESET...well frankly I guess I am...but not because I don't like them.
I am and have been a user of NOD32, and I used it mainly due to it's light resource usage and the ability to perform AH for IDW strains. I just want ESET to find a solution to this problem, since it turns any respectable machine with any respectable workload into bricks. I did not get a multi-core system to have one of those cores fully chewed up by an AV. It would be acceptable if you knew that the AV detected 100% of all infections but ESET can barely pull 94% in most tests.

 

I'm aware of that, but, that's far from being the solution.

What I believe that should be achieved, and I'm not a programmer, so I apologize if this is out of reasonable thought, is a monitoring feature that would make a record of the used CPU while scanning real-time. Then people could filter results of CPU spikes, to find out what is causing those huge spikes.

For example, let's imagine that from 6 PM to 6:10 PM, there was a huge spike for the file Y.doc. A record should be kept. EAV/ESS could even alert the user that there was a spike while scanning X, Y or Z file/other.

I don't imagine my self looking at the current implemention in v4 to see what file, etc., is being scanned, while I'm also looking at the taskmgr or alike tool to see the amount of CPU used.

Can you imagine this for a few systems? It's insane.

A better solution is needed.


Regards