Hi I have a technical question about Webroot Endpoint memory usage.
I've found Webroot commits around 600mb of memory when it only uses about 7mb.
We have customers asking about it, as this as that's a massive amount of memory for a program to reserve?
You can see it for yourself in Resource Monitor under memory and commit.
Why does Webroot reserve so much and use so little?
Thanks in advance!
Best answer by TechToc
That is true, however, because Commit memory is flexible in its usage, it can also go down allowing other applications to make use of it if necessary.
I can understand your point, however, Commit memory isn't really written to disk either. It's really a kind of virtual marker in the event that a process needs it. The commit size is written to memory, but the amount of that memory buffer isn't written until it's needed. There are tools out there that you can force it to write to disk, but generally, it's just marked, but doesn't actually use any Disk I/O until needed.
Windows in most cases is able to address this kind of elastic memory fluctuations because the page file isn't a static size. So while you can 'hard set' a page file size so that it isn't able to grow in size, the default options set at install allow for some dynamic resizing if necessary.
On the Data center side, there are a number of different functions built into a server that limit this kind of paging and optimizations that would cause this normal kind of behavior from getting out of hand like you could see. Additional RAM, faster disks, and HUGE pages file already allocated means that a process that is simply marking a reserve of memory (all of which are designed to eliminate the exact issue you mention as it applies to all software) means that the worst case scenario is very unlikely. I have a process running with 1.5 GB of Commit memory at this moment with very little impact on any normal functions of the system. I also haven't rebooted my machine in almost two weeks. Additionally, while it can certainly seem as if the commit size is increasing, it's unlikely to increase exponentially unless WSA begins journaling a process, at which point, classification of that file, or a console override would address this journaling.
Memory - Commit Size: Amount of virtual memory that's reserved for use by a process.
WRSA reserves some page file space in the event that the software needs to journal a process. The size of this memory allocation will vary greatly based on the system it's installed on, the number of unclassified files, and the number of processes currently running on the system. For example, my machine at the moment has 72,740 KB (System) + 203,600 (User) KB (269.86 MB) of commit size. 97 Processes running, and physical memory usage in the upper 60%. No unclassified processes are currently running. A system uptime of ~10:17:52. And, my memory stats are as follows:
Total Physical Memory: 8,190 MB
Available Physical Memory: 2,406 MB
Virtual Memory: Max Size: 16,377 MB
Virtual Memory: Available: 9,987 MB
Virtual Memory: In Use: 6,390 MB
None of this is really outside the range of normal operating conditions, for example 'SoapUI-.exe' has the highest commit size at almost 290MB. This is a tool I use for various functions, however, the Windows memory manager allocates a pretty large swap file to the application. The long and short of this is that SWAP (Virtual Memory) has very little effect on performance in modern operating systems and hardware. It's a requirement for multitasking functions, and isn't much to be concerned with. For those who want to know more about memory management, Mark Russinovich has a great series that provides more detail regarding memory management in Windows. It is a couple hours long, but for those interested it can be found: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL405
Thanks,
Lucas Moore
Webroot Sr. Escalation Engineer
Sure. My concern was more that Webroot had approx 600mb commtted and climbing. The longer a machine is left on, the higher it climbs.
Not too much of a concern for a workstation that can be rebooted which resets Webroot to having around 40 to 60mb commited. But when you take into consideration that it is installed on datacenter servers that don't get rebooted very often at all, you can wind up with it increasing exponentially over time.
That is true, however, because Commit memory is flexible in its usage, it can also go down allowing other applications to make use of it if necessary.
I can understand your point, however, Commit memory isn't really written to disk either. It's really a kind of virtual marker in the event that a process needs it. The commit size is written to memory, but the amount of that memory buffer isn't written until it's needed. There are tools out there that you can force it to write to disk, but generally, it's just marked, but doesn't actually use any Disk I/O until needed.
Windows in most cases is able to address this kind of elastic memory fluctuations because the page file isn't a static size. So while you can 'hard set' a page file size so that it isn't able to grow in size, the default options set at install allow for some dynamic resizing if necessary.
On the Data center side, there are a number of different functions built into a server that limit this kind of paging and optimizations that would cause this normal kind of behavior from getting out of hand like you could see. Additional RAM, faster disks, and HUGE pages file already allocated means that a process that is simply marking a reserve of memory (all of which are designed to eliminate the exact issue you mention as it applies to all software) means that the worst case scenario is very unlikely. I have a process running with 1.5 GB of Commit memory at this moment with very little impact on any normal functions of the system. I also haven't rebooted my machine in almost two weeks. Additionally, while it can certainly seem as if the commit size is increasing, it's unlikely to increase exponentially unless WSA begins journaling a process, at which point, classification of that file, or a console override would address this journaling.
Ok, that definitely seems like something we should watch out for then. How can we be alerted to Webroot deciding to journal a process? We would need to know about it before we can create the override. Is there an alert we can use to notify us of this potential issue?
Journaling is a fairly common behavior, and it has various levels. The most extreme is when you would see a entry similar to this in c:programdatawrdatawrlog.log Thu 2014-08-07 11:11:47.0722 Monitoring process C:Windowssystem32SnippingTool.exe [7633F554EEAFDE7F144B41C2FCAF5F63]. Type: 9 (312) (This is an example, the actual log did not include this entry.)
The 'All Undetermined Software Seen' report may determine if we have whitelisted the file in question in the cloud. But I am not aware of a 'Journaled' Process report. This kind of behavior happens pretty rarely and is triggered by the heuristic logic on the agent. If a unknown application is acting suspicious (or sometimes a known one in my example above) the changes on the system may be journaled to ensure that if the software is bad, proper remediation takes place.
Again, the performance hit for the memory allocation should be virtually non-existant, however, depending on the application in question Disk I/O may create some performance issues.
Hope that helps, let me know if there's anything else I can add or clarify.
I've noticed that since I've installed webroot SA on my server2008r2, my physical memory keeps increasing, it never resets even when no one is logged on... it goes upto the point it maxs out and then either it is too slow to work with or it goes to blue screen and automatically resets... this happens about every 4-5 days...
we found that the Kernel Paged memory was going up, so we downloaded the poolmon, and noticed that there is a tag called WRCS... this is taking up about 500mb now, and it will keep going up...
if I reset the server, this goes down to a very small number... and starts increasing every day...
we've searched it on google but nothing shows up, but I'm assuming this is related to WebRoot...
this is the tag that is constantly going up and currently ... below is a screen shot of what I see...
this is annoying and seriously disturbs the work flow...
Have you worked with support yet? The last I heard about this issue it's currently being investigated, so we'd want to make sure we get logs to give to the devs.
Nope, nothing...
as of my last email, the memory on poolmon is now 2x higher, and today finally I had to reset my server...
however, I am looking for a more sustainable solution...
I looked up your ticket to see what is going on. There seems to be some confusion there as to whether you're on the business or consumer version. When I look up your email address it only shows the business version - is that what you're using?
Stumbled upon this thread whilst troubleshooting a similar issue to dannydan whereby the paged pool memory is maxing out, eventually causing the server to fall over. Just thought I'd update this in case anyone stumbles across a similar issue.
Poolmon.exe shows the tag WRCS using a huge amount of memory and we were having issues with Webroot not communicating into the console.
There was a registry key in the following location:
HKLMSOFTWAREWow6432NodeWRData
String: RSP
This had the value '127.0.0.1' and when compared to other machines, we found this should be blank.
We removed the value and Webroot started responding. After reinstalling, the WRCS tag is no longer using a huge amount of memory.
We suspect this may have been caused by a piece of software that was previously on the server causing it to act as a proxy server. This software was removed around the same time we started encountering the issues.
