Laptop hanging on auto-update when first switched on

Hello Mike,

it seems to be slow during syncing the files (there's already a significant delay after the empty first CIDSync(CidSyncMessage):). Of course a sync is to be expected (i.e. new files have been added to the CID) after the computer is switched on,  but otherwise the "first update" is not special and thus I assume the almost-hang also happens once or twice during the day - the logs should show this. I notice that it takes another three seconds from the CIDUpdate(PrimarySuccess) to ALUpdate(DownloadEnded) - my desktop is in its 9th year but there it completes in less than a second. The SAVXP sync constantly takes about 20 seconds - this would be a factor of 60. Admittedly I have no explanation for this. Guess AutoUpdate is checksumming the cache files at this point - nevertheless this shouldn't monopolise the CPU (and AFAIK it's neither I/O- nor memory-demanding).       

You didn't mention the machine to be generally slow and even if AutoUpdate syncing would expose some "hidden" hardware problem I'd expect it to show elsewhere as well.

Thinking about it - if Outlook seems to freeze and other applications hang they must have been started already when AutoUpdate kicks in. If AutoUpdate is disabled (and then a manual requested)  or delayed for, say, 900 seconds - is the behaviour the same?

Christian

Hi Christian, thanks for your speedy response. 

Updates throughout the day seem ok and not causing a performance hit on the machine. A later update cycle shows the process being much quicker (although I guess there is less definitions to download than say first thing Monday morning after the weekend):

Trace(2012-Sep-10 11:17:13): CIDUpdateLocation::Sync - Updating from http CID: http://********/sophos/CIDs/S001/SAVSCFXP/savxp
Trace(2012-Sep-10 11:17:13): CIDSync(CidSyncMessage):
Trace(2012-Sep-10 11:17:13): CIDSync(CidSyncMessage): zbot-ciw.ide
Trace(2012-Sep-10 11:17:13): CIDSync(CidSyncMessage): ranso-iq.ide

*********************************

Trace(2012-Sep-10 11:17:55): CIDSync(CidSyncMessage): shakbl-a.ide
Trace(2012-Sep-10 11:17:55): CIDSync(CidSyncMessage): krypti-l.ide
Trace(2012-Sep-10 11:18:26): CIDSyncCallback, SynchronisationTerminated - Code = 0
Trace(2012-Sep-10 11:18:26): CIDSyncCallback, SynchronisationTerminated - MapFile = C:\Program Files\Sophos\AutoUpdate\cache\savxp.map
Trace(2012-Sep-10 11:18:27): CIDUpdateLocation::SyncProduct - Product Checksum: c73f85638ec0a090bd57d531fd136c75
Trace(2012-Sep-10 11:18:27): CIDUpdate(PrimarySuccess):
Trace(2012-Sep-10 11:18:28): UpdateLocationFacade::SyncProduct: Last Update Mechanism = CID
Trace(2012-Sep-10 11:18:28): CIDUpdateLocation::SyncProduct - Updating Product: Sophos AutoUpdate
Trace(2012-Sep-10 11:18:28): CIDUpdate(SyncProduct.Start): Sophos AutoUpdate, http://********/sophos/CIDs/S001/SAVSCFXP/
Trace(2012-Sep-10 11:18:28): Checksum found in master.upd matches cached cidsync.upd : bf9b3c06. Skipping download
Trace(2012-Sep-10 11:18:28): CIDUpdate(PrimarySuccess):
Trace(2012-Sep-10 11:18:28): ALUpdate(DownloadEnded):

I will test by delaying the morning update by disabling the autoupdate service and letting everything settle down for 10 minutes before re-enabling the service. The laptop is an XP client and therefore I can't set the service to be on a delayed startup. I guess other things like a little house keeping, defrag, stopping unneeded start-up programs, disk indexing etc might speed things up a little. 

Hello Mike,

I guess there is less definitions to download

Likely but that might not be the cause for the slowdown: Note that the final steps (after CIDSyncCallback)complete much faster - though they might depend on the number of new entries - and also the "idle" sync for AutoUpdate and the last step to DownloadEnded (which are independent) take significantly less time.

Christian 

Hi RogueViper,
 
For XP, this is not that unusual unfortunately. It's important to understand the autoupdate process to know why this becomes a problem over time. AU starts by downloading the 'list' of current files from the CID and comparing these with it's local list. If a difference is established (no matter how small), the entire SAV cache folder is then linked using junction points to the tempsavxp folder (this process though only links is still quite IO intensive and you can see this if you ever 'view updating status' where you'll see nothing yet downloaded and the disk drive thrashing away with 'connecting to server' then 'downloading' (the actual downloading will probably occur very fast). Once downloaded, the old SAVXP folder is deleted from the cache and the TEMPSAVXP folder then moved to SAVXP and the installation/update commences.
 
Moving this block of 100MB's+ constantly over time causes huge amounts of disk fragmentation on the drive and over time, the machine gets worse and worse until you see times very much like you are seeing. It used to be much more noticeable under v.7 than v.10 before junction points were introduced but it's still a significant problem in v.10.
 
Fairly easy remedy is to run defrag not just the once, run it 2 or 3 times to properly consolidate the file pieces. Also, check that the pageing file is not defragmented at the same time and if it is, use pagedefrag (from sysinternals) to consolidate that after you have run a full disk defrag.
 
Rule of thumb to remember, a disk with > 60% space used will fragment much more quickly than you would expect so it's worthwhile if you can, making sure that you keep below this golden number.
 
The problem is not so apparent on Vista and 7 because they have built-in tasks to defrag disks all the time which means you don't tend to run into this problem as much.
 
Matt

Good point, Matt. The effect should be the same for all updates if this were the only cause. As an aside: call it a folly, call it a mannerism of mine - I use to make the system+user drive unreasonably small (<32GB for XP) and to fill it up to the point where I have to move files between volumes for larger software updates (read: less than 3% freespace). Defrag ...  defrag ... guess it'd refuse to start analysis. No problem at all with AutoUpdate or its performance though. 

Christian