Active Scanning Out Of The Box Is Killing This Product

[dbaps 0]

Two years ago I stopped using ESET for this very reason, it's just too slow. I have three Macs and on each they perform the same. Yes, I am doing some intensive file open/close commands but it's not even usable. To top that off, I start getting resets on disk. I've looked at the settings. is it necessary to have active scanning on each time an open, creation, and execution of a file is done? How can I trim back the resources your product is taking friom my computer. I have a boot SSD and a 4-drive RAID-10 setup that just dies when I run Eset. I end up having to uninstall. This timeI want to ask for some suggestions. Maybe some setting changes will help but still protect my computer. 

 

2006 Mac Pro - Lion

2010 Imac - Mavericks

2010 MacBook Pro Mavericks

 

Thanks,

Paul

[Arakasi 549]

Hello dbaps, if possible find the option to remove the scan and heuristics on every single file, and leave only the option for newly created files or ones which have been modified (typically from malware).

This is essentially how the business portions of ESET work and are default settings.

The home portion has every file checked as default settings.

 

See attached pic please.

 

Source: hxxp://www.eset.com/fileadmin/Images/US/Docs/beta/eset_ecs_5_RC_userguide_enu.pdf

Edited July 13, 2014 by Arakasi

[dbaps 0]

I haven't changed any of the defaults since I just installed the product, It is currently setup as you say, to only use advanced heuristics on created and modified files under advanced options, and not checked under executed files which is the default. 

 

I do have some related questions after reading this section of the manual which may be impacting performance. In the ThreatSense Engine Setup, why isn't Advanced Heuristics checked under the options tab?

 

It says,

Advanced heuristics – Advanced heuristics is comprised of a unique heuristic algorithm, developed by ESET, optimized for detecting computer worms and trojan horses written in high-level programming languages. The program's detection ability is significantly higher as a result of advanced heuristics.

 

 

Since I'm scanning a very large number of files, should I increase the cached size? It also says,  "Files are scanned again immediately after each virus signature database update." Does this mean when a new virus signature is released each day (usually), all of my files get scanned again?  I can see the importance here if a new virus is being addressed by the signature and Eset needs to make sure that the new virus is not in any of my files. However, when is this done? It sounds like tremendous overhead, almost as if it's running a new scanning job on all of my files but just checking for the latest addressed vulnerabilities in the virus signature.

 

Also my files were being modified multiple times as they are music files with meta-data being updated. For example, a new album could be inserted into the song file. Plus any other information such as album year, songwriter, title correction. It literally could be making 25-50 modifications on just one music file. Does this mean for each modify it is being scanned again since modify is set under advanced heruristics? In this case would a larger cache file make a significant difference in performance? For example, if it's not in cache has Eset gone to disk to retrieve the file?

 

Finally in earlier products you set the nesting level to unlimited and now it's a value of 10.  Under what circumstance would I consider changing to a higher or lower nesting level value?

 

Thanks again for your help. 

 

 

[dbaps 0]

I have thousands of these in my console log...well really tens of thousands...19,421 songs being processed.

 

7/14/14 12:08:22.247 PM esets_daemon[267]: summ[010b0500]: vdb=19167, agent=fac, name="/Users/dbaps/Library/Application Support/TidyMyMusic/musicitem.db-journal", virus="", action="", info="Event occurred on a newly created file.", avstatus="not scanned", hop="accepted"

Edited July 14, 2014 by dbaps

[dbaps 0]

I have come to the conclusion that this product can not handle files that are having their music tags changed in large quantities. The console shows scans taking hours of time.  It's not just one product that tags music files either, it's all of the six that I've been testing. Plus I've been trying this out on three different Macs, two running the latest version 10.9.4, and one running the latest version of 10.7.5. I may be able to turn off active scanning, but that kind of defeats the purpose. That esets_daemon is a killer.  I've uninstalled this product and my console logs and the performance of each computer has returned to normal.

 

I attached just the last page of one console log. They all look like this page. I clicked on a couple of entries, one the Google Music Manager file scanner and the second Wondershare Tidy My Music for Mac. I've tested the Amazon upload, Picard, Jaikoz, Songkong, plus the two already mentioned, all with the same results.

[planet 232]

Hi dbaps,

 

For your 'resets on disk', try out the most recent release (6.0.13.0) that should resolve the Kernel Panics.

 

You can reduce the amount of scans performed by opening the program, clicking 'Tools > Scheduler', and unchecking the two entries with "User login" under the 'Launch time' column, then consider editing the "Startup file check" task (the remaining selected one, not the one you just unchecked) so the minimum task interval is set to 1 day (scanning your computer once a day) instead of every single time the database is updated, or to whatever you wish to set (eg. per week).

 

In the Console log, ESET by default logs every new or modified file discovered, but it can be disabled if you prefer not to see them.

 

It might be useful to see if adding exclusions for Google Music Manager (for example the 'ServerDatabase.db-journal' item) helps or not.