The purpose of this blog entry is to explain expected behavior for the various System Utilization settings available in the Performance tab when configuring an On Demand Scan.

 

IMPORTANT

The behavior of this setting changed in Patch 2. It changed again in Patch 4. It changed again in Patch 5. For simplicity and to avoid confusion, I'll only describe the latest behavior here in detail.

The possible settings are:

  • Low
  • Below Normal
  • Normal

 

Low

The product will create 1 thread per CPU for scanning, up to a maximum of 8.

  • If you have 2 CPUs, only 2 threads will be created for scanning.
  • If you have 24 CPUs, only 8 threads will be created for scanning.

 

Below Normal

The product will create 1 thread per CPU for scanning, up to a maximum of 12.

  • If you have 2 CPUs, only 2 threads will be created for scanning.
  • If you have 24 CPUs, only 12 threads will be created for scanning.

NOTE

There will be little to no difference in behavior when comparing a "Low" and "Below Normal" setting on a system with up to 8 CPUs.

There will be little to no difference in behavior when comparing "Low" and "Below Normal" settings on a system with 8 CPUs vs a system that has 64 CPUs.

 

Normal

The product will create 1 thread per CPU for scanning, up to a maximum of 16.

  • If you have 2 CPUs, only 2 threads will be created for scanning.
  • If you have 24 CPUs, only 16 threads will be created for scanning.

NOTE

This setting is not recommended for environments that are concerned about impacting end Users, and/or the performance of active applications.

 

Increasing the Thread Count

It is possible to override the built-in behavior for how many threads are created. This should only be explored under guidance/recommendation from Intel Security Support.

Most environments will not have any need to exceed the described values above. The goal of the above values is to facilitate scanning that completes in a timely manner without impacting the User, and for each higher priority setting to be functionally capable of completing a scan faster than the lower setting.

To raise the thread count requires adding registry values that override the logic in the code. It would have to be done on a per machine basis, because there's no mechanism to calculate the number of CPUs and then overwrite the default behavior with an intelligent value appropriate for the number of CPUs found on the system - that all has to be done by a human. Intel Support can assist in advising how to accomplish this, but it would be a Product Enhancement Request (PER) for this functionality to be automated or manageable via ePolicy Orchestrator.

 

Archive Scanning

The archive itself, as in the wrapper that contains the archived files, will be scanned even if the Archive Scan option is disabled; the contents however will not be scanned unless the Archive Scan option is enabled.

If the ODS setting to Scan Archives is enabled, then the thread priority setting explained above does not apply.

Scanning archive files is not best practice, except for environments that insist upon a higher standard of security and favor security over performance. Archive file's content does not pose an immediate threat to the system, therefore the contents of an archive do not need to be scanned.

For an archive file's content to become a threat, the contents of the file must be extracted - and thereby it is no longer an archive, allowing the extracted files to be scanned using that existing On Access Scanner configuration.

 

 

Related Information

KB82021, How the Scan Engine scans files with VSE

KB55145, Understanding the VirusScan Enterprise On-Demand Scan system resource utilization

KB85925, ODS thread count in VSE 8.8 Patch 5 and later