I've been testing SESC9 for a few months and found the following:
Savservice.exe starts with about 94MB of memory after install.
Our managed nodes are setup to fail over to Sophos for updates if they can not reach our sites. When this occurs the Sophos site installs 1 of 1 and savservice.exe increases in memory use.
This same thing occurs when our node comes back to update from our site install 1 of 1 and savservice.exe increases in memory use.
If checked nodes in our testing and saw savservice.exe running 200MB, 300MB and 1.2BM of memory.
I tested this on my computer and watched savservice.exe go from 94MB to 140MB before stopping my test.
I look forward to seeing what you have experienced.
I have seen the savservice.exe begin to run wild since 9.0.4 VDL4.51G was released. At start-up the service ran very high and our users were crippled until after alupdate.exe executed (which was taking much longer than in the past). I've disabled On-write from our On-Access Scanning settings. I also turned Web Scanning off but it seems to me that the On Write feature of On-Access Scanning was the culprit. Something is amiss as many of the knowledge base articles that my searches returned have been modified in the past 8 days. My main Update manager is also not properly updating. I'm having to perform manual updates.
Secondly, as HIPS policy settings, and those for Application Control, are not included in KBA 14245''s list of recommendations, these may need to be checked when isolating scanning issues:
Detect suspicious behavior Detect buffer overflow Alert only If ''alert only'' is selected, HIPS scanning will still take place. Alerts are sent to the Enterprise Console, as well as appearing locally in the Quarantine Manager.
Note that scanning for Application Control can still occur when regular on-access scanning is disabled, because the option above is not dependent on that setting.
3) Additionally, please check if Web Content Scanning is enabled. For details on how to do that, please see:
I would suggest you go through the above details one at a time, to see if you can isolate the component which is responsible for the change since this update. I am suspecting it is the BHO scanner - Web Content scanning - because some other customer have been reporting similar issues recently, although it ultimately often is coincident with an update to IE8.
Let me know what you find."
Again, in my case, disabling On-write from our On-Access Scanning settings seems to have done the trick.
I've worked with Sophos tech support under two separate cases. Both have been escalated to global support. I also have a Sophos engineer that confirmed he saw the same thing in his testing. He will be overseeing the status of my cases.
When I hear back on their status I'll post it here.
That's good to hear. Please let us know what the resolution is. I would like to turn the on-write scanning feature back on.
Also, my reply got marked as the solution to this problem but it wasn't marked as such by me. I was replying to sandy's request for someone to open a support case and what the response was that I received.
I have posted this again because my earlier post was closed before I received a solution.
Here is an update on this:
Sophos confirmed there have been defects seen for the issues I reported under:
2##### : In regards to the CPU usage / memory leakage 2##### : In regards to the unknown up-to-date status
The Sophos engineer that worked on the cases with me stated "I suspect they will be fixed in the next maintenance release, roughly within one months’’’’ time. However I’’’’ll be monitoring the progress of the fix and let you know when to expect it."
I'll up date this post once I see things resolved.
Issue and history:------------------------------------------
Thu 01-Apr-2010 15:24
Sophos SESC9 appears to have a memory leak
Has anyone else seen this?
I've been testing SESC9 for a few months and found the following:
Savservice.exe starts with about 94MB of memory after install. Our managed nodes are setup to fail over to Sophos for updates if they can not reach our sites. When this occurs the Sophos site installs 1 of 1 and savservice.exe increases in memory use. This same thing occurs when our node comes back to update from our site install 1 of 1 and savservice.exe increases in memory use. If checked nodes in our testing and saw savservice.exe running 200MB, 300MB and 1.2BM of memory. I tested this on my computer and watched savservice.exe go from 94MB to 140MB before stopping my test.
I look forward to seeing what you have experienced.
Fri 09-Apr-2010 15:13
Here is an update on my post.
I've worked with Sophos tech support under two separate cases. Both have been escalated to global support. I also have a Sophos engineer that confirmed he saw the same thing in his testing. He will be overseeing the status of my cases.
When I hear back on their status I'll post it here.
The memory leak issue is still under investigation. 4-28-10
Update status resloved 4-28-10:
The issue where machines that are failing over to update from secondary (Sophos) and report unknown has been fixed now with a recent update. Please verify this on your end. Machines failing over should now report Up-to-date ''Yes'' with an error 0000006b where download failed from the primary location, rather than ''unknown''.
I'll post once I hear the memory issue has been corrected.
Currently we are working on possibly getting a special package available for you to test with. The report is the issue has been fixed in the next version and we are trying to apply the fix to the special package for you to test with. I hope to have more information available for you when I hear back on the status of this activity.
I was able to test a possible solution Sophos came up with to stop the SAVservice.exe memory issue yesterday. Here is what I learned:
I tested this possible solution and saw the following concerns: 1. SAVservice.exe stops and is reloaded. It took 38 seconds before the reload completed. This appears to happen during each switch between update sites. I was able to download the Eicar virus test file easily during the time SAVservice.exe was not running.
2. The install process during the update is still taking up to 50% of the CPU.
Results: The memory use issue is gone but a half minute window of no protection is provided during the switch from one update site to the next with a 50% CPU hit and no IDE or product changes provided.
I provided this information to Sophos. I'll continue to post here information I receive concerning this issue.
This post which started many months ago is still alive.
Sophos released a fix for the memory issue last month 09-29-10 but it turns out this did not correct the issue. I've reported to them that the memory issue still occurs. If I hear any new information I will post it here.
Quote