Skip to content
Notifications
Clear all

What's the actual memory footprint per endpoint? My measurements vs. spec sheet

1 Posts
1 Users
0 Reactions
1 Views
(@cloud_ops_amy)
Estimable Member
Joined: 5 months ago
Posts: 128
Topic starter   [#9663]

I've been running Cybereason's endpoint sensor (v22.1) on a fleet of AWS EC2 instances for about six months now. While the overall detection has been solid, I've been digging into resource utilization as part of our monthly cost review. The spec sheet and documentation mention a "typical" memory footprint, but my actual measurements are consistently higher, and I'm trying to figure out if this is expected.

On a standard Linux (Amazon Linux 2) instance, the documented "average" RAM usage is listed as 150-200 MB. However, my CloudWatch metrics (pulled from the agent's own process and the OS) tell a different story. Here's a snapshot from a `c5.xlarge` workload host over a 48-hour period:

```bash
# Sample from a monitoring script polling 'ps aux'
USER PID %CPU %MEM VSZ RSS COMMAND
cybere+ 45678 2.1 4.2 1456789 345672 /opt/Cybereason/cybereason.bin ...
```

The RSS is consistently in the 300-350 MB range, with VSZ often spiking above 1.4 GB. That's nearly double the upper bound of the spec. I'm seeing similar patterns on Windows Server instances, though the differential seems a bit smaller there.

Has anyone else done this kind of benchmarking? I'm trying to reconcile this for capacity planning, especially for our smaller, memory-constrained instances (like our GitLab runners). A few specific questions:

* Are my measurement methods (RSS from `ps`, CloudWatch's `MemoryUtilization`) the right ones to compare against the spec sheet?
* Does the "typical" footprint assume a completely idle endpoint, whereas a real workload host with frequent file/network activity causes more memory usage?
* Could certain prevention or sensor settings (we have most features enabled) explain this delta?

I'll be the first to admit that the tool's value outweighs a couple hundred extra MBs on most hosts, but for large-scale deployments, this adds up in terms of instance type selection. I'd love to compare notes with others running it in production, especially on Kubernetes nodes or dense cloud environments.

-- Amy


Cloud cost nerd. No, I don't use Reserved Instances.


   
Quote