Sophos 9.7 updates slow on Windows 7 32 bit machine

Hi,

I assume it's just after SAV actually updates (i.e. new ide files are downloaded) rather than just the checks to the CID to see if an update is required?

The update time asside, the fact the slow-down occurs just after an update, I can only assume this is due to the checksum cache being cleared, as when SAV obtains a new definition, SAV essentially starts building up it's checksum cache again.  As it can't count on the files it has already got checksums for being clean, based on the new data.

As an example. If I have a file or multiple files which are quite complex to scan and they are opened quite often by a piece of software, the first time they are opened SAV would scan them and it might be a bit slow.  The next time the file is opened, providing hte file hasn't changed and SAV hasn't updated, it wouldn't need to scan the file again so it would be quick.  So based on that you can see why after an update, depending on the software installed and the files it uses, it could be slow for a short time.

Also worth considering: are the scanning settings different from the defaults?  On-write? Scan all files? Scan inside archives? Does it help to retun the machine to the default on-access settings?

I would probably try and Process Monitor an update of a machine and see if this then causes SAV to start scan certain files again.  Maybe you could try introducing a few exclusions based on that test to see if that helps to narrow down the problem.

Regards,

Jak

Thanks for the quick reply.  Yes it is actually when the update is being applied that we see the SAVservice consuming resources.

We have tried the default settings but that didn't resolve the problem.  When do have exculsions added but so far we cant figure out why.  We currently only use the AV part of the EPP package so we are not using hips just alert only.

I can tell you that a few of the user have their laptops powered off and only attach them to the network maybe once a month and these seem to be the people reporting the issue the most.  I assume that their system are getting the update during their morning logon.  After the update has been applied their system performance returns.

I'm being asked now to try a different AV product by my management but I do not want to go that route as Sophos has been working for us so far.

Hi,

In that case, consider this, when a machine starts up, the Sophos AutoUpdate service starts (alsvc.exe), this then kicks off Alupdate.exe which performs the update a short while later.

So for these machines you could add the registry key:

32-bit machines

[HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\AutoUpdate]

"StartupDelay"=dword:0000000a

64bit machines

[HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Sophos\AutoUpdate]

"StartupDelay"=dword:0000000a

Where in this case, the Alupdate Process would kick off 10 seconds after the service starts.

Maybe if you add in a 5 minute delay (DWORD decimal "300") and increase in the updating policy the update interval to something like 30 minutes that might help these machines.  This way the client would be up and running fully, before SAV updated.

Also, I've noticed on my machine, which I think is a Windows bug, that although I might schedule a SAV scan for 9pm at night, I've found that it sometimes starts in the morning when I log on,  Looking at the history of the task confirms this behaviour even though none of the properties of the task are set to do this.  So checking that these machines aren't running scheduled scans at startup/resume might also be worth doing.

Hope that helps.

Regards,

Jak 

Hi,

Good advice!  I already set the AutoUpdate service to delayed start so that should give me the 10 seconds which did seem to help.  I checked the task scheduler and so far the histroy show the task only running off hours but I will keep an eye on that.

If I add the reg key below with a decimal valuse of "300" will it work even though I already set the service AutoMatic Delayed start?

32-bit machines

[HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\AutoUpdate]

"StartupDelay"=dword:0000000a

Thanks

I would think so; to test you could just check the AutoUpdate log files to see when the first check happens after startup.  You could check in the event log when the AutoUpdate service starts and compare the first update time.

Another approach might be:

1. Firstly add the key, run ProcessMonitor and restart the AutoUpdate service.

You should see that alsvc.exe kicks off Alupdate.exe so many seconds after the service started.

2. To test the actual startup of the machine you could use the same technique as Process Monitor has the Log boot option.

Regards,

Jak