Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Endpoint Protection: Abnormally high RAM usage?

I have a work laptop which has Sophos Endpoint installed (company antivirus). I work as a software developer, so I often have programs like Microsoft Visual Studio, Android Studio/IntelliJ IDEA, Visual Studio Code, Google Chrome etc. open, usually at least 2 of those open at a time.

The work laptop has 8GB of RAM, which would normally be plenty to run, something like VS2019, Android Studio and 5-8 tabs in Chrome with at least 1.5GB to spare. However, doing that starts spinning up the laptop's HDD to use swap space. Upon looking at the memory usage in Resource Monitor, I noticed that even when idle (that being just running Windows and the startup background processes, which are basically Sophos, Nvidia's drivers and ShareX (which I use for screenshots and screen captures) the machine uses around 3.6-4GB of RAM. Of this, Sophos (at least the processes I can make out to be from Sophos) uses anywhere from 700MB to 1.1GB.

Is this normal for Sophos to be doing? In my experience antivirus programs on machines with very little RAM to spare have mechanisms to reduce their own footprint, leaving more for other applications. I can understand the average user saying 8GB is a lot, but IDEs have a rather large footprint to start with (Android Studio uses around 1.5-2GB, VS about the same). Is there a config flag or option somewhere to force Sophos to use less RAM? Or which non-essential features can be disabled that typically have a larger footprint?

I've attached a screenshot from Resource Monitor that shows Sophos' memory usage, this is on a fresh boot of the machine, having only opened Chrome to type this post.

As you can see, Sophos has around 750MB of memory committed, about 500MB of which is working memory. I don't think this is normal.

 

Any help would be appreciated

Richard



This thread was automatically locked due to age.
Parents
  • Hello Richard,

    Commit is virtual size, Working Set (WS) is what occupies RAM

    savservice's WS is about the expected value, Commit is high (should normally be about the same) - it should eventually go down. Numbers for swi_service are expected (and anyway not high).  SSPService seems high, might or might not be in conjunction with SophosFileScanner (that I don't have, I'm not using Central, so I can't comment on it).
    Commit should eventually go down to about WS, would be - as you say - around 500MB. Assuming SSP and SFS are higher than normal (for whatever reason) don't expect the total to go below 400MB.

    Christian

Reply
  • Hello Richard,

    Commit is virtual size, Working Set (WS) is what occupies RAM

    savservice's WS is about the expected value, Commit is high (should normally be about the same) - it should eventually go down. Numbers for swi_service are expected (and anyway not high).  SSPService seems high, might or might not be in conjunction with SophosFileScanner (that I don't have, I'm not using Central, so I can't comment on it).
    Commit should eventually go down to about WS, would be - as you say - around 500MB. Assuming SSP and SFS are higher than normal (for whatever reason) don't expect the total to go below 400MB.

    Christian

Children
No Data