end point workstations slow down during update

Thanks Darren.

I would agree, hard links will solve the major slowness issues here. What people might not understand is that when disks spend time servicing requests, you WILL NOT see CPU usage rise and in fact, you may actually see it fall as the CPU idles waiting for IO requests to complete. When disks fragment, the service times increase dramatically and you end up with long request queues on the IO bus. The dead give away here that this is happening on your Sophos install is when you see the green bar flickering up and down on the Sophos shield and the hard drive light is light up solid. The transition of the release folder to temp and back again occurs during the 'Blue' phase of the shield and it's only when the shield goes grey that you're into the actuall installation phase of the update.

In my setup here, we're typically using P4 2.4Ghz machines runing XP SP2/3 and typically with 512MB or 1GB ram with IDE disks. We have update checks occuring every 30 minutes and when an update happens, a typical update will last around 30-60 seconds. When fragmented (say 2 to 3 weeks down the road on a 40GB disk with approx 15GB free), we will see update times meassured in minutes typically 90 to 180 seconds. Most noteable is the startup update which can take 5 to 10 minutes because the whole machine is dragged down by all the normal load up times and now the update cycle copying 100MB's of data back an forth.

Having almost no files move will cure most of the issues but I have to ask the obvious questions here: Hard links are just pointers to the original files, so why not just checksum the original files 'in place'? You have the new and old cidsync.upd files and therefore know which files are old and which are new, why not simply download new stuff to the temp folder and checksum files in current location then if all is good, move new stuff in and clear down anything not in the new cidsync.upd. This way you still guarantee 'known good' as much as using your current method but minimise all file system changes almost as much as possible?

Matt

Thanks Darren.

I would agree, hard links will solve the major slowness issues here. What people might not understand is that when disks spend time servicing requests, you WILL NOT see CPU usage rise and in fact, you may actually see it fall as the CPU idles waiting for IO requests to complete. When disks fragment, the service times increase dramatically and you end up with long request queues on the IO bus. The dead give away here that this is happening on your Sophos install is when you see the green bar flickering up and down on the Sophos shield and the hard drive light is light up solid. The transition of the release folder to temp and back again occurs during the 'Blue' phase of the shield and it's only when the shield goes grey that you're into the actuall installation phase of the update.

In my setup here, we're typically using P4 2.4Ghz machines runing XP SP2/3 and typically with 512MB or 1GB ram with IDE disks. We have update checks occuring every 30 minutes and when an update happens, a typical update will last around 30-60 seconds. When fragmented (say 2 to 3 weeks down the road on a 40GB disk with approx 15GB free), we will see update times meassured in minutes typically 90 to 180 seconds. Most noteable is the startup update which can take 5 to 10 minutes because the whole machine is dragged down by all the normal load up times and now the update cycle copying 100MB's of data back an forth.

Having almost no files move will cure most of the issues but I have to ask the obvious questions here: Hard links are just pointers to the original files, so why not just checksum the original files 'in place'? You have the new and old cidsync.upd files and therefore know which files are old and which are new, why not simply download new stuff to the temp folder and checksum files in current location then if all is good, move new stuff in and clear down anything not in the new cidsync.upd. This way you still guarantee 'known good' as much as using your current method but minimise all file system changes almost as much as possible?

Matt