4 Replies Latest reply on Oct 20, 2015 10:17 AM by wwarren

    Controlling the performance impact of a scheduled scan


      We have been increasing receiving complaints about the performance impact of on-demand scans. For various reasons, these must occur while systems are active, so we are looking to minimize the impact on the system.


      We have seen some articles about setting things like dwMaxThreadsLow in the Best Practices Guide (link) and dwUserDefinedMaxThreads in the Patch 4 Release Notes (link), but then noticed they values will get removed when installing Patch 5 (link). Are they registry values still consumed and supported? What is the right way to lower the number of threads? The high/below normal/low slider have demonstrated to not be sufficient for many users. The duration of scan is less important than avoiding impact.


      We are running VirusScan 8.8 Patch 5.


      Anxiously waiting for Endpoint Security 10.1 to go production, which has the "no impact scans", but it will be at least a couple months after release before we can deploy.

        • 1. Re: Controlling the performance impact of a scheduled scan

          Typically the impact felt by an ODS when it has already been configured to run at below normal (or lower) priority, is from the archive setting being enabled. Does that have to be enabled, if enabled?  Because, the priority setting is of little value in that scenario. The act of exploding the archive in memory and scanning content occurs outside the control of the ODS feature.


          The registry values you refer to are indeed removed by P5+ on purpose. They were of use with Patch 4 (because P4 had a bug that affected thread count) and the values allowed overriding the bug. But that issue is fixed in P5+, along with redesigning how the priority setting affects the thread count.

          We don't really want you playing with registry values... it can still be done but the value names have changed, to help with making it more difficult to enter into non-supported product usage pathways. If you're truly determined, process monitor can reveal to you what those values are but it would be appreciated if you'd avoid publishing them on forums so that folks engage with Support rather than venturing down pathways toward the unknown.


          With P5 and later -

          1. if a system has 8 CPUs or less then we'll seek to use CPUs; i.e. use up to 8 threads for scanning.  The priority setting affects thread priority but realistically there's little/no performance difference between Low | Below Normal | Normal.
            NOTE: You would never choose "Normal" unless you don't care about impacting Users.
          2. if a system has 12 CPUs, at "Low" it'll perform like A. above (leaving 4 CPUs for the OS to serve other processes), but at "Below Normal" and "Normal" we'll use those 12 CPUs also.
            That means "Below Normal" should complete in shorter time than "Low", theoretically - we don't actually try to control the CPU, we leave that to Windows to decide
          3. if a system has 16 or more CPUs, then at "Low" it'll perform like A. above, and at "Below Normal" it'll perform like B. above, whereas at Normal it'll use 16 CPUs. Adding more CPUs at this point makes no difference to thread count or performance.


          And, as alluded to, we have registry values that override this behavior such that you can specify more threads for scanning if you have more CPUs available and want the ODS to take advantage of them.

          It's also possible to use the registry values to train-wreck your system (in theory at least), hence my reluctance to just post the details here.

          • 2. Re: Controlling the performance impact of a scheduled scan

            Does the enduser feel any performance change if i start an ODS running at below normal(or normal)?

            • 3. Re: Controlling the performance impact of a scheduled scan

              In our case, we didn't seem to notice any difference between Low and Below Normal. We never tried Normal as there didn't seem to be a reason to try having more utilization.


              Our benchmarks have shown the number of threads to ultimately allowing disk I/O issues, so even though the CPU scheduling was lower than normal, we'd still see bottlenecks. So far my testing has shown some promise for us. For the reasons wwarren stated, this probably shouldn't be anyone's go-to solution, but in our case, we needed something.

              • 4. Re: Controlling the performance impact of a scheduled scan

                For most environments there will be no noticeable difference from a User's perspective between "Low" and "Below Normal". Windows is really good at managing thread priority.

                If you choose "Normal" though, expect they will instantly know when the ODS is running. And then the same is true if Archive scanning is enabled, regardless of the priority setting. Best practice is to avoid scanning archives, since their content poses no threat and in order to become a threat it must be extracted and thereby is no longer an archive.

                Environments that take the position that all files must be scanned, even if they're an archive, are choosing to accept security over performance. Those environments probably want the ODS to complete in as short a time as possible since performance for the User is less of a consideration. They would consider running ODS at "Normal" priority, and they'd definitely want to raise the thread count beyond 16 if they have the CPUs for it.


                Factoid: When archive scanning is disabled, the scanner still inspects the archive wrapper (which may be infected) but the contents of the archive will not be scanned.